Hey thanks for hopping in @bretton.dev!
The groups spec does build on atproto spaces. Though it’s important to note that spaces can be public as well! I think spaces map to the data model of a forum better than the public broadcast repository does. Have you tried out the spaces alpha yet? You may find that it works very nicely for Cove.
Specifying the groups standard to function on top of the public broadcast repo would require a lot of additional specification. And those groups would have a difficult time transitioning between private & public as it would require migrating data between both protocols.
The same is true with atproto spaces and the atmosphere groups spec! Content still lives in the author’s repo. This post gets into that design decision. A few things have changed since March, (for instance renaming “buckets” to “spaces”), but the general point still holds.
3 Likes
@dholms.xyz Sweet, sounds good! I just read the leaflet post, I’ll look into spinning up the alpha with a test community to see what I can come up with. Mostly worried about the rewrite on our side: the communities backend around ingestion, any backfill / labeler / moderation changes, and our Fediverse bridge, which would have to be rewritten around spaces.
I’m not excited about that rewrite, but I suppose that’s the cost of building before the primitive existed, and if spaces are the right foundation, then I’m not going to fight it.
I think my ultimate question is: what does a public-read space give a fully public group that the public repo doesn’t? I can see the benefits for private and mixed groups, but I’m trying to understand the win for communities that are public by design, like Reddit and Lemmy, or even some larger public Discord channels. To my understanding, a space seems like the weaker fit for them, since their content is meant to be read by anyone, indexed and picked up by any app, which fits cleanly into the firehose architecture. And perhaps the answer is that there’s no direct win, and the trade-off is worth it for private setups, but curious if you have any immediate answers.
I think the short version is that you could build it either way. I’m personally pretty interested in reddit-style public forums, and I would build most of it on public broadcast data even after spaces are fully shipped. But I could also understand why somebody would want to use spaces instead.
I did some writing on on representing communities generally on atproto earlier this year, before spaces was designed, which might be of interest. Regardless which sync mechanism you end up building on, I strongly recommend using the “group account” concept to represent group/community spaces in the network.
I’ll note that this is still kind of an open protocol design and ethos question: how public should spaces be? Could or should we tweak the protocol to make them more or less public? This is all still being debated and a bit in play. I’ll admit to being a bit biased towards public broadcast for public data (I love the firehose, and the simplicity of public-means-public). But my hot take is that this is a complex enough question that we won’t really know until folks build real services and run them at scale and see what problems arise.
Here are some other ideas/considerations:
- one of the advantages of spaces are that they give a clear “locality” or boundary for what needs to be synchronized. this is nice if you want to be able to synchronize just a single group (eg, single-group self hosting), or if it is hard for you to deal with the volume of other data on the firehose (eg, all those bsky like records)
- things like
listReposByCollection do help for backfill, and there might be ways to give public broadcast data a bit of “locality”. but it won’t be as strong as with spaces.
- whether spaces or public broadcast are more efficient at larger scale (hundreds of thousands or millions of active accounts being synchronized) remains to be seen (in my opinion). some of the spaces stuff is light-weight (eg LtHash vs MST), but just subscribing to the firehose and not needing to make lots of outbound HTTP requests to many servers is also pretty nice. I don’t think we have hard data yet one way or the other; maybe public spaces will be more efficient!
- if you want groups to be able to flip all their data between public (anybody can read) and restricted (eg, only members can read), and have that be relatively seamless, I’d probably go with spaces from the start
- if you want public data to get picked up and indexed by lots of services, like composable labelers, feed generators, bridges, search, etc, I think it will probably be easier with public broadcast. I suspect that public space indexing will usually be “app modality specific”. I could be wrong, and maybe we can tweak the protocol to help with this.
- I agree with dholms that getting the opensocial.group specification to work natively with public records (eg, for members) would add a bunch of complexity and is unlikely to happen. That being said, you might be able to copy or adapt parts of the design.
- groups could use a mix of both sync mechanisms. eg, you could have all posts be public broadcast, but still have a locked-down chat area just for members. but then you are implementing two sync mechanisms.
- you could configure a group account to be a public labeler over group data. this would involve running/implementing a labeling service (like Ozone), and updating the group account DID document to reference that labeler
5 Likes
Thank you, appreciate the detail here!
if you want public data to get picked up and indexed by lots of services, like composable labelers, feed generators, bridges, search, etc, I think it will probably be easier with public broadcast.
Yeah definitely think we’d fall into this bucket
I suspect that public space indexing will usually be “app modality specific”. I could be wrong, and maybe we can tweak the protocol to help with this.
Even if I don’t move this direction to spaces, certainly think this would be the best for the protocol just from an interop standpoint, but unfortunately I have no suggestions on the “how”.