So my name is Baldemar. I help run uh Furry List uh which is a feed uh which is a service that uh provides feeds for the furry community and let me see here. I completely forgot how to actually do this. Right, there we go. Speaker notes. Awesome. All right, so we're good. So um I have a question for you all. Let me see if this works. Awesome. So what makes you and me different from strangers? So raise your hand if you're a developmental biologist. Okay, raise your hand if you're Mexican. Uh and now raise your hand if you care about the open web.
That should be everyone. Yeah, okay, that's what I thought. All right. So we have that shared identity and that those shared values, right? As a and we are sharing this space here as a shared social space based on those values, right? We have that common foundation of trust to build relationships from. And I'm interested in how exactly we can actually translate those relationships into the online space in a way that actually reflects uh how they exist in the real world as they exist. And this is what I've kind of been wondering as I have been uh helping out with uh furry list.
So if you don't know, furry list is a service on Bluesky that provides feeds uh for the furry community, but we don't do a global feed and uh we don't just rely on hashtag feeds, right? What we do is uh we manually curate every single user that uh wants to become a member of our community of our feeds. Um so we've done that for about 64,000 people now. Uh we've started doing that uh early on in Bluesky when uh Otter uh was in charge back then otherwise our founder. Um now Kev uh has been uh uh the lead and we have grown quite a bit since then.
And I'll just show you real quick how it works. I mean it's not nothing too complicated. A user follows us, right? And after that follow, um they go into our review backend. Now the follow itself is a signal of intentionality, right? They have they have signaled to us that they would like to join our community. And our review backend, which looks a little something like this, um, is a way for us to check first off whether our they are furry, and second off, whether we believe that they would be a good addition to our community. So there is a manual curation to our community at every level.
Um 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. Every judgment here is intentional. So this is a classic, you know, bi-directional membership, you know, like the user is part of a community because they wish to be, and the and uh the community allows someone to be part of their community as well. This is how most online communities work today, you know. Um but uh and when we do this, we actually create what I'm gonna call trust domain. The user by being part of by being part of the community implicitly at least initially trusts us to make good decisions for the community, and then furry list then um uh through this follow record says that we believe that they are also a trusted member of the community.
And you know, again, this is how most online communities work. But there are a few issues here that I think I've uh that that that I started to uh think about. Uh the community um depends on us for infrastructure and their existence. Now to be clear the community is defined through public records, right? Like we follow them, the follow is a public uh is a public record, but um we're the ones who provide the feeds for furry list, and this isn't but why is that? Well, let's see, let's go through uh through what happens when we revoke a record, right?
I mean if we revoke a record, then there's no that we have vouched. There is no historicity to the community. When it's gone, it it it's really difficult to prove that you were part of the community at a protocol level. And God forbid, if we stop existing, there is no proof that the community ever existed in the first place. There's no history or path forward. Everything has to be rebuilt from scratch. The community itself dissolves. 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 in the entire social graph itself is gone, right?
So I I divide these problems into two different domains. First, the trust service domain um lives in the records that we control. And if we and they don't exist independently of us, right? And secondly, there's no easy way to organize, find, or navigate what others build on our work. Again, it's not impossible, but it's uh but but there's no surface through which to find new things. We become the default space. And we don't want to be the default space. Uh like we provide default fees, but we don't want to do extended governance. Uh because that in that enhances the surface through which conflict can happen with a community, right?
We have a limited mandate. Our mandate is to vet members of the community. If we start doing additional governance on top of that, that is additional surfaces through which we can come in conflict with the community. And if we put so much effort into creating this community, we don't want it to go all to waste because of a mis of because of a mistake that we made. And if because again, if we make a mistake and things collapse, it cannot exist independently of us, right? These are connected issues. Oh, and um, so thankfully there the uh permission that I don't know I'm sure that you saw a lot of you guys have been looking at uh the permission data infrastructure proposal or you know, like rough proposals that it has been doing, that I think that actually solves one of the issues uh uh pretty cleanly, and that's ownership.
So essentially we have uh we have a spectrum here from private to public data, right? The the protocol itself was designed for private with a public data in mind. And you know, the extreme end of private data would be end-to-end encryption where it's two parties who at who who share a a uh a trust boundary, which is probably the smallest trust boundary you can make. Now permission spaces are things, for example, like uh Discord, like a private subreddit or a private forum, right? These are spaces where there is uh where there is a shared domain of trust.
Um, you know, like people within the Discord community can see everything within the community, but they can but people outside of it cannot. Um so this is this I think is where the importance uh the the uh the interesting uh like the interesting part for communities lie. And when thinking about uh when thinking about ownership of these trust domains, I think that the that uh that Bluesky has come up with uh a correct solution. So here again, bidirectional follows, uh each record here lives in the in uh in each author's repository, which is you know how follow records typically work.
However, uh within the permission data infrastructure, adrats so far, there is a signed attestation that the ACL maintainer, the access controlless maintainer, writes to the to the user's um uh repository. 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. It exists independently, right? So this becomes in a way a historical fact. Even if even if there is a retraction of the credential, um this uh this credential still exists and it exists independently of the ACL maintainer. Now let's think about what Furulist does today uh compared to the ACL maintainer in the permission spec.
So we curate a membership list. They also curate a membership list. We do vetting. They also have to do vetting of some kind. Uh we use followbacks as proofs, credentials in this scenario are proof. We use unfollows as removals. You can also do credential withdrawals, stop admitting uh by you know not issuing any new ones. We already kind of act like an ACL. We just don't issue any credentials yet. So this is the this is uh how things existed before, you know, again, no historicity. But think about how things look when we actually use these verifiable uh these verifiable credentials.
A retraction really is not uh like it it's not an erasure. I think about it kind of like how uh you know like uh uh scientific journal retracts a paper. A retraction is a statement that says we made a mistake, we no longer believe uh this statement that we made is true, but the paper's still available. Similar here, it's a statement, like a labeler, right? Um the the history of the decision is preserved and the governance that results from it becomes auditable. And if we disappear, um in theory, the the the history of the community survives because the credentials still exist, they exist within the user repository, and in theory, a path to credential uh to recovery is possible.
But the important part is that it's possible, that does not mean that it is uh that that it will happen. Without a structure to reorganize around, without a matrix that the community exists in, the community still becomes a diaspora, right? If we're just defined by the by by the ACL, then we're still back to the to square one if we disappear and if our feeds disappear, right? There's nothing to reorganize around. Now we I think that the credential system solves the first part pretty nicely. But what about the second part? What about the structure itself? So to do this, I would like to uh talk about one of my uh favorite feeds, which is the science feed.
And in many ways, the science feed um it does similar work to Furry List. The science feed uh manually checks orchids, they do staff paid base checks to check whether uh something is uh whether an account is associated with a professor, they check publication lists, they really do the field work uh to to verify whether someone is part of their commun of uh their you know scientific community. This has created like an extraordinary trust surface of thousands and thousands of real world scientists. And it's it it really is just an incredible undertaking, what they have been able to make here.
But like think about like what results from this. It's just one feed. And it's good feed, and I love using that feed, but a feed is not a space. It's a one of many different conversations that can happen. I mean, I want to talk, you know, I'm a development biologist, I want to talk about like some help with like my zebra fish experiments or how to use a particular microscope or help with grant proposals, things like that. 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, but there's nothing there to go to, and it's not because of the protocol.
This is a publicly accessible. You can make it technically, and you know, like you can make that space if you wish, but there is no way to find it, right? There's no way to to to find uh there's no way to find what has been built off of this infrastructure here. No matrix through which the community itself can exist apart from what the maintainer itself provides. Uh so why does this happen? Um 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.
People want to be where the people are, you know, like distribution is not a good user experience that is not a good user experience. During the beginning there were many, but because everyone wants to be in one place where everyone else is, everything converges to one maintainer, the landlord. Same thing that happened with uh with uh you know like like you know the online social web as well. Everything converges because people want to be where the people are, you know? And I think I think that a lot of people kind of ask the question like how can we fight this?
I don't think that this is really something that we can or should fight. It's not a good user experience to do so. Bluesky and the app protocol so far has been successful precisely because it doesn't fight it. You know, Bluesky itself, you know, is the entryway into the AT Protocol, but it does not make you had make a choice about which app you will use because Bluesky is the default and it's what everyone else uses, and from there you can make the choice to exit if you want to. I think that we can do something similar if we at with communities by giving that centralizing force a limited mandate, 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.
So if we definition, if we allow members of a community to say, define a governed social space, which I'm gonna call a venue here, um through some kind of record, then that record uh becomes a link between the infrastructure of the community and the definition of the community, the credentials of the community. And this opens up a ton of affordances. Um governance now has a surface for disagreement. Um there's two governances here, right? There's not just the one governance for us, which means that if the if we make if we make a mistake or something that the community disagrees with, there is a surface here through which that disagreement can surface and be absorbed, not necessarily at the member level, but at the actual spaces where people exist.
And this can create backpressure. Um the relationship between these two are is now surfaceable at a protocol level, which means that uh that apps and app views or apps can surface this connection between the community infrastructure and the community definition itself. And because this is emergent from the community itself and the community members, plurality kind of becomes the norm. Um there are many spaces that are run by self-selected stewards who have decided they care enough about the community to create these spaces that create uh that create air like different spaces for different needs for the community with different types of governances, and members can use the ones that they resonate with the most.
And this topology emerges from the users, it does not emerge from you know furry list or you know whoever defines the community itself. The credential is the key to opening up all of these, uh all of these different uh all of these different spaces. A single community can have different spaces run by different operators with different governances, and yet they all here share a trust domain where the credential is the unifying uh is the unifying factor. And users then can you know route their post to different places through, for example, if this if if they're defined by a record, TID as metadata, let's say, for example, it could might as well just be like a random hashtag at the end of the post.
Um and this can be used as metadata as information that defines a space within the public network, right? Because the metadata is unique and it does not convey any information, the information emerges from how people use it. And uh this is actually something that I would like to uh that that I like to shout out uh for uh with uh Nighthaven, uh who's uh Blue Skyfell, I believe, uh has done some good work uh in uh in kind of exploring this area. Uh he calls it a mezzanine, uh they call it a mezzanine, which I think it's uh is a really apt description because a medzanine is shares a space with the ground floor, but there's an intentionality to going up there.
There's a it's a shared frequency where people can congregate that still exists within the public network. So it could exist kind of like this, you know, like it because these all are share are connected through with the uh through the community definition, each one is independently gov uh independently operated. So they are separate governances, separate stewards, but are all connected. So this is what this is what it could look like. You know, the roster kind of gives the browser gives out credentials to the community members. The community the the the uh they can make venues through which uh through which members can then self-sort and use the ones that they resonate with the most.
And um, yeah, each node in this graph is an independent agent that has a complete independence and complete agency within their own domains, but cannot uh cannot directly affect the others. But they can affect the others collectively through back pressure from the bottom up. For example, if a venue uh you know, if a venue's governance acts badly, well they're operating in a public network with public data, right? So they can make a different one, 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?
That is a back pressure mechanism of action. And this also works for the roster. If the roster makes a bad decision, if they admit someone they shouldn't have, they should, or they uh if they remit 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, and if this happens throughout the community, that is a back pressure mechanism saying you are doing you like you were wrong. The community disagrees with you. It is layered back pressure mechanisms. So are we done here?
I guess we're done here. I guess I can just go home. Oh right. So communities cannot simply exist in public, especially when they share a trust boundary. This is uh it's a problem to exist only in public for communities. If everything is surface level, there's little opportunity for depth of conversation. Even if in further, in the science community, we've created this amazing uh this amazing uh surface of trust, but there's little meaningful way to take advantage of it if every conversation happens in public, you know? Every interaction within these spaces is done in front of imagined audiences, people who you think might be looking at.
And the pro that that that depth, that community depth, I believe, is important uh to uh is important to really uh take the full advantage of this trust that we're building. And you know, like I said, with the permission data system that that that Bluesky is building, we're already uh we're already acting kind of like an ACL. So then the question becomes like what what if we just uh become uh the uh the ACL maintainer. What if we just become the the like the uh the the system that decides who does and does not gain access to permission data.
Well, this means that uh not only could posts be made public or private to our community, but because uh because venues exist as defined as records, individual venues can also be either public or private or even individual subspaces within them. Um the uh uh the outside might see all of first sky. They might see uh they might see some of the first suit maker spaces if there's you know like a sale uh going on for like a first suit or something like that, but they don't see it all unless you're part of the permission space of the community.
Once you're in this permission space, um you can see, for example, that Bafers exists or that Stenfers exists who did not want to share what they were talking about in public. Um you can you can join in with the advice for first suit makers and see you know learn how to make a first suit for yourself or the first uh you know if you haven't you you don't have any uh experience with it. Even within these boundaries, you can create another one if you so wish. You can create another roster that's just for like for example furry list moderators.
And uh this can create this this is just simple set logic, right? Um the design space is modular and any kind of set logic here is possible because I mean we have the fundamentals here, we have the boundaries and we have the spaces within them. So if however, if you're thinking about how the permissioned uh data system would work here, you might have noticed something. If the run if the 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?
They have full control over that like the community's permission data. So how so haven't we just recreated the landlord essentially? And this is where I think um the ad protocol uh can really help, not necessarily at the protocol level, but in the ability to go off protocol. So say that uh say that we at first retract a credential for someone, we say that we no longer trust them as a member of our community. As a result, they lose protocol level access to the community data. Um there is no fix for this, and I don't think that there should be.
But let's say that a single venue uh disagrees, in this case first of makers. Their governance still vouches for them. They still that they still think that they were a valuable member of the community and that we were too harsh in their decisions. At the protocol level, there's no fixing this. Um but consider what happens when these live in an app, an app that uh that must uh that must govern or you know moderate what happens within them, you know. Then something interesting can happen. If the first if first you makers can send a vouch signal uh 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.
They can say, well, yes, we have access to all of this, and the and the roster says you know we that that they do no longer trust them, but in this particular social space, in this particular governance space, they still uh they they still trust them. So we can still serve that content to that user and allow them to interact in this particular space, but only in that space. It's a window into the permission space. And it only exists outside of the protocol. It exists because the app view is the trusted mediator of of governance between all of these.
So this is what this is the system that that that I call composable trust. Each uh role here, each part here has a particular role. The roster can issue uh decides who belongs, but it does not decide what the community looks like or how they govern themselves. The venue can govern their space, they can design their space and uh and set the rules and set what the space is about, but they can't yield, they can't make credentials. They have to define themselves based on an existing community definition. The app view assembles the view and forces and forces the ACL and forces trust, mediates trust, mediates the venue's governance, but it holds no data, it cannot make it does not make credentials, it has no governance authority in and of itself.
It's powerful, but it's still replaceable, just as the rest of these. And the members themselves are the ones who hold all the cards. They own the data, they hold the credentials, they choose, they choose which community definitions to be a part of, and within those community definitions within that trust domain, they choose where they want to be.
And the users are at the very bottom. They are at the their existence within this space, it's at the discretion of all the layers above. And if one of these fails, everything below it fails. Now consider how this system works. This is now a system of roles and relationships. The community structure itself emerges from the bottom up from the users. Each node here is can be audited by the others. If any one of these uh systems violates the community's trust, they can be replaced. And if these relationships are surfaced well, if the community structure is navigable, then the community can survive any one single failure of these.
Nobody here holds all the power for our community. The community is built from the bottom up by the people that inhabit it. So I think that I think that uh this is a good structure for a solution. Remember this uh this uh diagram that I showed you here? So this is what a single community looks like. This is what furry list might look like. But consider what this could be. Uh 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.
This is a trust graph that is built by all and owned by none. So if you would like to uh help build this, I have a uh I have a more technical proposal um up on leaflet if you're interested in in in in reading that. Um otherwise, if you are interested in helping build these kinds of sustainable communities, um please do reach out. I mean I'm I'm super interested, I'm hoping to get some uh some uh schemas out after this uh after this conference and start uh and start building something uh something uh uh real. I'm not a coder, uh but but uh I've I I'm really uh excited to see um what we can make with the with this uh infrastructure with the protocol.
Yeah, Mikey. Thank you so much, Baldemar. We have time for maybe one question. Is there anyone in the audience with a question? Yes. Uh really interesting, thanks. Uh do you have a a sense for um which primitives might be missing from the protocol right now to support this uh and and which uh like already there and and useful. So really like the the the biggest thing that that is missing is the permission data infrastructure, the one that has been proposed by Daniel, and the uh the ability to connect infrastructure to uh to existing uh like lists, for example, or uh or credentials.
Um I think that that infrastructure um that that simple connection is really from where all of this can emerge and the abil and a lot of the uh like the governance aspects of things, uh uh, you know, for example like the enforcing the ACLs and things like that, um, really come from the uh from the app level, right? And uh and uh and using metadata from within a post or something or you know, whatever have you to actually compose this. But you know, there's not really a ton that is missing here from the protocol. I think that once permission data happens and we have that credential infrastructure to work from, um both the uh like uh with a few record schemas, um I think that this uh that this can be uh built um relevant I think this can be built without much additional infrastructure, you know.
Thank you so much. Can we have one more round of applause, please? Thank you.