We successfully are now able to write and read a profile json with an image, name and city to our private wn.fs app path. What is your current best intended strategy to make the profile data shareable, updateable and revokable so it propagates across all users, which have access or no access anymore to the profile resource.
We currently would like to give the user 3 options on their profile data:
Keep the profile data completely private and only accessible to your own devices (in this case propagate the outside world an anonymous avatar and name, like in the screen below)
Share the profile data with only the people you trust and know (with the option to revoke this access)
Make the profile data completely public and pin it to the omo organisation service for public lookup
The goal for the first iteration, would be to create profile resolvers on this screen, according to the upper 3 options:
Especially with account “person” related info, this may be better accomplished with a type of verifiable credentials.
For example, we already collect a (verified) email address as the minimum info that we need for the platform, and this is a common piece of info that apps want. Apple’s approach of also cloaking this for users is interesting. The GitHub OAuth API also provides email by default. So for email, this may be a platform feature.
We see apps collecting more info as you describe. If we think about this as not profile data but just ANY data, then public, shared, and private are the three levels we see.
Shared access would be on an account to account basis. Where the data is encrypted unless shared with the user.
“shared with / by me” is on the roadmap of WNFS, which can be a way to address 2. but it s harder right now I think
to the other points
private profile info you have already implemented this Sunday, with profile.json
should be possible; one (maybe not ideal) path could be to add a contract to xDAI where (safe -> byte32) registers the CID of the profile.json stored by the Omo app in the public directory; it would need to update to xDAI on profile updates
Good idea, the approach to attach the CID onchain is an interesting one I was considering as well, albeit not a prio for now.
Looking much forward for the shared with / by me feature.
I have another question regarding how to give write access to someones public folder. As I am currently playing with the marketplace offers, how would you go along? Currently I think to put each product offer or product request into the public folder of its user and then in a second step allow the user to pin its reference f.e. to the public folder of an omo account in order to make it globally indexable. Is this currently already possible or the intended strategy?
might be best to see if some responses from others come back.
writing to others public dir is possible in principle; if I have (in my app) have write permissions to a public subdirectory, then you could grant another users session write access to (a sub directory) of that subdirectory, for a short amount of time. It’s not supported by the webnative SDK as such, and Im not sure it s recommended to do this. It might require building a bunch of stuff that doesnt noicely fit (eg. “linking between the two users A and B”, how to now manage and revoke these permissions.
Neither would this give you index-ability/query-ability.
I feel this might be better placed on shared state, like a blockchain
In short, this is the “aggregation” use case @samuelandert. This is user data, so we’re thinking of different ways to store indexes while still having user control.
This isn’t necessarily what is needed for this use case, but “Public Dropbox” functionality (write permission, but no read permission). This is a standard feature that has shipped with MacOS for a very long time, and is something we can do with our system.
@samuelandert rather than writing this up as a feature request (“subfolder access control”), explaining what you want to accomplish is more useful in having us design this.
private only – done today
share – wait for “shared with” functionality in WNFS – once you have a user permission flow here, WNFS can take care of giving access to the users. This isn’t really subfolders, there will b a new “shared_with” tree that takes care of making this stuff available
public data, plus aggregated view – public data can just go in a public folder, the tricky part is aggregation
I wrote about Aggregated Views previously. We can prioritize the public one I think.
but free-floating, so you’d want some way to DAG it all together