I'm a staff engineer, staff software engineer at GitHub, and promise I know how to use computers. I'm an atproto-enthusiast. Why I'm here. And also a member of the Chronically Online, and really, really love online communities. I work remote, and so online communities is really how I engage with a lot of folks. And so that's what I got really interested in. I co-host uh the overcommitted podcast. I'm gonna be recording this weekend. If you want to talk about your experience here, let me know because we're gonna do a special episode. Uh and I also brought some stickers that I'll put out once I find where where all of the stickers are congregating.
So a few months ago, I uh had this thought that I thought was a brilliant idea. I was like, why isn't there a good reads or like a letter box on atproto? How does this not exist yet? And so I started building this app called Collective, which was sort of you know the same thing. Um turns out it did exist. And there's quite a few of them. Um in particular that I really like is called popfeed.social. They did this way, way better than I had done. Um and I highly recommend you check it out if you're interested in something like that.
Um but one thing that I got really stumped by while working on this problem was I have an online developer community for overcommitted, and we have a book club. So we like to read technical books together. If you are also interested in reading books, let me know. Uh, you're welcome to join. Right now we coordinate on Discord. And Discord is great, but I really wanted collective to help you know facilitate the book club situation uh because it's really awkward to say, all right, we're gonna put our list on GitHub and then we're gonna have the conversations in Discord, and then we'll have some events, and it's just it's kind of a mess.
So I was like, you know what? Wouldn't it be nice if we could solve this problem? Uh Discord now owns our member list, it owns our reading history, it owns every single conversation we've had about every single book. If Discord decides to change their terms, which I'm sure they would never do, then we lose all of that. The entire history of our entire community can just be erased. Uh, and that's a real bummer. It's not necessarily just a Discord problem. This is also a platform problem. Every single group that has been built online on Reddit or on Facebook or on Slack, the platform owns every one of those spaces, and the platform gets to make all of the decisions about what happens there.
And when the platform disappears, that means the community disappears too. You got Google Plus, MySpace, Twitter, what once existed of it, all gone, along with every single conversation, uh and every shared memory and piece of community knowledge. So I think that atproto DID a really great job of solving personal ownership. Your posts live in your repo, your social graph is completely under your control, and your identity is portable to wherever you want to bring it. But there's still an open question one question about what about shared things? So, what about book clubs or community projects or the group chat itself?
Does that belong to the individual or does it belong to the group as a whole? So these are the design questions that I was thinking about going into this because I wanted to build something that would make it so that my group could live not just in collective itself, not just on Bluesky where we chat to each other. I want it to exist on its own and not be controlled by whichever platform we are working in. So the first question was where does the data live? Uh you know, is this a shared PDS? Is it someone's personal repo, whoever created the group?
We'll get into that. That can be problematic. Um, somebody is familiar with this problem. Um then who controls it? Like, does the person who created the group get automatic full control over that group forever? No, absolutely not. Like that is that's crazy because then you know, anyway, we'll get into that. Um then how do members themselves relate to the group? Do they have to sign up through whatever group mechanism they're in? Um, what determines how a group, how an individual controls their own affiliation with the group? And so those are the things that I brought into thinking on this problem.
And I do want to give some shout-outs uh to a ton of folks in the community that have already been thinking a lot about this and that uh their work has gone into uh what I ended up building. So um Brian Newblad, I just met you this morning. Uh sorry I'm stalking you online. But he had some great like great leaflets on this. Nick Jerichen is I don't think he's in here, but I uh I technically work with him as how he's been introducing me today. We work at GitHub together and I've been bugging him. He's had some great stuff.
Mary, uh, the front page team, Erland, who I don't believe is here, uh, and then also I wanted to give a shout out to Amelia who has been very patient at ask answering all of my questions here. Uh yes. So I've been collecting these and I uh I built a thing uh with that. So approto's philosophy is really your data, your repo. That works for group personal data, but not so great for shared state. It doesn't really fit neatly into this one person's repo. So how do we extend that ownership model to collective data without losing what it is that makes atproto so special.
And this is the approach that I came up with, which is open.social.community. It isn't really the answer, but it's an answer. Uh, and you know, you can try it out and see if it's this is a thing that fits you or build your own thing. That's the beauty of this community. Uh it's group infrastructure. It's not itself an app view. It's just an infrastructure and a set of APIs that anybody can integrate with, any app view can integrate with, or any community can manage their own group through. And I'm gonna walk through a couple of the design decisions that were made.
So the first one, which is uh the most important to that that ownership question is uh groups are stored as atproto identities themselves. They're their own DID. Um I've separated the group infrastructure from the app because I don't want to get into the situation where I've built this fantastic community and then the app goes in a direction that I don't agree with, and then we're just completely locked in. Membership is a two-way handshake. Not anybody can just join any group. I mean, maybe there are some groups who are okay with that, but there's definitely some that aren't.
And you can't just say, hey, I'm gonna join this group now. And then finally there's a wrapper pattern to have uh shared content that makes it easy to uh show within an app view uh without necessarily overloading that repo with a lot of extra stuff. So what does that look like? Every group gets its own DID. So for example, my book club is uh its own web DID web over committed.dev. It has its own handle, uh, its own repo on a PDS, and then group shared data is stored within that repo. That makes uh a group a first class citizen of the protocol itself, and it means that it gets to take advantage of a lot of the stuff that's already built there.
It's not a row in some app's database, it's an entity with its own identity. And just like personal DIDs, that entity is at least hopefully portable. And then the infrastructure, instead of being an app view itself, this is what the infrastructure looks like. So I can have collective, which is has access to open.social.community. But then you all can also have your own other apps that have access to it. Any app view can connect to it. Um you can also have you know your podcast app or your reading app or multiple of those if you want.
Maybe you want to support multiple, you can want to support Bluesky and BlackSky and Eurosky, all from the same thing to have one group, then that's totally reasonable. Each app gets its own namespace within open social, so collective stores app.collective social dot group.list lexicons. Um, and then other apps cannot create other lexicons within the group unless they have access to those namespaces. That prevents other apps from overwriting data that you know you don't want somebody else to be able to change the data for your podcast app from collective or vice versa. Same group, different data and no conflicts.
The group there is the shared context then, and then the group gets a decision on which apps it also has access to. So if an app does go in a direction that the group decides that they don't want access to, they can also prevent that group from having access or that app from having access to that group. The next one, so membership as a two-way handshake. This means that there is a membership record in an individual's repo, and then also in the group repo. That confirms that not only has the member agreed that they want to be involved in this group, but the group has agreed that that person is involved in that uh in that membership record.
That means that an individual can leave anytime without needing permission from the group to leave the group. And then at the same time, the group can you know excommunicate somebody if needed without having to get permission to update that individual's repo. It has a nice uh opportunity for privacy here too. So you can have a group of membership records that you know have hashes that are storing instead of the actual membership identity, which means that then you don't necessarily have a list of all the people that are in the group sitting in the repo, which can also be beneficial.
And then the wrapper pattern. So in this case, this is for user content. So the group creates a wrapper around that content. Um, Bob in this case will own the book review. They create the book review and they own that content, but then the group owns a wrap or wrapper around that content. That means that the group has access to remove that content from the group if needed. And then Bob, if he decides to leave the group, he still owns his own book review, which is nice. Then the group repo also ends up being an index of references and not necessarily a copy of all of the content, which can also be uh a bit problematic.
And then this is what it looks like end to end. So you register an app, in this case collective, as an app view with open.social.community and get an API key, which can be used for authentication. And then you can create your group through those collective APIs. We're still working on some PDS things involved to make that simpler because nobody wants to have to create a DID and then put it over anywhere else, but we'll get to that. Members join through that two-way handshake, which again can be within the app view if you'd like, or through open.social.community.
It has its own uh UI for that. Um then members contribute content via their wrappers, also through APIs. They support community creation, uh, membership management, namespaced record storage. Uh, because I work in the uh enterprise space at GitHub, there's also audit logging and custom roles and permissions, which were probably a little bit unnecessary, but it's what I know. And uh because I don't want to just talk about it, I'm gonna show you a little demo uh through images. So this is what it actually looks like uh on the web. Um both open social and collective are up.
I like I said, don't use collective. It's it's not very good. But open social is up, um, and I've spent a lot more time looking at this. So this is how you can register a developer app. You can go in and initially set like what are the lexicons that you want groups to be able to manage, and you can say with the regular create read, update or delete. Do you want everybody in the group to be able to do that or just group members? So you can have a completely open one or say, like, eh, let's say that only admins can delete things or something.
Next, you can view the group itself, um, the list of members, you can search through it, um, see who has registered with this group, um, and also have different community settings. So community admin can configure settings like whether the community is completely open, anybody can join, whether they want it to be closed where they need an approval, or whether it's private but asterisk on private because everything's in a repo in atproto. So uh private doesn't really exist just yet. But it will. There's some very smart people working on that problem. Um these governance decisions are explicit and visible, they're not buried, they're just all stored within within the group's repo.
And then finally there's app permissions. So a community admin can say, I want access to this app, but not this one within this group context. And theoretically, there's also some opportunity here to create some sort of a record now saying this is where this group has access to. Maybe we can just create like a Steam or Roblox type app store where you can access all of these different apps. You could access collective or Bluesky or BlackSky or Streamplace, all within one space, and you can say these are the places that my community is gathering, so that it's easy to gather across different contexts.
And then finally, uh collective. So you have the ability to discover new communities, um, search for them and view them. Uh each community has its own handle, uh, membership status. Um you can see here we've got overcommitted.dev, which is the overcommitted book club, which I already have access to, and then a few of the book club features on collective, uh, because why would I build just one app when I could build two? Um is what the overcommitted group actually looks like. So it has a collection of lists of the different books, including the book that we're currently reading, and an ability to set different sections by date, an ability to comment on different sections of the book, and an ability to make sure that you're not spoiling those things so that you complete the book reading before you actually participate in the discussion.
This is the most recent book that we read, writing for developers. Cynthia Dunlop and Peter Sna Sarna are both very active on Bluesky, and I highly recommend you check out the book if you are in the very small niche of developers who also like to write for other people. And then, yeah, so the full app is available at open.social.community. If you're interested in building on it, let me know, because I would love to see how this actually scales across other, you know, other apps. Like I said, there's a lot of features that are built in already that are probably overkill, but then we also have collective social, which I think is mostly just for book club organization.
Um, but we also have some movies and some other ways to collect podcasts and things like that. So uh yeah, that one is in alpha, I will say, as a way of saying it's not quite ready. Um, but what about so this brings me to some important points about groups. Uh, so uh specifically about governance and moderation. So one of the things that Brian brought up in one of his posts uh brought to my attention is from Nathan Schneider who coined the term implicit feudalism, which is a very large way of saying that there's a default pattern where whoever creates a thing online typically ends up owning that thing.
And I think that that goes in multiple ways. That's not just the group itself, it's the pat the platform that actually allows the creation of the group. So by default, there is a bias towards building uh communities as fiefdoms where somebody owns that group and they want to, of course, increase membership and be the person who owns that community. Um, but that doesn't that means that that person has absolute power over the group. And a member needs to start seeking permission to be able to do anything, which is something that I've experienced a lot in community spaces.
It would be really nice if we did this thing, but then they need to get permission from the person who runs the community to actually do that instead of just doing the thing. So what shared groups on App Proto can enable for us is we can have different governance patterns. What does that actually look like when we have control over it separate from the platform? We have an ability to make that completely transparent, where the rules are visible for everybody, and that you can create rules that fit your community because it's not a one size fits all approach here.
Different communities are gonna want different ways of managing themselves. And so we want to be able to make sure that it's flexible enough that they can do what they want to do across all of the different apps. And then moderation is the other spot that I've been uh looking at this from, which is a layered moderation approach. This is already built in. This is a thing that already exists with labelers, um, and the group itself can act as its own labeler. Admins can approve labelers that align with the community values, and then we can layer on that by uh moderating within the specific spaces that they're in.
And then individual members can still add their own lay labelers or muting or anything like that on top of that so that they see exactly the stuff that they want to see and nothing else. The advantage here for using this wrapper pattern means that there's an implicit moderation built into the group itself. You can remove a wrapper and that content is hidden from the community, but the user's data is still intact. You can remove a membership proof and that revokes access without actually destroying the rest of the uh access to the group. Uh you can delete content, which leaves a tombstone preserving conversation structure.
Um, and then there's options there for you know appealing those moderation decisions. You can, you know, maybe just soft delete those things and then bring them back so that they can be appealed easily. There's still a lot to figure out. I think that private groups is probably the thing that I'm most interested in. Um, it's important not just, you know, because not every group needs to be available. You know, what if it's just your friends' group chat? You know, that doesn't necessarily need to have everything visible online, but it's also important for community safety. I participate in a lot of parenting groups online because I am a mom of three young kids, and none of us want pictures of our kids shared on the internet.
Um so having that privacy is extremely important. Um, group creation, uh, I've been talking to Bailey a little bit about that today, uh, where there are some really awesome ideas on how to make this easy because you don't want to necessarily tell somebody all right if you want to have your own community first set up a PDS like that's not the way to sell anything to anybody um so making that easy and frictionless when a user's using it is very critical and then finally how do we make this interoperable um not just with app proto but what about the activity pub like why would the decentralized communities need to be separated we can bring them together within their own identity so are a group's important what becomes possible so then this means that the whole reason why this is important is the day the playlist that somebody creates on Spotify that's owned by the friend group that's not necessarily owned by the by Spotify itself.
A study group can have their own shared notes belonging to students discussion forums can say stay with the author and not with uh with the individual or not with the not with the group the platform I think that decentralization is not just about personal data sovereignty but it's also about collective data sovereignty a community's shared knowledge and history and spaces should belong to the community forever not just while they're on the platform that they're on so the question the answer to who owns the group chat the group should I love to talk more about this if this is a thing that you're interested in.
I've got some resources linked here you're welcome to check out and I've also got some links to all of these community references I'll post this I guess maybe in Discord and Roomi chat I've got a repo for all of this symbol okay yeah we'll put it somewhere on the internet and you'll be able to access it. But thank you to keep the 15 minute offset if you want to take a few questions. Oh god oh god any questions any questions you want to talk about your thoughts on private group oh um yeah I think I'm not I'm very interested to see what comes out people on the one read your question oh yes uh thoughts on private groups um I think that that data should not be stored in a PDS I'm very excited to see what happens with a lot of the permissioned data and what comes out of that to see what that forms um that's not a thing that I've spent a lot of time doing but it's a thing that I definitely want.
Anyone else the question was when you are setting roles can you set custom roles? And the answer is yes you can set custom roles with different permissions that are set up and you can define what permissions as an app view provider of which ones should be created. It's very complicated honestly it's it's probably overcomplicated. But yes that is that does exist thanks. So theoretically also custom role names oh yes for sure custom role names there's some defaults member and admin and then from there the world is your oyster yeah I think I think that identity um actually commentary might be not like how much you hear and how much for you now yes so the question was about identity and the different roles actually verification oh verification of the individual oh um oh interesting uh we believe handles are real people that's true I I'm a I'm a firm believer that like a handle is like pretty if you own I own Britneyelick.com and there's nobody else that can really take that uh without having access to my DNS which is a different problem um but uh yeah I don't really have strong opinions though on like verifying individuals I think that that could probably be the the something that the group decides how they want to handle it.
Awesome thank you very much for taking a few questions