Baldemar Motomochi 1:44 Awesome. 1:44 All right. 1:46 And should be— so my name is Baldemar. 1:52 I help run Furry List, which is a feed, which is a service that provides feeds for the furry community. 2:02 And let me see here. 2:03 I completely forgot how to actually do this. 2:08 Right, there we go. 2:10 Speaker notes. 2:12 Awesome. 2:13 All right, so we're good. 2:14 So I have a question for you all. 2:19 Let's see if this works. 2:21 Awesome. 2:22 So what makes you and me different from strangers? 2:28 So raise your hand if you're a developmental biologist. 2:33 Raise your hand if you're Mexican. 2:36 And now raise your hand if you care about the open web. 2:39 That should be everyone. 2:40 Yeah, okay, that's what I thought. 2:41 All right, so we have that shared identity and that— those shared values, right? 2:48 As a— and we are sharing this space here as a shared social space based on those values, right? 2:56 We have that common foundation of trust to build relationships from. 3:00 And I'm interested in how exactly we can actually translate those relationships into the online space in a way that actually reflects how they exist in the real world as they exist. 3:14 And this is what I've kind of been wondering as I have been helping out with FurryList. 3:20 So if you don't know, FurryList is a service on Bluesky that provides feeds for the furry community. 3:26 But we don't do a global feed and we don't just rely on hashtag feeds, right? 3:30 What we do is we manually curate every single user that wants to become a member of our community, of our feeds. 3:40 So we've done that for about 64,000 people now. 3:44 We've started doing that early on in Blue Sky History when Otter was in charge back then, during our founder. 3:50 Now Kev has been the lead, and we have grown quite a bit since then. 3:57 And I'll just show you real quick how it works. 3:59 I mean, it's nothing too complicated. 4:01 A user follows us, right? 4:03 And after that follow, they go into our review backend. 4:07 Now the follow itself is a signal of intentionality, right? 4:12 They have signaled to us that they would like to join our community. 4:16 And our review backend, which looks a little something like this, is a way for us to check first off whether they are furry. 4:25 And second off, whether we believe that they would be a good addition to our community. 4:30 So there is a manual curation to our community at every level. 4:34 We— every single person within our community has been seen by us and we have made a manual decision about their belonging within our community. 4:44 Every judgment here is intentional. 4:48 So this is a classic bidirectional membership. 4:51 You know, like the user is part of the community because they wish to be. 4:54 And the community allows someone to be part of their community as well. 4:58 This is how most online communities work today, you know. 5:03 But when we do this, we actually create what I'm gonna call a trust domain. 5:09 The user, by being part of the community, implicitly, at least initially, trusts us to make good decisions for the community. 5:17 And then FurryList then through this follow record says that we believe that they are also a trusted member of the community. 5:29 And, you know, this is how most online communities work. 5:32 But there are a few issues here that I think I've— that I started to think about. 5:40 The community depends on us for infrastructure and their existence. 5:45 Now, to be clear, The community is defined through public records, right? 5:49 Like we follow them. 5:49 The follow is a public, is a public record. 5:51 But we're the ones who provide the feeds for FurryList. 5:55 And this is— but why is that? 5:58 Well, let's see. 5:59 Let's go through, through what happens when we revoke a record, right? 6:04 I mean, if we revoke a record, then there is no proof that we have vouched. 6:09 There is no historicity to the community when it's gone. 6:13 It's really difficult to prove that you were part of the community at a protocol level. 6:18 And God forbid, if we stop existing, there is no proof that the community ever existed in the first place. 6:27 There's no history or path forward. 6:30 Everything has to be rebuilt from scratch. 6:32 The community itself dissolves. 6:34 I mean, this is as if a social media site, you know, like were to disappear, like it, You might be able to have a few friends to find, but the entire social graph itself is gone. 6:43 Right. 6:46 So I divide these problems into two different domains. 6:51 First, the trust surface, the trust domain lives in the records that we control. 6:56 And if we— and they don't exist independently of us. 6:59 Right. 7:00 And secondly, there is no easy way to organize, find, or navigate what others build on our work. 7:06 Again, it's not impossible. 7:08 But it's— but there's no surface through which to find new things. 7:13 We become the default space, and we don't want to be the default space. 7:19 Like, we provide default fees, but we don't want to do extended governance, uh, uh, because that enhances the surface through which conflict can happen with the community, right? 7:29 We have a limited mandate. 7:31 Our mandate is to vet members of the community. 7:35 If we start doing additional governance on top of that, that is additional surfaces through which we can come in conflict with the community. 7:41 And we put so much effort into creating this community. 7:45 We don't want it to go all to waste because of a mistake that we made. 7:50 Because again, if we make a mistake and things collapse, it cannot exist independently of us, right? 7:56 These are connected issues. 7:59 And so thankfully, the permission— I'm sure that a lot of you guys have been looking at the permission data infrastructure proposal. 8:08 Proposal, or, you know, like rough proposal that Danny has been doing, that I think that actually solves one of the issues pretty cleanly. 8:15 And that's ownership. 8:16 So essentially we have a spectrum here from private to public data, right? 8:21 The protocol itself was designed with public data in mind. 8:26 And, you know, the extreme end of private data would be end-to-end encryption where it's two parties who share a trust boundary, which is probably the smallest trust boundary you can make. 8:38 Now, permission spaces are things, for example, like Discord, like a private subreddit or a private forum, right? 8:45 These are spaces where there is a shared domain of trust. 8:53 You know, like people within the Discord community can see everything within the community, but they can't— but people outside of it cannot. 9:01 So this is— this, I think, is where the importance, the interesting The interesting part for communities lie. 9:10 And when thinking about ownership of these trust domains, I think that Blue Sky has come up with a correct solution. 9:20 So here, again, bidirectional follows. 9:23 Each record here lives in each author's repository, which is how follow records typically work. 9:30 However, within the permission data infrastructure draft so far, There is a signed attestation that the ACL maintainer, the access control list maintainer, writes to the user's repository. 9:43 This is signed and this is verifiable independently of whether the ACL maintainer wants to or not, and it lives in the user's repository. 9:50 It exists independently. 9:51 Right? 9:52 So, this becomes, in a way, a historical fact. 9:56 Even if there is a retraction of the credential, this credential still exists and it exists independently of the ACL maintainer. 10:06 Now let's think about what Furiolist does today compared to the ACL maintainer in the permission spec. 10:12 So we curate a membership list. 10:17 They also curate a membership list. 10:19 We do vetting. 10:20 They also have to do vetting of some kind. 10:22 We use followbacks as proofs. 10:24 Credentials in this scenario are proof. 10:26 We use unfollows as removals. 10:28 You can also do credential withdrawals, stop admitting by not issuing any new ones. 10:33 We already kind of act like an ACL. 10:35 We just don't issue any credentials yet. 10:39 So this is how things existed before. 10:44 Again, no historicity. 10:46 But think about how things look when we actually use these verifiable credentials. 10:53 A retraction really is not like, it's not an erasure. 10:59 I think about it kind of like how, you know, like a scientific journal retracts a paper. 11:05 A retraction is a statement that says we made a mistake, we no longer believe this statement that we made is true, but the paper is still available. 11:12 Similar here, it's a statement like a labeler, right? 11:16 The history of the decision is preserved and the governance that results from it becomes auditable. 11:24 If we disappear, in theory, the history of the community survives because the credentials still exist. 11:33 They exist within the user repository. 11:35 In theory, a path to credential— to recovery is possible. 11:41 But the important part is that it's possible. 11:44 That does not mean that it will happen. 11:50 Without a structure to reorganize around, without a matrix that the community exists in, the community still becomes a diaspora, right? 11:59 If we're just defined by the ACL, then we're still back to square one if we disappear and if our feeds disappear, right? 12:06 There's nothing to reorganize around. 12:09 Now, I think that credential system solves the first part pretty nicely, but But what about the second part? 12:15 What about the structure itself? 12:19 So to do this, I would like to talk about one of my favorite feeds, which is the Science Feed. 12:25 And in many ways, the Science Feed does similar work to FurioList. 12:30 The Science Feed manually checks ORCIDs. 12:33 They do staff page checks to check whether something is— whether an account is associated with a professor. 12:40 They check publication lists. 12:42 They really do the fieldwork to verify whether someone is part of their, you know, scientific community. 12:49 This has created like an extraordinary trust surface of thousands and thousands of real-world scientists. 12:57 It really is just an incredible undertaking what they have been able to make here. 13:02 But like, think about like what results from this. 13:07 It's just one feed, and it's a good feed, and I love using that feed. 13:12 But a feed is not a space. 13:14 It's one of many different conversations that can happen. 13:18 I mean, I want to talk, you know, I'm a developmental biologist. 13:20 I want to talk about like some help with like my zebrafish experiments or how to use a particular microscope or help with grant proposals, things like that. 13:28 This would be an amazing trust surface to use it on because I know that the people that are here know what they're talking about. 13:34 But there's nothing there to go to. 13:37 And it's not because of the protocol. 13:41 This is publicly accessible. 13:44 You can make it technically. 13:46 And, you know, like you can make that space if you wish, but there is no way to find it. 13:50 Right. 13:50 There's no way to find— there's no way to find what has been built off of this infrastructure here. 13:58 No matrix through which the community itself can exist apart from what the maintainer itself provides. 14:04 So why does this happen? 14:09 I think this is because of something that we should all be familiar here when we think about the app protocol, and that's the tendency towards centralization. 14:17 People want to be where the people are, you know, like, the distribution is not a good user— that is not a good user experience. 14:25 During the beginning, there were many, but because everyone wants to be in one place where everyone else is, everything converges to to one maintainer, the landlord. 14:34 Same thing that happened with, you know, like, you know, the online social web as well. 14:39 Everything converged because people want to be where the people are, you know. 14:42 And I think that a lot of people kind of ask the question, like, how can we fight this? 14:49 I don't think that this is really something that we can or should fight. 14:53 It's not a good user experience to do so. 14:56 Bluesky and the app protocol so far has been successful precisely because it it doesn't fight it. 15:01 You know, Bluesky itself is the entryway into the app protocol, but it does not make you make a choice about which app you will use because Bluesky is the default and it's what everyone else uses. 15:12 And from there you can make the choice to exit if you want to. 15:16 I think that we can do something similar if we act with communities by giving that centralizing force a limited mandate. 15:26 And by making community infrastructure independent, like credentials, and then make community infrastructure discoverable from the community definition, from what something like Furry List creates. 15:40 So if we— if we allow members of a community to say, define a governed virtual space, which I'm going to call a venue here, through some kind of record, then that record becomes a link between the infrastructure of the community and the definition of the community, the credentials of the community. 16:02 And this opens up a ton of affordances. 16:06 Governance now has a surface for disagreement. 16:10 There's two governances here, right? 16:12 There's not just the one governance for us, which means that if we make, if we make a mistake or something the community disagrees with, there is a surface here through which that disagreement can surface and be absorbed, not necessarily the member level, but at the actual spaces where people exist. 16:29 And this can create back pressure. 16:34 So the relationship between these two is now surfaceable at a protocol level, which means that, that apps and app user apps can surface this connection between the community infrastructure and the community definition itself. 16:52 And because this is emergent from the community itself and the community members, plurality kind of becomes the norm. 17:02 There are many spaces that are run by self-selected stewards who have decided they care enough about the community to create these spaces. 17:10 That creates different spaces for different needs for the community with different types of governances. 17:18 And members can use the ones that they resonate with the most. 17:24 And this topology emerges from the users. 17:27 It does not emerge from, you know, furry lists or, you know, whoever defines the community itself. 17:32 The credential is putting up all of these different spaces. 17:40 A single community can have different spaces run by different operators, different governances. 17:45 And yet they all here share a trust domain where the credential is the unifying factor. 17:55 Users then can route their posts to different places through, for example, if they're defined by a record, TID is metadata. 18:04 Let's say, for example, it might as well just be like a random hashtag at the end of the post. 18:11 And this can be used as metadata, as information that defines a space within the public network, right? 18:18 Because the metadata is unique and it does not convey any information. 18:23 The information emerges from how people use it. 18:26 And this is actually something that I would like to— that I'd like to shout out for with Nighthaven, who's a Blue Sky fellow, I believe, has done some good work in kind of exploring this area. 18:39 He calls it a mezzanine. 18:40 They call it a mezzanine, which I think is a really apt description because a mezzanine shares a space with the ground floor, but there's an intentionality to going up there. 18:50 It's a shared frequency where people can congregate that still exists within the public network. 18:57 Like this, kind of like this, you know, like it— because these all are connected through the, through the community definition, each one is independently operated. 19:10 So they are separate governances, separate stewards, but are all connected. 19:15 So this is what, this is what it could look like, you know. 19:18 The roster kind of gives— the roster gives out credentials to the community members. 19:23 They can make venues through which, through which members can then self-sort and use the ones that they resonate with the most. 19:31 And yeah, each node in this graph is an independent agent that has complete, complete independence and complete agency within their own domains, but cannot, cannot directly affect the others. 19:47 But they can affect the others collectively through back pressure from the bottom up. 19:52 For example, if a venue, you know, if a venue's governance acts badly, well, they're operating in a public network with public data, right? 19:59 they can make a different one. 20:02 And they don't have to make a different one in order to change the governance, but the mere threat that they could influences venues to act in accordance to what the community wants, right? 20:14 That is a back-pressure mechanism of action. 20:16 And this also works for the roster. 20:18 If the roster makes a bad decision, if they admit someone they shouldn't have, or they, uh, if they admit someone they shouldn't have, or they retract trust from someone that they shouldn't have, each individual venue here can override that decision and say, you made a bad decision. 20:33 And if this happens throughout the community, that is a backpressure mechanism saying, you are doing— like, you were wrong. 20:41 The community disagrees with you. 20:42 It is layered backpressure mechanisms. 20:46 So are we done here? 20:48 I guess we're done here. 20:49 I guess I can just go home. 20:51 Oh, right. 20:53 So, communities cannot simply exist in public, especially when they share a trust boundary. 21:02 This is a problem to exist only in public for communities. 21:06 If everything is surface level, there's little opportunity for depth of conversation. 21:11 Even if in the science community, we have created this amazing, this amazing surface of trust, But there's little meaningful way to take advantage of it if every conversation happens in public. 21:22 You know, every interaction within these spaces is done in front of imagined audiences, people who you think might be looking at. 21:30 And that depth, that community depth, I believe, is important to really take the full advantage of this trust that we're building. 21:43 And, you know, like I said, with the permissioned data system that Bluesky is building, we're already acting kind of like an ACL. 21:52 So then the question becomes, like, what if we just become the ACL maintainer? 21:59 What if we just become the system that decides who does and does not gain access to permissioned data? 22:08 Well, this means that not only could posts be made public or private to our community, but because venues exist as defined as records, individual venues can also be either public or private, or even individual subspaces within them. 22:27 The outside might see all of First Sky. 22:30 They might see some of the First Suitmaker spaces if there's like a sale going on for like a fursuit or something like that, but they don't see it all unless you're part of the permission space of the community. 22:43 Once you're in this permission space, you can see, for example, that BaeFurs exist, or that StemFurs exist, who did not want to share what they were talking about in public. 22:53 You can join in with the advice for fursuit makers and see, you know, learn how to make a fursuit for yourself, or the first, you know, if you haven't, you you don't have any experience with it. 23:02 Even within these boundaries, you can create another one if you so wish. 23:06 You can create another roster that's just for, like, for example, for realist moderators. 23:09 And every— this can— this, this is just simple set logic, right? 23:19 The design space is modular and any kind of set logic here is possible because, I mean, we have the fundamentals here. 23:26 We have the boundaries. 23:28 And we have the spaces within them. 23:33 So if, however, if you're thinking about how the permissioned data system would work here, you might have noticed something. 23:40 If the roster here has full control over the community's ACL and their permission data, and it can revoke protocol-level access to the community data, then it's kind of acting like what the landlord was acting like, right? 23:55 They have full control over the community's permission data. 23:57 So how— so haven't we just recreated the landlord essentially? 24:02 And this is where I think the app protocol can really help, not necessarily at the protocol level, but in the ability to go off protocol. 24:13 So say that— say that we at Furioos retract a credential for someone. 24:18 We say that we no longer trust them as a member of our community. 24:22 As a result, they lose protocol-level access to the community data. 24:26 There is no fix for this, and I don't think that there should be. 24:29 But let's say that a single venue disagrees. 24:33 In this case, Fursuit Makers, their governance still vouches for them. 24:36 They still think that they were a valuable member of the community and that we were too harsh in their decisions. 24:40 At the protocol level, there is no fixing this. 24:43 But consider what happens when these live in an app, an app that must govern or moderate what happens within them, you know, then something interesting can happen. 24:58 If the first— if First We Make This can send a voucher signal within this permission space and the app view has access to that space, then the app view can act as a mediator of that venue's governance. 25:12 They can say, well, yes, we have access to all of this. 25:16 And the roster says, you know, that they do no longer trust them. 25:19 But in this particular social space, in this particular governance space, they still trust them. 25:28 So we can still serve that content to that user and allow them to interact in this particular space, but only in that space. 25:37 It's a window into the permission space, and it only exists outside of the protocol. 25:44 It exists because the app view is the trusted mediator of governance between all of these. 25:53 So this is what— this is the system that I call composable trust. 25:59 Each role here, each part here has a particular role. 26:03 The roster can issue— decides who belongs, but it does not decide what the community looks like or how they govern themselves. 26:14 The venue can govern their space. 26:16 They can design their space and set the rules and set what the space is about. 26:21 But they can't yield. 26:22 They can't make credentials. 26:24 They have to define themselves based on an existing community definition. 26:29 The app view assembles the view, enforces the ACL, enforces trust, mediates trust, mediates the venue's governance. 26:39 But it holds no data. 26:40 It cannot make— it does not make credentials. 26:42 It has no governance authority in and of itself. 26:47 It's powerful, but it's still replaceable, just as the rest of these. 26:51 And the members themselves are the ones who hold all the cards. 26:56 They own the data. 26:57 They hold the credentials. 26:59 They choose which community definitions to be a part of. 27:01 And within those community definitions, within that trust domain, they choose where they want to be. 27:08 And each role here is auditable by the others, and each one is replaceable without destroying the rest, without destroying the community. 27:18 So compare this to how platforms and online communities exist nowadays. 27:23 The platform is at the top. 27:24 They control everything below. 27:27 The admin for a particular space is usually one person that controls the space. 27:33 Is in control of the entire governed space. 27:36 The mods, they might delegate some authority, you know, to the mods. 27:41 They're still ultimately at the discretion of the admin and the users are at the very bottom. 27:46 They are at the— their existence within this space is at the discretion of all the layers above. 27:52 And if one of these fails, everything below it fails. 27:56 Now consider how this system works. 27:59 This is now a system of roles and relationships. 28:02 The community structure itself emerges from the bottom up from the users. 28:06 Each node here can be audited by the others. 28:10 If any one of these systems violates the community's trust, they can be replaced. 28:17 And if these relationships are surfaced well, if the community structure is navigable, then The community can survive any one single failure of these. 28:28 Nobody here holds all the power for our community. 28:31 The community is built from the bottom up by the people that inhabit it. 28:38 So I think that, I think that this is a good structure for a solution. 28:43 Remember this diagram that I showed you here? 28:48 So this is what a single community looks like. 28:49 This is what Furry List might look like. 28:52 But consider what this could be. 28:55 This is what communities could look like: a navigable trust graph with overlapping affinities, overlapping relationships that give structure to communities in a way that no platform, no AI, no algorithm could make because it is built from the bottom up by the community and who they trust. 29:13 This is a trust graph that is built by all and owned by none. 29:20 So if you would like to help build this, I have a— I have a more technical proposal up on Leaflet if you're interested in reading that. 29:31 Otherwise, if you are interested in helping build these kinds of sustainable communities, please do reach out. 29:37 I mean, I'm super interested. 29:38 I'm hoping to get some schemas out after this conference and start building something something real. 29:46 I'm not a coder, but I'm really excited to see what we can make with this infrastructure and with the protocol. 29:57 Yeah, thank you. 30:11 Thank you so much, Baldemar. 30:13 We have time for maybe one question. 30:15 Is there anyone in the audience with a question? 30:18 Yes. Speaker B 30:23 Really interesting, thanks. 30:24 Do you have a sense for which primitives might be missing from the protocol right now to support this? 30:35 And which are like already there and useful? Baldemar Motomochi 30:44 So really, like, the biggest thing that is missing is the permissioned data infrastructure, the one that has been proposed by Daniel, and the ability to connect infrastructure to existing, like, lists, for example, or credentials. 31:01 I think that that infrastructure that simple connection is really from where all of this can emerge. 31:07 And a lot of the governance aspects of things, for example, like the enforcing the ACLs and things like that, really come from the app level, right? 31:19 And using metadata from within a post or something or whatever have you to actually compose this. 31:25 But there's not really a ton that is missing here from the protocol. 31:31 I think that once permissioned data happens and we have that credential infrastructure to work from, both with a few record schemas, I think that this can be built. 31:45 I think this can be built without much additional infrastructure.