I’m working on a new app based on AT Proto and would love to have a “group”. A shared resource that folks could post in/share things in. The primary use case I’m thinking of is a book club, so we can all share opinions as we work our way through a book, or share reviews of multiple books.
I’m curious if there are any best practices or patterns I should follow for this. Does the representation of the group/entity live in the application? Or would it live in the user’s personal repo that created it? I’m leaning towards having the details of the group (name, description, bio, etc) in the application and each individual having a group membership linking them to the group in their own repo, but not sure if that is really working the spirit of ATProto or not.
This is built to do kinda that, but real minimal and very simple.
It was explained to me as a lexicon for .books .lists and .stamps
Use them however you like in your app, and we’ll have interoperability.
Users hold their own self-declared .books as a library
Librarians can make a .list in their own records.
Readers apply said .list references to their .book records
Librarians can add a .stamp connecting .list and .book with validation
How each librarian wants to use this pattern is up to them.
There’s no markers or ISBN requirements, kinda to be super simple.
If it’s useful at all, take a look?
(I am very very bad at explanations, so apologies to trying)
I think this is the rough plan - collection owned by an account, that collection record is in that users PDS. Links have a “collection link” to put them into a Collection.
Extremely rough, could probably use some whiteboard sketches
@bnewbold.net wrote up some details on using dedicated “group accounts” to own community resources like this
For your book club the stakes are likely not that high.
Yeah! There has been an evolving and maturing idea where a communal identity “owns” wrapper records that had an inner reference to community specific content records.
For example, the community did:web:book.club exists and has a PDS. Nick creates a week 2 thoughts post at at://did:plc:nick/club.book.post/abce1234 through the book club AppView and as a part of that process, the AppView also creates the record at://did:web:book.club/club.book.post wrapper/bcde2345 that has a strong ref to Nick’s post.
The AppView does this to have moderation controls for the wrapper records it maintains, but users “own” their own posts. It also has an interesting side effect because cross posting can point to a single user’s content.
That same model can be applied to lots of different content, from book club reviews to forum topics.
I’m interested in the same concept, and want to do it in an ATproto compatible way, but I have users that aren’t on ATproto yet. Thanks for bringing it up for discussion!
Hi! For this comment is there a significant to your suggestion of using the did:web or are you meaning a group would have any DID? I’m not clear on if there’s a best practice between using did:web vs did:plc
I was just using it for demonstration purposes to distinguish between an identity that represents a community (book.club) and an individual / member of that community (nick).
Coming back to this thread to share an example! I’ve got a PDS running for the domain opensocial.community and am creating community DIDs for things like name.opensocial.community
My plan is to host a small app on opensocial.community that can allow folks to create/edit communities hosted there but then also to have APIs that I can hook into to access communities from the app I’m working on building (Create new ones, read/search through communities, add a new membership to a community, etc).
More thoughts about it here, I’ll probably make an actual blog post once I have a more concrete implementation and have it integrated into the actual app I wanted it for (this is what over engineering my book club but here we are) @brittanyellich.com on Bluesky
Hi all, thanks for sharing all these thoughts - I’m just starting to get a little bit caught up on the discussions here and it’s exciting to see so many overlaps in thought with how we have been thinking of things in my work with @zicklag.dev and @erlend.sh on Roomy and the Leaf system underlying it. The discussion here inspired me to write up some thoughts partly in response, which I posted here as this leaflet:
