I also wanted to chime in with some thoughts after following the discussions around communities and the most recent data diary. I outlined my use case in #855, but I’ll briefly describe it here since it differs quite a bit from the community/group-like use cases that are being discussed a lot:
-
private personal posts to an audience, where only the owner knows the member list of the audience
-
anyone in the audience can reply and see the replies of other audience members
-
this maps to things like private facebook posts with a custom audience, google+ posts to a specific circle, or close friend stories on instagram
-
allowing PDS host choice and data portability
-
interop with apps using same lexicons, including reply and full thread sync
Allowing the member list to be fully enumerated by apps on behalf of anyone in the space as a side effect of credentialed sync via getMemberOplog / getMembers (including compaction recovery) doesn’t feel private enough for this use case. I generally support the permissioned data shape so far, but I’d need viewer-scoped member list responses for SpaceCredential holders (while owner OAuth can still see the full list for administration).
There was a suggestion in #855 to use an arbiter in front to modify how getMemberOplog, getMembers, and any recovery path that enumerates DIDs work, but I’m concerned this means the space data would not truly be portable and would always be tied to some bit of my infrastructure. It would also mean every product of this shape of personal data would have to host its own arbiter or fork the PDS implementation, with each one possibly differing slightly in implementation.
I’d like a basic option for viewer-scoped member listing at the protocol level. My suggestion would be to add a memberListSync: full | ownerOnly option on createSpace. This obviously doesn’t prevent inferring participants from replies in synced records, but it at least prevents sync from exporting the full graph through member list APIs. Any other functionality can definitely be layered on top “above the waist” as mentioned in data diary 6, but something like this bit feels fundamental for space audience privacy + interop.
I’m happy to join in on any community call!