These use cases haven’t been specced out much but we anticipate a few specific private data use cases for Semble, a social bookmarking / knowledge curation tool.
1. Private Cards and Collections
A bookmark is saved as a “Card” which can optionally be added to “Collections”. Ideally, users can have the choice of (1) saving cards privately and (2) creating private Collections.
2. Private Collaborative Collections
Collections can be collaborative, and we may want to support private collaborative Collections. I.e. only viewable and editable by approved collaborators.
2 Likes
This is great @wesleyfinck.org, thank you!
The collaborative use case is an important one for BOTH public and private data so that gives us another angle to look at.
If you squint, OAuth Scopes for read/write access is orthogonal to whether stuff is public or private and having a method for doing that.
1 Like
On the collaborative use-cases, I wonder if there’s any merit to the idea of declaring API servers for editing records.
Let’s assume you’ve successfully shared the private collection with the intended recipients only. To support mutations, you could just declare in the record that foo.com controls the record. Then collaborators just submit edits via API requests to foo.com, which has been granted prior access to mutate the record.
I suppose foo.com could actually be the collection owner’s PDS, if the needed APIs are generic enough.
The way we handle collaboration with public PDS data is to:
- collection creator creates a collection record in their repo (including list of collaborators). Only the creator can add or remove collaborators
- collaborators add cards to a collection by creating a “collection link record” which links the card record to the collection record
- only if the did of the link creator is in the collection record do we consider it “in” the collection.
The issues with this approach are:
- only the collection creator can add or remove collaborators
- only the person who added a card to a collection can remove it
These aren’t really blockers to us at the moment but it leaves us with relatively rudimentary collaboration.
The API server approach @pfrazee.com suggests is an interesting work around, thx for the suggestion!
if permissions are also data, being tightly coupled to the data as well, and if users are to control their data, thus so their permissions too, and the PDS is the place that manages that?
we also wouldn’t want a specific domain blocking access to a forked appview on another domain. In my experiment, I have a subject type for appview that sits next to accounts, apikeys, oauth, and groups, because I imagine there are use-cases out there, like notifications and giving an appview permission to push notifications into some inbox or space