Continuing the discussion from Inter-app access control:
I posted my thoughts and some motivating use cases on end user expectations on data access control and privacy.
Feel free to move them here if it makes more sense.
Continuing the discussion from Inter-app access control:
I posted my thoughts and some motivating use cases on end user expectations on data access control and privacy.
Feel free to move them here if it makes more sense.
Yes, I think we should! Or a forum thread, or a wiki page, or a github repo… We already did a lot of work on this topic within the Unhosted project, see Data modules — remoteStorage.js 2.0.0-beta.6 documentation.
@megoth on the other thread, you wrote:
We are working on the process of how we should be public about our work
The ‘we’ there being Inrupt’s team within the solid project, right?
let the community contribute to work on cases like this. We should have something ready soon.
If we create a working group or some other community process, then this would be the other way around the SOLID community would welcome Inrupt’s contributions, rather than Inrupt welcoming contributions from the community project.
Yesterday, @MitziLaszlo and I were discussing the option of using a W3C community group as a light-weight way of expressing who is entitled to contribute to Solid.
How open do we want the Solid project to be?
More specifically, under what circumstances should Inrupt have a veto on inviting contributions from outside Inrupt?
If two community members disagree, and one of them is an Inrupt employee, then whose proposal should be adopted by the Solid project? Both, maybe?
What about third party middleware for apps? And javascript API dependencies, version and acceptance by the community?
For example I get attracted to the Streams API
Yet if I use it would it make people not want to use my middleware
The ‘we’ there being Inrupt’s team within the solid project, right?
Yes, you’re correct. Sorry for not being clear about that.
If we create a working group or some other community process, then this would be the other way around the SOLID community would welcome Inrupt’s contributions, rather than Inrupt welcoming contributions from the community project.
Yes, I agree, I also think that is how it should be. My previous comment was written a bit immaturely, I was quite new to the Solid project (still am in most regards).
What I hope we, as in the Solid community (even though I’m an employer at Inrupt, I’m still a member of the Solid community as well), are able to formalize this processes so that they’re transparent and fair to all. I would imagine Inrupt would participate in this on the same level as other contributors.
If two community members disagree, and one of them is an Inrupt employee, then whose proposal should be adopted by the Solid project? Both, maybe?
I would hope the best proposal should be adopted The purpose of a process would in this regard be to facilitate discussions that would (hopefully) come to a conclusion on which proposals is best. Both proposals could still be accepted, given they’re not exclusive to each other. (We probably need some real-life examples to hone the process.)
It would help clarify if Inrupt folk displayed this status - you can have it appear next to your avatars on posts.
Let’s move forward with this, shall we?
@MitziLaszlo let’s chat about this at the Utrecht meetup tomorrow?
I think third-party app access control (giving them less than root access) is a big missing link atm, and would love to contribute some of my time to help fix that.
Shall we use the SOLID w3c CG infrastucture for this (mailing list, contributor agreement)?
Hi @michielbdejong,
Yes, great let’s talk about this tonight.
As the W3C inrupt chair I’d be happy to facilitate these kind of conversations.
Mitzi