frequency.app is a private, personal social networking app that is currently built on top of ActivityPub. atproto didn’t fit our use case initially given the public-only nature, but I’d like to explore how the permissioned data proposal might fit it now.
frequency is basically like private individual facebook or instagram accounts for sharing photos and videos with a small set of close personal connections. Its current and proposed features include:
2-way connections instead of followers
private posts to all connections with bcc semantics, but replies visible to the entire audience
private posts to a subset of connections with the same bcc/reply behavior
ability for a user to make their connection list private to avoid relationship scraping for advertising, political targeting, etc.
easy data portability without breaking thread references
I’ve just caught up with all of the current Permissioned Data Diaries through Permissioned Data Diary 5: What’s in a Name? - Daniel's Leaflets . I think that a lot of my permission-related features would be possible to implement within the current proposal, but only with spaces having a certain shape:
To keep connection lists private and have bcc semantics on posts, there would have to be a space per connection rather than one space with all connections as members. Posts would need to fan out to each connection’s space.
But the only way for replies to be visible to the whole audience in this shape is to have the post author rebroadcast them into each space. Given Diary 3’s rejection of asymmetric signatures on private data as an anti-pattern, there is potential for abuse here without a way to verify a reply’s integrity.
I’m still catching up with posts and skeets around permissioned data, so feel free to point me in the direction of any existing writing by folks who are thinking about similar needs for the shape of their spaces. So far I’m seeing a lot more group-like use cases, so I wanted to put this one out there.
Thank you for finding an edge case that doesn’t seem to work great with permissioned data.
Me and my team are trying to build community infrastructure on top of the permissioned data proposal, so we’re really trying to find the limits and understand what needs to be taken into account for different use cases. This is really useful perspective.
I think with an intentional violation of a portion of the protocol you could make it work while still being interoperable. You could do it pretty simply with a custom space host implementation, which shouldn’t be too much trouble to implement.
Here’s a way I think you could make it work:
Each user has a personal space that they put their posts in.
For every connection that they have where they want to allow someone to read their posts, they add them as a member of that personal space.
The tweak that we make to the space host, though, is that it will not show the other members of your personal space who is in the member list.
For example, if Alice has a personal space and they add Bob and Charlie to it:
when charlie queries the member list from the space host, it will tell him that Alice and Charlie are in the space.
But when Bob asks for the member list, it will tell Bob that only Alice and Bob are in the space.
So the same space appears to only ever have two members, except to the owner who can see all of the members.
When Bob writes a reply to Alice’s post, then Alice’s account can “rebroadcast” it by creating another record for the reply with a URI that links to Bob’s reply.
Charlie will notice the link, because he see’s it in Alice’s repo, and then he can go and fetch Bob’s reply from Bob’s PDS, now that he knows it exists.
Before Charlie can make a request to Bob’s PDS, though, Charlie, like normal, needs to get a space credential from the space host.
When Bob’s PDS sees Charlie’s space credential, and that it was signed by the space host, he’ll know that charlie is in fact a member of the space, and that it’s OK to share the reply with him, even though, when Bob checked the member list earlier, it looked like only Alice and Bob were in the list.
So essentially we just lie about the member list when other people ask, so that it can’t be crawled, but the rest of the protocol works just fine as long as we have Alice announce the replies so the other members can find them without crawling the member list.
I am also a fediverse user (@ajhalili2006@tilde.zone, bridged via Bridgy Fed) although I mainly use Atmospheric apps more lately (the data portability is the killer here to be honest). Thanks for the hard work on permissioned data in the AP side of things so far!
Thanks for thinking through that use case with me!
I like your suggestion for how to do the reply rebroadcast. That avoids any issues with the space owner being able to nefariously edit replies when other members can’t verify authenticity.
The suggestion to make the getMembers call lie and only show the owner and the person asking is interesting, but I’m hoping to avoid customization at the PDS layer so that accounts can be hosted anywhere rather than only on my own custom PDS. I wonder if the private (except to the owner) members list is something with a broader use case than just mine? I can imagine many types of private groups that wouldn’t want the member list to be public (activists, spicy content, etc.). I’d love the help out with any community infra you are building so that this can be available to a wider swath of atproto!
Oh, that’s perfectly allowed! Many apps and use-cases will require the space host to be separate from the PDS. In fact I would recommend it for most community use-cases.
It is far lighter than a PDS, and is merely responsible for hosting a DID, the member lists for spaces, and signing the space credentials.
Even with the lie, it should be compatible with any spec compliant PDS as far as I understand.
We’re actually working on what we’re calling an “arbiter” which is a custom space host meant for communities & groups, and it’s one of the cool parts about the permissioned space proposal that you are allowed to handle the space creation and group membership in your own way with your own space host, while still being compatible at the protocol layer with standard PDSes.
it’s one of the cool parts about the permissioned space proposal that you are allowed to handle the space creation and group membership in your own way with your own space host, while still being compatible at the protocol layer with standard PDSes.
Oh! I wasn’t aware the space host portion would or could be separate from the PDS! Excellent! That makes it much easier to consider any extensions.
We’re actually working on what we’re calling an “arbiter” which is a custom space host meant for communities & groups
Very cool - I’ve seen arbiter’s name cross my feed a few times, but hadn’t grokked what it was for yet! I will dig in now
I am also a fediverse user (