Brittany Ellich 1:16 I'm a staff engineer, staff software engineer at GitHub, and promise I know how to use computers. 1:21 I'm an @proto enthusiast, why I'm here, and also a member of the Chronically Online, and really, really love online communities. 1:34 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. 1:41 I co-host the Overcommitted podcast. 1:44 I'm going to be recording this weekend. 1:45 If you want to talk about your experience here, let me know, because we're going to do a special episode. 1:49 And I also brought some stickers that I'll put out once I find where all of the stickers are congregating. 1:56 So a few months ago, I had this thought that I thought was a brilliant idea. 2:01 I was like, why isn't there a Goodreads or like a Letterboxd on @proto? 2:05 This does not exist yet. 2:07 And so I started building this app called Collective, which was sort of, you know, the same thing. 2:14 Turns out it did exist. 2:16 And there's quite a few of them. 2:18 One of them in particular that I really like is called popfeed.social. 2:22 They did this way, way better than I had done, and I highly recommend you check it out if you're interested in something like that. 2:31 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. 2:42 So we like to read technical books together. 2:44 If you are also interested in reading books, let me know. 2:48 You're welcome to join. 2:49 Right now we coordinate on Discord. 2:52 And Discord is great, but I really wanted Collective to help, you know, facilitate the book club situation. 2:58 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. 3:07 So I was like, you know what? 3:08 Wouldn't it be nice if we could solve this problem? 3:11 Discord now owns our member list, it owns our reading history, it owns every single conversation we've had about every single book. 3:20 If Discord decides to change their terms, which I'm sure they would never do, then we lose all of that. 3:29 The entire history of our entire community can just be erased. 3:33 And that's a real bummer. 3:34 It's not necessarily just a Discord problem. 3:38 This is also a platform problem. 3:40 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. 3:56 And when the platform disappears, that means the community disappears too. 4:01 You got Google+, MySpace, Twitter, what, what else? 4:04 Once existed of it, all gone, along with every single conversation and every shared memory and piece of community knowledge. 4:15 So I think that @proto did a really great job of solving personal ownership. 4:19 Your posts live in your repo. 4:22 Your social graph is completely under your control. 4:24 And your identity is portable to wherever you want to bring it. 4:27 But there's still an open question one. 4:30 Question about what about shared things? 4:34 So what about book clubs? 4:35 Or community projects? 4:37 Or the group chat itself? 4:39 Does that belong to the individual or does it belong to the group as a whole? 4:46 So these are the design questions that I was thinking about going into this, 'cause 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. 4:57 I want it to exist on its own and not be controlled by whichever platform we are working in. 5:03 So the first question was, where does the data live? 5:07 You know, is this a shared PDS? 5:09 Is it someone's personal repo, whoever created the group? 5:12 We'll get into that. 5:13 That can be problematic. 5:16 Yeah. 5:18 Yep, somebody is familiar with this problem. 5:22 And then who controls it? 5:23 Like, does the person who created the group get automatic full control over that group forever? 5:29 No, absolutely not. 5:31 Like, that's crazy because then, you know, anyway, we'll get into that. 5:36 And then how do members themselves relate to the group? 5:38 Do they have to sign up through whatever group mechanism they're in? 5:42 What determines how a group, how an individual controls their own affiliation with the group? 5:48 And so those are the things that I brought into thinking on this problem. 5:52 And I do want to give some shoutouts to a ton of folks in the community that have already been thinking a lot about this and that their work has gone into what I ended up building. 6:03 So Brian Newbold, I just met you this morning, sorry I'm stalking you online. 6:10 But he had some great leaflets on this. 6:14 Nick Jarochinis, I don't think he's in here, but I technically work with him, is how he's been introducing me today. 6:21 We work at GitHub together and I've been bugging him. 6:24 He's had some great stuff. 6:25 Mary, the front page team, Erlend, who I don't believe is here, and then also I wanted to give a shout out to Amelia, who has been very patient at answering all of my questions here. 6:38 Yes. 6:39 So I've been collecting these and I built a thing, uh, with that. 6:45 So App Proto's philosophy is really your data, your repo. 6:49 That works for personal data, but not so great for shared state. 6:54 It doesn't really fit neatly into this one person's repo. 6:57 So how do we extend that ownership model to collective data without losing what it is that makes App Proto so special? 7:06 And this is the approach that I came up with, which is opensocial.community. 7:12 It isn't really the answer, but it's an answer, and you know, you can try it out and see if this is a thing that fits you, or build your own thing. 7:19 That's the beauty of this community. 7:23 It's group infrastructure. 7:24 It's not itself an app view. 7:27 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. 7:38 And I'm going to walk through a couple of the design decisions that were made. 7:41 So the first one, which is the most important to that, that ownership question is, uh, groups are stored as @proto identities themselves. 7:50 They're their own DID. 7:52 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. 8:03 Membership is a two-way handshake. 8:05 Not anybody can just join any group. 8:07 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. 8:15 And then finally, there's a wrapper pattern to have shared content that makes it easy to show within an app view without necessarily overloading that repo with a lot of extra stuff. 8:28 Stuff. 8:30 So what does that look like? 8:32 Every group gets its own DID. 8:33 So for example, my book club is its own DID, web/overcommitted.dev. 8:40 It has its own handle, its own repo on a PDS, and then group-shared data is stored within that repo. 8:48 That makes 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. 8:55 It's not a row in some app's database. 8:58 It's an entity with its own identity. 9:00 And just like personal DIDs, that entity is, at least hopefully, portable. 9:11 And then the infrastructure, instead of being an app view itself, this is what the infrastructure looks like. 9:16 So I can have Collective, which is— has access to opensocial.community. 9:22 But then you all can also have your own other apps that have access to it. 9:27 Any app you can connect to it, um, and you can also have, you know, your podcast app or your reading app or multiple of those if you want. 9:35 Maybe you want to support multiple— you want to support Blue Sky and Black Sky and Eero Sky all from the same thing to have one group, then that's totally reasonable. 9:44 Each app gets its own namespace within OpenSocial. 9:47 So Collective stores app.collectivesocial.group.list lexicons, and then other apps cannot create other lexicons within the group unless they have access to those namespaces. 10:03 That prevents other apps from overriding 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. 10:12 Same group. 10:13 Different data, and no conflicts. 10:16 The group there is the shared context then. 10:18 And then the group gets a decision on which apps it also has access to. 10:23 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— or that app from having access to that group. 10:34 The next one, so membership as a two-way handshake. 10:37 This means that there is a membership record in an individual's repo, and then also in the group repo. 10:42 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 membership record. 10:54 That means that an individual can leave any time 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. 11:11 And that's a nice opportunity for privacy here, too. 11:14 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. 11:30 And then the wrapper pattern. 11:31 So in this case, this is for user content. 11:35 The group creates a wrapper around that content. 11:39 Bob, in this case, will own the book review. 11:41 They create the book review and they own that content, but then the group owns a wrap— a wrapper around that content. 11:47 That means that the group has access to remove that content from the group if needed. 11:52 And then Bob, if he decides to leave the group, he still owns his own book review, which is nice. 12:00 Then the group repo also ends up being an index of references and not necessarily a copy. 12:05 Of all of the content, which can also be, uh, a bit problematic. 12:11 And then this is what it looks like end to end. 12:13 So you register a— uh, an app, in this case Collective, as an app view with opensocial.community and get an API key, which can be used for authentication. 12:24 And then you can create your group through those Collective APIs. 12:29 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. 12:36 But we'll get to that. 12:38 Members join through that two-way handshake, which again can be within the app view if you'd like, or through opensocial.community. 12:44 It has its own UI for that. 12:47 And then members contribute content via their wrappers, also through APIs. 12:52 They support community creation, membership management, namespace record storage. 12:58 Because I work in the 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. 13:11 And because I don't want to just talk about it, I'm going to show you a little demo through images. 13:16 So this is what it actually looks like on the web. 13:19 Both OpenSocial and Collective are up. 13:21 I, like I said, don't use Collective. 13:23 It's not very good. 13:24 But OpenSocial is up, and I've spent a lot more time looking at this. 13:27 So this is how you can register a developer app. 13:29 You can go in and initially set, like, what are the lexicons that you want groups to be able to manage? 13:35 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? 13:43 So you can have a completely open one or say like, eh, let's say that only admins can delete things or something. 13:51 Next, you can view the group itself, the list of members. 13:56 You can search through it, see who has registered with this group. 14:01 And also have different community settings. 14:05 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 approval, or whether it's private, but asterisk on private because everything's in a repo in @proto. 14:20 So private doesn't really exist just yet, but it will. 14:25 There's some very smart people working on that problem. 14:29 These governance decisions are explicit and visible. 14:32 They're not buried. 14:32 They're just all stored within, within the group's repo. 14:38 And then finally, there's app permissions. 14:40 So a community admin can say, I want access to this app, but not this one within this group context. 14:47 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. 14:54 Maybe we can just create like a Steam or Roblox type app store where you can access all of these different apps. 15:02 You could access Collective or Blue Sky or Black Sky or Streamplace all within one space. 15:07 And you can say these are the places that my community is gathering so that it's easy to gather across different contexts. 15:17 And then finally, Collective. 15:18 So you have the ability to discover new communities, search for them, and view them. 15:24 Each community has its own handle, membership status. 15:29 You can see here we've got overcommitted.dev, which is the Overcommitted Book Club, which I already have access to. 15:34 And then a few of the book club features on Collective, because why would I build just one app when I could build two? 15:41 Here's what the Overcommitted group actually looks like. 15:44 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. 16:06 This is the most recent book that we read, Writing for Developers. 16:10 Cynthia Dunlop and Peter Sarna are both very active on Blue Sky, 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. 16:25 Um, and then, yeah, so the full app is available at opensocial.community. 16:29 Um, it's— if you're interested in building on it, let me know, 'cause I would love to see how this actually scales across other, you know, other apps. 16:37 Um, like I said, there's a lot of features that are built in already that are probably overkill, but— uh, and then we also have Collective Social, which I think is mostly just for book club organization. 16:49 But we also have some movies, and some other ways to collect podcasts and things like that. 16:54 So, yeah, that one is in alpha, I will say, as a way of saying it's not quite ready. 17:03 But what about, so this brings me to some important points about groups. 17:07 So specifically about governance and moderation. 17:10 So one of the things that Brian brought up in one of his posts, 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. 17:26 And I think that that goes in multiple ways. 17:28 That's not just the group itself, it's the platform that actually allows the creation of the group. 17:36 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, but that doesn't— that means that that person has absolute power over the group. 17:56 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. 18:02 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. 18:12 So what shared groups on App Proto can enable for us is we can have different governance patterns. 18:18 What does that actually look like when we have control over it separate from the platform? 18:23 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. 18:34 Different communities are gonna want different ways of managing themselves. 18:39 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. 18:46 And then moderation is the other spot that I've been, uh, looking at this from, which is a layered moderation approach. 18:54 This is already built in. 18:55 This is a thing that already exists with labelers. 18:58 Um, and the group itself can act as its own labeler. 19:01 Admins can approve labelers that align with the community values. 19:04 And then we can layer on that by moderating within the specific spaces that they're in. 19:10 And then individual members can still add their own 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. 19:21 The advantage here for using this wrapper pattern means that there's an implicit moderation built into the group itself. 19:29 You can remove a wrapper and that content is hidden from the community. 19:33 But the user's data is still intact. 19:35 You can remove a membership proof, and that revokes access without actually destroying the rest of the access to the group. 19:45 You can delete content, which leaves a tombstone preserving conversation structure. 19:50 And then there's options there for, you know, appealing those moderation decisions. 19:54 You can, you know, maybe just soft delete those things and then bring 'em back. 19:58 So that they can be appealed easily. 19:59 There's still a lot to figure out. 20:03 I think that private groups is probably the thing that I'm most interested in. 20:07 It's important not just, you know, because not every group needs to be available. 20:12 What if it's just your friends' group chat? 20:14 You know, that doesn't necessarily need to have everything visible online, but it's also important for community safety. 20:19 I participate in a lot of parenting groups online 'cause I am a mom of 3 young kids and None of us want pictures of our kids shared on the internet. 20:28 So having that privacy is extremely important. 20:32 Group creation, I've been talking to Bailey a little bit about that today, where there are some really awesome ideas on how to make this easy, because you don't wanna necessarily tell somebody, alright, if you want to have your own community, first set up a PDS. 20:46 Like, that's not the way to sell anything to anybody. 20:50 Um, so making that easy and frictionless when a user's using it is very critical. 20:56 And then finally, how do we make this interoperable? 20:58 Um, not just with @proto, but what about the ActivityPub? 21:01 Like, why would the decentralized communities need to be separated? 21:04 We can bring them together within their own identity. 21:11 So why are groups important? 21:13 What becomes possible? 21:14 So then this means that The whole reason why this is important is the playlist that somebody creates on Spotify, that's owned by the friend group. 21:24 That's not necessarily owned by Spotify itself. 21:28 A study group can have their own shared notes belonging to students. 21:32 Discussion forums can stay with the author and not with the individual, or not with the group, the platform. 21:42 I think that decentralization is not just about personal data sovereignty, but it's also about collective data sovereignty. 21:49 A community's shared knowledge and history in spaces should belong to the community forever. 21:54 Not just while they're on the platform that they're on. 21:58 So the question— the answer to who owns the group chat? 22:02 The group should. 22:02 I'd love to talk more about this if this is a thing that you're interested in. 22:08 I've got some resources linked here. 22:10 You're welcome to check out, and I've also got some links to all of these community references. 22:15 I'll post this, I guess, maybe in Discord? 22:19 In Roomie chat? 22:20 I've got a repo for all of this. 22:23 Ooh, Sembel? 22:24 Okay, yeah, we'll put it somewhere on the internet. 22:26 You'll be able to access it. 22:30 But thank you. Speaker B 22:38 We're going to keep the 15-minute offset if you want to take a few questions. 22:46 Oh, God. 22:47 Oh, God. 22:48 Any questions? Brittany Ellich 22:49 Any questions? Speaker B 22:51 Do you want to talk about your thoughts on private groups? Brittany Ellich 22:55 Oh, yeah, I think I'm not— I'm very interested to see what comes out. 23:01 Oh, yes. 23:02 Thoughts on private groups. 23:05 I think that that data should not be stored in a PDS. 23:08 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. 23:15 Um, that's not a thing that I've spent a lot of time doing, but it's a thing that I definitely want. Speaker B 23:19 Anyone else? Brittany Ellich 23:35 The question was, when you are setting roles, can you set custom roles? 23:38 And the answer is yes, you can set custom roles with different permissions that are set up. 23:43 And you can define what permissions as an app view provider of which ones should be created. 23:51 It's very complicated. 23:53 Honestly, it's, it's probably overcomplicated, but yes. 23:55 That is, that does exist. 23:57 Thanks. Speaker B 23:57 So theoretically also custom role names. Brittany Ellich 24:00 Custom. 24:01 Oh yes, for sure. 24:02 Custom role names. 24:02 There's some defaults, member and admin. 24:04 And then from there, the world is your oyster. 24:07 Yeah. Speaker B 24:07 I have a question about identity. 24:12 Um, there's a lot of different perspectives and thoughts on identity. 24:14 I'm curious how you're thinking about identity versus role. Brittany Ellich 24:36 Yes, so the question was about identity and the different roles. 24:43 Oh, verification of the individual. 24:45 Oh, um, oh, interesting. Speaker B 24:49 We believe handles are real people. Brittany Ellich 24:54 That's true. 24:55 I'm a firm believer that like a handle is like pretty— if you own— I own brittanyellec.com and there's nobody else that can really take that without having access to my DNS, which is a different problem. 25:07 But yeah, I don't really have strong opinions though on like verifying individuals. 25:13 I think that that could probably be something that the group decides how they want to handle it. Speaker B 25:19 Awesome. 25:19 Thank you very much for taking a few questions.