The Iron’s Still Hot

Jim Ray: We are streaming now live, ready to go. Your usual host, we’ve got Jim, we’ve got Alex, and we’ve got our very special guest, head of protocol at Bluesky, Mr. Daniel Holmgren. And we’re going to get to our AMA. Thanks to everyone for submitting your questions. But oh, and look, Eli has teleported magically through the magic of Streamplace, 15 people into our little space here. Thank you as always, Eli. Before the stream started, we were just singing your praises and how much we love Streamplace. But as we often do during these, we’re going to start with a little bit of news at the top. Breaking news, this is actually now a sports show where Alex and I our hometown teams, the Chicago Cubs and the new York Mets are playing each other right now.

And I’ve I’m I believe I’ve now doomed the Cubbies to lose the next two games in the series. Alex, any thoughts?

Alex Garnett: Well, Jim, as I was saying ten minutes ago, at least you’re currently over 500 while it lasts, because your team like mine is bad.

Jim Ray: Yeah, you know, every year I think it’s gonna to be gonna be the one. So just kidding. This is not actually a sports show, even though Bluesky is apparently a sports app. And so we’ll run through some of the news here. We do actually have a little bit of breaking news. Alex I’m gonna toss it over to you. To with some changes to the reference PDS.

Alex Garnett: Yeah, but this did not actually get out before this stream. It’s going to be going out later this afternoon because we are still deploying it live on our own Bluesky infrastructure. structure, but we now have an account management web interface in the reference PDS, which is a big, big deal because it further decouples account management from the Bluesky web interface and it also provides an interface for user management on the PDS. Until basically this week. The interface of the PDS was essentially GOAT, right? Like the command line tool, GOAT. If you’re a PDS administrator, perfectly useful, lots of cool endpoints, well documented, but still for a regular end user, there weren’t a lot of ways to interact directly.

with the PDS as an account management surface. And we finally delivered that, which is super exciting. I think it really helps complete that story, especially for atmospheric apps that don’t really want to have a prominent Bluesky presence in their account management flow. We’re very supportive of that, and we’re finally getting there so look forward to announcements hopefully later on today once we get it live on our own infra. And we’ve got docs, we’ve got everything. Please look forward to it.

Jim Ray: And this means people will be able to do things like change the passwords and all of those kinds of activities that were we usually had to redirect people back to Bluesky if they were on an another PDS and they were using our reference PDS, right?

Alex Garnett: Change your password, update your email address, deactivate your account, gr revoke permissions you’ve granted via OAuth, all that good stuff.

Daniel Holmgren: And Cuba gives a great place for 2FA, which I believe Amelia’s working on right now.

Jim Ray: Speaking of Amelia, Amelia did a live stream on Monday showcasing some of the features that are coming up. And I think I’ve got a video for that right here. And like you like you said, Amelia is also working on TOTP 2FA implementation not going out in this release, but a fast follow. So that’s reference PDS. And we’re, I don’t know. I’m very excited that that one’s rolling out. A little bit of making things a little bit more atmospheric so we don’t always have to come back to the to Bluesky just to do some basic account management stuff. Something else I’m quite excited about and got to work with the team on this one a little bit is you probably saw our announcement that we are working with the three blogging platforms that are on, or three of the blogging platforms, I guess, the ones that are behind the standard.site lexicon that everybody knows and loves.

So this is just a fun little bit of cross-promotion. Go sign up for pckt, sign up for Leaflet, sign up for Offprint, sign up for all three of them. You know, we all contain multitudes. You need to have multiple blogs. Once you decide that you love all three of them, Bluesky is pitching in and you get a 25% off that lines up with our time of year here. So we’re basically going to give you a summer of pro blogging for free. And so yeah, super, super fun. Just kind of a fun little you know, way to help support the ecosystem there. Alex, we were talking about how neither of us really has personal websites at the moment, but I’m actually in the process of migrating my old, my 10-year-old it’s probably been longer than that.

Food blog over to pckt. I have to figure out a Tumblr to pckt migration.

Alex Garnett: Nice. I mean, I know it took several hours of argument to avoid calling this promo hot blog summer. We just decided that that wasn’t gonna be right for you or I. That wasn’t the right brand for me and you, Jim.

Jim Ray: Yeah.

Alex Garnett: I don’t I don’t know why ultimately we were talked out of it by our loved ones and our families and our colleagues and some people on the street. well. Nobody wanted us to call it that. But summer standard.site, very cool stuff. Go check it out. Super exciting promo. And Jim, like you really drove this one. So I just wanted to give you some credit. Like it’s a very, very cool opportunity.

Jim Ray: No, thank you so much. It was literally a silly idea. I had walking the dog. I was like, you know what we should do? And was really excited to work with Leaflet pckt and Offprint on that. They you know, I love working with that crew. I’ve we’ve had interviews with them before and they were at AtmosphereConf. And so just can’t say enough good things about working with that team. While we’re talking about standard.site, our friends at Leaflet, they actually put together a really a really pretty great standard.site explainer. I don’t think anybody tuning into this live stream necessarily needs the standard.site explainer, but it’s quite a good one. So drop that link into the chat, give it a read if you need to tell your friends about why standards.

So speaking of pckt.blog, our fearless leader, Mr. Mr. Divy there, has put together the first of what I think will be an ongoing series of atmospheric login entries into an atmospheric login diary. I think taking from some of the success that Daniel has had with his permissioned data diaries. Any reflections after reading that one? This is something we’ve been talking about internally on the team about how to do atmospheric logins well.

Alex Garnett: Yeah, building out the widget type use case is really important. I know we have Amelia doing great work with FedCM. I know we’re all pretty clear on the idea that we want to have like a very recognizable login. flow, right? And I’ve seen so many community projects sort of reinvent this from first principle so far where they’re like sign in with Bluesky, but not just Bluesky, right? And I think we are sort of past the point where it’d be great just to have something off the shelf that most people can reach for, and we think so too I was doing some work on this a few months ago chatting with the folks at Tailscale because Tailscale is all in on OAuth, essentially.

Like they’ve got a very enlightened and opinionated approach to credential management, which is like don’t just create credentials on the tail scale side. Like use any auth provider. Like we don’t want to have it on our end, which is pretty cool. And the criticism they then get in turn for that is that limits you to a bunch of very large providers, right? So if you want to have something that’s more community infra-driven, it’s hard to reconcile that with the OAuth story and I think putting this front and center will really help use cases like that and just figuring out again like how to make the parts of it that should be off the shelf and opinionated.

work very straightforwardly and do it in a way that helps scale up that community infra to again keep centralizing on the PDS as an authority source.

Daniel Holmgren: The best thing about the atmospheric login thing that Divy put out is there’s no text box. For your handle. It’s just a button. Just a button. Which is so nice. That’s been that’s been one of the rubs on like atmospheric login, especially in the context of like other login things, is everything else has a button, but because it’s distributed we had to have this like text box for a handle. And so there we kind of like the proposal there is this like lightweight shim where you don’t have that handle in the mix as we’re working up to FedCM, which pushes that credential management down into the browser itself. Which we’re very excited about the progress of that and especially Amelia’s work in that working group.

Jim Ray: Super excited to be supporting Amelia there and Laurens Hof is noting that we need to have this because it’s about to start World War III in Europe if they have a unified way to talk about their decentralized social networks. A couple of other things that we’ve kind of flagged. So our friends at Graze Social have put together a new this is such a cool project. It’s very much adjacent to, I think, what we’re trying to do with the protocol here. It’s not really, I think, A proto native necessarily, but essentially a way to socialize AI inference so that it’s not all in a you know single computer that’s run by, you know, two or three tech companies.

I always like when I saw this, I was thinking like, oh, this reminds me of the old SETI at home. And then I realized that there are only like seven people alive who remember SETI at home. There’s a folding at home thing that Google did, where it’s basically kind of taking advantage of your spare compute cycles. So this one is called co/core. Alex, have you have you downloaded the client and are you running inference in your spare compute cycles?

Alex Garnett: You know, I do actually have some local models running. I found out this week that the RAM in my workstation has gone up in price to $1,500. In the last few months. That’s just the RAM. I think historically I’ve spent like 200 bucks on RAM most times in my life. So we’re in a fun time for small scale infra, needless to say, and I think pulling resources is a very cool way to tackle that. I know we’ve got a lot of folks in this community who have a pretty progressive orientation to language models, which makes them naturally very interested in what can be run locally. And that’s a story I think we’re going to continue to see develop in and around Atmosphere Developers.

So super cool to see this. The more that we’re able to sort of chip away at the moat for large-scale LLM providers and close models, the better. I think that’s gonna get everyone to a better place in pretty short order.

Jim Ray: A couple other releases here. So the folks at Padding Labs, we haven’t really mentioned padding labs. This is the team behind Margin, which is the really fantastic way to kind of store all of your annotations on your PDS. They’ve released a couple of things this summer, marque.at, kind of a domain registrar. And they’ve even got some integrations. I know that pckt integrates with Marque so that you can automatically just point your domain without having to hand copy the your DNS records around. But they just released locale.at, which is a way to do on-protocol translations. Really kind of similar to other services like Crowdin. Alex, I know that you’ve worked on some of our locale stuff with the with atproto site.

Alex Garnett: Yeah, I’m really excited about both these projects, I have to say. Anything that already uses the well-established verbs and nouns of the internet and does it in a way that is approachable. But competes with established providers that nobody particularly loves, perhaps, and does it in a way that is atmospheric and reusable just makes me, you know, makes my heart sing. I recently did some work because when I joined, we’d committed to localization of our docs, and I thought that was quite impressive. We’ve obviously got a big developer community in Japan and in Korea where that’s important. And so figuring out how to abstract out the code samples from our docs, like to avoid drift when we were doing localization changes, was step one.

Step two is making it possible for folks who are not you know kind of handling GitHub PRs all day long to contribute more easily. And that’s where these Crowdin or locale.at type tools come into play. So I think we’ll be adopting this relatively soon. I’ve been sort of hinting at this, but we’re in the middle of a pretty big redesign of the dedicated Bluesky docs. That’s something I’ve been working on this month that I’ll have more news about in a week or two, hopefully. And just like we did for the atproto.com docs, we’re gonna have a pretty big localization push around release time. So I’d like to use this tool for it.

Jim Ray: we can. And tune in for our next live stream. I think we will have plenty to talk about when it comes to new approaches to things like the Bluesky docs.

Alex Garnett: I think so.

Jim Ray: And then you want to talk a little bit about gifthood.org.

Alex Garnett: I did want to talk about gifthood.org. I have been talking to the founder, Tim, quite a bit in the past couple of weeks because I am so impressed. with the work he is doing to launch this project. It is very, very, very polished for an early waitlisted atmosphere project. gifthood.org essentially it’s like a buy nothing community group for local communities. I think we all have a mental model for like bulletin board type use cases where it’s like, hey, I’m giving away some shovels and some crutches I no longer need. Come and take a look at this. Notably, that’s a weird combination, isn’t it? Yeah. I did recently give away shovels and crutches, but I’m realizing now it sounds like I buried a body.

But it’s also notable, I think, because that’s one of the primary reasons a lot of people still keep their Facebook account, right? It’s like to use marketplace, to use local communities and all that, just to say like, hey I’d like to do something for people nearby, for people who are actually in my proximate geographical location, again, sort of bringing that grass-touching aspect back to internet communities. And I love the work that Tim is doing on Gifthood. I think we’re gonna see it open to signups relatively soon. And I’d encourage anyone to check it out. Just really polished, really cool, fits into our ecosystem story very nicely, and that is gifthood.org.

Jim Ray: I love that story. I love the idea of people being able to give up their Facebook accounts so that they can trade their, let’s see here, they’re maybe their the kids’ toys they no longer need to kind of move us in a gentler direction. And then our final bit of news, you know, as always, don’t forget to tune in to theatmosphere. community to check out for your local events. And there are new ones popping up all over the place. If you run a local event and it’s not showing up on the atmosphere. community site, then get at Boris or let us know and we’ll happily get you involved. Have all your events showing up in all of the places.

And now we want to bring in our very special guest, Mr. Daniel Holmgren, head of protocol here at Bluesky, who’s been working really hard. I think for about as long as I’ve been at the company now on what we call permissioned data. You’ve been writing these really excellent permissioned data diaries. You’re up to Eight or nine of them now, right?

Daniel Holmgren: Including interludes and stuff.

Jim Ray: So those have been going really, really great. But what we wanted to do was have an AMA. People submitted some questions, so I’ve got a few questions here. But I guess the first question for you, Daniel, is why does this even need to be a separate protocol? We already have this existing protocol for all of the public data that exists on Bluesky and all the other apps that exist. Why do we need to create a whole new separate protocol to do permissioned data?

Daniel Holmgren: Well, real quick, it’s not like totally parallel to the current like protocol, right? It shares a lot of common things like DIDs and lexicons and a lot of roles in the network, like the PDS and AppView, things like that. But the data protocol itself is a different protocol. It’s a different data structure. It’s a different sync mechanism. And to some degree it’s a different addressing scheme. The reason why it needs to be separate is it’s like really trying to do a pretty different thing from the public protocol. The current protocol is about public broad and it’s kind of manifestly public data that you want broadcasted out to the entire world, it’s sort of like on the record in some sense.

It’s archival. It’s rebroadcastable. Every record that you put out there gets a redistributable proof. And the thing that we’re trying to do with permissioned data is very different from that. You actually like all of those things are anti-patterns. for it right you don’t want your proofs to be rebroadcastable because if someone you know whatever gets upset at you or something you don’t want them to or just has like bad opsec or something you don’t want them to be able to a proof of something that you said that you thought was in a private context. You don’t really want these things to be archival. You don’t really want them to be rebroadcastable you don’t want to broadcast them out to everybody you want to have a set of people that you that you transfer this to and so it’s just a very different shape of data flow one of the things that goes along with that is that the structure that we have for repositories is really centered around this idea of like one signature for your entire bag of things and you get proofs for every single record in there.

And if we don’t need those things. things and if those things are actually like an anti-pattern, then we can use like a pretty different way of structuring stuff and syncing stuff that is actually, it turns out to be like quite a bit lighter weight because we don’t have to maintain this whole Merkle structure for broadcasting out records. And so I actually think that the permissioned data protocol because you’re trading off this archival and rebroadcastability, it’s actually going to be quite a bit lighter weight and in some sense easier to use than the public protocol. So yeah, that’s kind of like the rationale for the two protocols one of the pieces of feedback that I got on the proposal, and I had meant to leave a note about this on the proposal, and I forgot to, is about the URI scheme.

We’re still like actually not settled on that. The proposal has it as ATS and there’s a big part of me that does not want to split the addressing space, but then there’s also difficult things about the AT URI scheme, which it’s like how complicated can this thing get? This thing’s going to the IETF. Like if we’re tacking things onto the URI scheme while this working group is trying to specify it, there’s complications there. So we’re still kind of thinking that through, but there’s a big part of me that doesn’t want to. split the addressing space into a new scheme. So jury’s still out on that one. I don’t want people thinking that that’s signed, sealed, delivered that it’s a new scheme.

Jim Ray: You know, one thing that I’ve been thinking through this is would we, you know, if we could go back, would we have maybe started with permissioned data and then you know, created an initial global space that everything could have been in. But it sounds like that the those would have just been working at cross purposes with each other, where the very idea of having one of these big world socials like Bluesky just wouldn’t even really work even in the context of like a global space. Is that true? Or like is there a world in which we created a single protocol that that was able to manage both of the.

Daniel Holmgren: It’s a good question. It’s like if we could go back, maybe I would start with permissioned data. like the public protocol.

Jim Ray: Yeah.

Daniel Holmgren: Would I start with permissioned data, maybe, but just because I think that there’s more permission to use cases than there are public use cases. But the mission under the company was around public broadcast, which is why we started with the public broadcast side of things. But yeah, I don’t think that this like data protocol subsumes the other one or replaces it in any or anything like that. And it’s because they do have these two different goals in mind. With public broadcast, you really do want like you want to broadcast it. You want it to be archival, you want it to be rebroadcastable. That’s just a different type of thing than having a group or permission space or something that you don’t you don’t want that type of thing, right?

It’s actually the opposite of what you want.

Jim Ray: Yeah.

Alex Garnett: Yeah. I feel like the locked open aspect has been a very useful razor in terms of prioritizing how we build the network and how we talk about the network.

Daniel Holmgren: The permissioned data protocol is still open and the authority is still centered in key material, but there is a sense that it’s like because it’s not redistributable, it’s a little bit less like locked open than the public protocol. And so from like sort of a network like politics perspective or something like that, maybe it was good to start with the public protocol. And that’s one of the benefits of using that protocol is it’s like kind of the way I would describe that it’s like a little bit more substantial. It’s a little bit like on the record is the phrase that I keep coming back to. It’s like pretty substantial to write something to that and it locks open that data.

in a way that maybe the permissioned data protocol doesn’t. And the check for that is that you have like permissioned data protocol, it’s like a little bit more of a trust space. Like you have someone that’s running that space, which is different from being in this public mode where you don’t have anyone that’s running that. You’re just broadcasting it from yourself out to the world. In the permissioned data protocol, you it’s like somebody started this space, somebody owns this space, they’re kind of stewarding it. And there’s some trust there. You know, it may it might not be full trust, but there’s like there’s a there’s a relationship there, I guess. Yes.

Jim Ray: Cool.

Alex Garnett: And those spaces are all very sort of like composable, right? And I think in practice, most of the app models that we’ll see utilizing this will probably be making use of like six or seven different spaces for any given interface, right? And I think that’s probably a helpful way to think about it is we’re just kind of constantly composing them on top of one another to present to a user what resembles like a normal set of ACLs or interaction patterns.

Daniel Holmgren: Yep, that’s exactly right. The spaces are like are very lightweight, so they’re very easy to create and easy to participate in. It’s it should be the goal is that it’s a pretty lightweight primitive. And then but they’re grounded in a particular modality. So then if you want to compose spaces out of like multiple modalities or multiple like access boundaries. Then you create multiple spaces. And so I expect a lot of these communities that are built on top of the protocol, they’re not just going to have one space. They’re going to have you know, several or even dozens of spaces that compose together to form the community. Which, if you’re interested in that, you should go check out the community discourse forum.

Where people are out talking about what is an atmospheric community, what do we want out of this, and trying to come up with a bit of a plan for how we actually make these things composed together into something that devs and users and community managers and all that can make sense of and is very fun and cool and unlike anything that anybody’s ever seen online.

Jim Ray: I’m really glad you made that point because a big thing that we want to make sure that people that are watching or listening this is that the this is still very much in the process of being built out. We still absolutely want your feedback. We’re trying to show up at as many places as we can. So check out the GitHub proposal. I’ll throw links to these in the chat just now. But we’ve got a proposal up on GitHub. It’s in a PR currently. You’ve been doing some conversations in the discourse. And then of course there are the permissioned data diaries. I saw there was a request from Roscoe that you we do some bonus episodes of the podcast of just Daniel reading his permissioned data.

You know, that may be another way.

Daniel Holmgren: That’s a great point, Jim. And just to like call out there, it’s like a part of this design is that with the protocol, we really tried to like I think some people, whenever they first read it, are a little bit surprised or dismayed that they’re just like, oh, that’s like all that’s like how is that like a community? How is that like the thing? And the primitive in the protocol, we kind of tried to strip back to like the bare amount of functionality that you can compose with itself and other things in order to create these richer structures. Right. And so in practice, I think that there’s going to be kind of three layers to like communities built on the protocol.

You have like the protocol itself, the data and sync protocol. And then you have these community structures on top of it. We’ve been calling that like standard. site for communities. There’s interesting work from the Roomy crew building out like an arbiter for running these things, the stuff that Brittany did with Open Social communities is in this domain as well. And all of those people are participating in these discussions. We’re kind of like hashing out like what this layer should look like. And we want to come up with like an ecosystem driven. Spec for how to structure these communities. And then there’s the application layer on top of that, which people are familiar with that. You like it’s under a domain that you own.

You have full control of the application semantics and other applications can interoperate with it so yeah there’s those three layers and like the bottom layer the iron’s still hot we can still make changes there on the proposal I think the general shape is there please give me feedback I’m trying to get to like an actual draft proposal by what did I say by the 250th anniversary of this nation’s founding.

Jim Ray: There we go.

Daniel Holmgren: Probably by the.

Jim Ray: time before.

Daniel Holmgren: Yeah, exactly. By July 2nd, I’m trying to get to like an actual proposal on that. But then we’re really doing this like community and ecosystem-driven effort on building out the middle. Or designing the middle layer there. So we’re very interested in people hopping in on that if you have thoughts on the shape of that.

Jim Ray: Yeah.

Alex Garnett: Nice.

Jim Ray: And I’m seeing some conversation in the chat here too. A little bit of I wouldn’t quite call it angst, but I think maybe some informed worry about everything just moving to permission spaces and all of a sudden Bluesky’s just a ghost town that’s that feels less like a technical challenge and more like a governance challenge and something that is up to all of us to make sure it doesn’t happen. But I think it’s it is something that we’re talking about internally as we try to figure out because the communities project that we’ve talked about and head of product Alex has talked about too regarding where we’re going to be kind of taking the app in the future.

being built in conjunction with permission spaces. And I think one of the things that we really want to figure out from a product perspective is how do we take all of the liveliness that’s happening on the big open social give people the spaces to kind of create their communities and allow that interaction to happen. And I think that there’s plenty of opportunity to for folks to build their own custom implementations of that.

Daniel Holmgren: I’m not too worried about it. I do think a lot of stuff will happen in the permissioned data protocol and probably more act like more interaction will happen there than in the public protocol. But there’s always going to be a need for public broadcast and like it’s sort of core to the microblogging social modality in a lot of ways and giving people places to socialize and talk with each other outside of the big public broadcast square, if anything, I think brings more people in that are going to end up using the public broadcast. So I’m not worried about it subsuming it, but I think it’ll nicely complement it.

Jim Ray: So I want to get to some of the questions that folks have submitted. We’ve got some great questions in the chat here, but I’ll start with the ones that folks hit us on we had a post about a week ago and folks have been responding there. So Woke Oak asks, what is the rollout going to look like? Bluesky was a private beta to test the protocol. Will anything similar happen here and can they have an invite?

Daniel Holmgren: That is a great question. So my like my goal is to have this proposal in life right now. It’s funny, I’m it’s like a draft proposal, which kind of seems like I’m just layering on words for not quite finished. But I’m hoping to have the proposal in a pretty good spot. By the start of July. I would like to have like a alpha version of the PDS implementation done by then as well. At that point, we would not be like rolling it out to Bluesky PDSs, but folks that self-host a PDS or host like a larger PDS instance. would be able to roll it out on their PDSs and start using it. The caveat there is that whatever data goes into it, you either need to have a migration story or you have to be okay with it being deleted.

This th this would still be early in alpha and breaking changes are absolutely still on the table. And we’ll try to make that as easy as possible, but we can’t make promises. We’ve also discussed we need to figure out if we’re actually doing this, but we’ve discussed throwing up a Bluesky hosted PDS for permissioned data that we wouldn’t toss like you know normal users on to, but it would be open signups for developers to build against and we would handle all the data migrations and stuff on there and just kind of keeping this thing in sync with the work on it so that people can start developing against it and getting a feel for it.

So I think that that would be a pretty good thing to do. And then and then it kind of just depends on like I guess like what the reception is too like if it if everything works and everyone’s like, yeah, this is great. This seems to be working. Let’s do it. There’s no there’s no bugs, flawless implementation. Thanks, Daniel. then we’ll package it up and get it out there. If we need to go back to the drawing board on either big or small things, then we’ll do it with that. My like rough goal and this is always a dangerous thing to say is probably like end of August I would like to have things kind of like in a good spot on the on the protocol side of things.

Jim Ray: We do have a follow-up question here and I think there’s probably some interest in the chat too about the migration piece. And so it sounds like the migration story is very much going to be kind of a work in progress. And certainly while we’re in development, then, you know, we’re gonna do everything we can, but no promises while things are in beta. And then we’ll kind of see how the migration shakes out given how things go there. I think I know that there are, you know, there’s certainly lots of community implementations. So we’ll kind of keep in touch with what’s going on there and try to figure out what a migration story might look like there too.

Daniel Holmgren: Yeah.

Alex Garnett: Cool. And that segues into our next question here, which is wondering about Bluesky group chats, will these be migrated to permission spaces when they are ready? And sub-question, and will ownership of those spaces be transferable separate did. This is a good one, and I’m glad people are thinking about it. I think in terms of Bluesky group chats being migrated permissioned data. Most of the conversations I’ve been privy to all kind of land on probably. Like it’s a good thing that we ship group chats ahead of waiting for permissioned data and it makes sense as a use case for us to test out. permissioned data in Bluesky the app. I don’t think we’ve said for sure like we’re definitely going to migrate them right away, but as far as dog fooding goes, it feels like a pretty good use case.

Daniel Holmgren: Yeah, I think that I think the goal is to eventually migrate them to it. It’s like it’s sometimes hard to prioritize stuff like that that is not gonna give really like any like benefit or service in the product or anything like that. And there’s just like a much more exciting first application of permissioned data, which is around like atmospheric communities, which again check out the discourse if you want to talk about atmospheric communities. That I just think is like really fun and cool for both Bluesky, the app, and the atmosphere, and like I think can really give users a lot of intuition about what the atmosphere is and help onboard people. people into it. And so that’s the thing that we want to build out first on the permissioned data protocol.

Once that’s in a good spot, then I think it would make sense to go back to group chats and bring them on to onto the protocol as well. Haven’t thought about it too deeply, but I do think that in general with DMs, you want to have a separate DID from any of the participants that own the conversation. And so I think that that’s probably what we would do in terms of modeling it is each conversation would get its own DID.

Alex Garnett: Yeah. And that gets us into community owned dids and transferable spaces and things like that, which are ongoing discussions that we know are really important and key parts of the permissioned data ecosystem that are shaping up concurrently, I would say. Is there more detail we can share there right now?

Daniel Holmgren: Yeah, yeah, yeah, yeah. That’s a that’s a big topic of conversation. That’s also over in the discourse forums right now. But yeah, whenever you start setting up these community spaces, they’re under a DID that’s like not one of the user dids, and then these like services that we’re talking about putting together, things like the arbiter that Roomy’s working on, the concierge that Miss Boba’s poking at open source social communities and Brittany’s doing. All of these things like kind of have a governance layer under the hood, which it’s like, okay, who actually owns these dids? How are they governed? Like how do we keep this from devolving into like petty fiefdoms of communities and stuff and build actual governance structures around it?

So and the great thing about that is that like the primitive in the protocol is flexible. It’s a DID. And there’s key material there. And you can kind of drive this however you want. And so people can build their own governance structures around how these communities are owned and administered.

Jim Ray: And our man in Amsterdam, Laurens Hof, kind of points out that the reason I’m writing so much about geopolitics now is because of govs actually very much want online spaces where the space has permissions that can be controlled. So this isn’t necessarily even just us or specific individuals, but it seems like it’s very much layering up all the way to the highest levels as they say. So.

Daniel Holmgren: yeah.

Jim Ray: Super interesting to see how that’s gonna that part of it’s gonna play out with Europe is obviously going through a big data sovereignty, all kinds of tech sovereignty push right now.

Daniel Holmgren: Yep, totally.

Jim Ray: Okay, we’ve got a question from Scooty who asks, so to deliver mail, co-mail will need to write a user’s inbox space member list, but a delivery service isn’t a normal user with a PDS. Do we join as a member did Plus host our own realm, or do we write to the user’s PDS? What does sync on behalf of users look like for an outside sender A bit of a kind of a specific use case, but you know, for something like that, where a service is maybe acting on behalf of a user or you know, this might go back to kind of like that shared did use case too.

Daniel Holmgren: Yeah, it’s I’d probably have to sit down with that one for a second to give like a definitive answer on it. But generally what I’ll say is that you don’t you never you basically never write into someone else’s PDS. That’s kind of a dangerous thing to do. You’re kind of open in your personal data server where it’s like, oh man, what are people going to put in there? And especially like kind of untrusted, right? Like an open right boundary or something like that. So you basically never do that. I also think it like sort of grades against the atproto ethos a bit, which is always about like you publish something, it’s on your thing, and then that gets crawled.

and pulled up by applications. Like that’s generally how the data flow works. And so if you want to build like a mail system on top of the protocol that would generally work by posting something in your PDS that then a mail client is going to crawl the participants of the threads or like of yeah of the email threads, you know. In terms of like how that how that would work for like cold sending an email without having a conversation structured, I.

Jim Ray: Well and I think the co-mail use case is it’s more about kind of community governance of mail infrastructure, not necessarily like sending specific emails and things like that. So.

Daniel Holmgren: I yeah, I don’t know. I’d have to sit with it a little bit more, but I think that the data flow protocol is like flexible enough that you could that you could set up that infrastructure in like a few a few different ways. I think we’d shake out.

Jim Ray: And I think we’ve got a similar kind of question here too, with a slightly different use case, but you know, this one is about so Patrick Singletary wants to know about creating kind of a giphy kind of application. And so, you know, if I share a GIF that’s stored on my PDS so that others can use it, how does that work when I revoke access? Is it kind of like detaching a quote with Bluesky now? I think the allowing and removing access piece is a is a pretty critical one.

Daniel Holmgren: Yeah. Yeah, so you can if you’re hosting a space, you can kind of add or remove access to it. Whenever you want to, whenever you remove access, that user is no longer going to read the things and applications, any applications that they authorize to do so will no longer be able to read it too. So in terms of like a GIF, sharing thing. I think that and some of this depends on like what you want as the application semantic. If you are just sharing the GIF and someone else can pull it in if they’re a member of the space and then you remove them from the space, then yeah I think it would work like detaching a quote.

They would no longer be able to pull it in. If that’s not your goal, then whenever you share it to them, they could copy the GIF over to a space that they own or even their own like repo within that space or sir or something like that. But yeah generally the semantic is whenever you remove somebody from a space that user loses access to everything and applications are supposed to enforce that like that view boundary and also not show them anything from inside of the space as well.

Jim Ray: So there’s always the ever-present and thorny and exciting topic of moderation. Lots of lots of big questions here, but how are we thinking about that? You know, so we’ve got a really a pretty great question from Dave here. How will how will it likely work for Bluesky permission spaces? Will your company keep using HMA? Hasher-Matcher-Actioner, is that right, HMA? To prevent illegal content in such spaces, what about third-party permission spaces? Can we automate moderation or utilize HMA? by proxy. So how are we thinking about moderation?

Daniel Holmgren: Yeah, all good questions. Yeah, I think that’s like about like kind of the like content hashes for illegal content and things like that.

Jim Ray: Yeah.

Daniel Holmgren: and yeah, like any media that flows through our system will be like running that on before we before we serve it. And like permission spaces are not encrypted at rest and you can view media in them. So we’ll be we’ll be running like scanning on stuff on our infrastructure. to make sure that we’re not hosting or serving illegal content. I can’t really speak to like if we’ll be providing that like as a service for third parties or by proxy or something like that I don’t know, I’d have to talk with legal about that first. I know that there’s like sensitive things about this because anything that you use in a positive way can also be used in a negative way.

identify it in the bad way. So I don’t know. We’d have to we’d have to chat through that. And that’s like a useful thing for public stuff as well. Generally the thing with moderation is it’s like because the data flow is pretty similar to the public protocol, the story is pretty similar as well. It’s like hosts are on the line for legal reasons, for stuff that they for any sort of content or media. that they host, they kind of take on the responsibility for that. They should have some sort of like reporting interface for finding out about stuff. We want to try to put some better communication flow into the protocol for reporting stuff from apps to hosts.

Apps are responsible for stuff that they’re showing to users both in a legal sense but also just kind of in a product sense in their relationship to users. All of that is basically the same between the public and permissioned data protocols. And because like this stuff isn’t encrypted at rest, like moderation teams can generally respond to it in the same way. As they can public data. The one big thing that’s different is that you have these boundaries in the network now and you can appoint moderators within those boundaries and so I think that that opens up a lot of stuff for community moderation and like the type of moderation that you don’t really get from you know, like tech companies or platforms or something, a much more like immediate and hands-on and bottoms-up and communal moderation that kind of gets enabled by having these boundaries within the network where you can appoint moderators and administrators to it.

So I’m really excited to see what people do with that and kind of just like self-organizing some bottoms-up communal moderation on their spaces, you know.

Jim Ray: Yeah.

Alex Garnett: This is like the subreddit model in effect, right? And as long as we have interfaces that appointed moderators can use and get privileged access to a given space, then you can build new norms around it. I know we develop Ozone for our own use case, you know, for moderating Bluesky, and we’re pretty vocal about that. Like we build Ozone for us, but there’s a lot of other tools in the T&S space. that are open and reusable and meant for smaller scale moderation. And that space is just exploding this year. I would say take a look at the TrustCon. program next month if you want to see like all the current active development in T&S tools, I believe that Acorn and Coop are both going to be represented there and we can definitely see a future.

in which those are well adapted to groups on protocol.

Jim Ray: I do want to try to get a couple more questions in here. Community favorite Fig, aka bad-example.com asks can you say more about space declaration as a lexicon instead of plain old record? I guess it roots the declaration’s authority in the space type NSID. But it feels a bit weird because the contents are more record-like, not schema.

Daniel Holmgren: What Fig is referring to is there’s a there’s a new lexicon type that’s spec’d where the type is space and it’s for declaring like the modality basic. So you might declare one of these for a group chat, for instance. That’s like one of the, and maybe it’s app. bsky. group chat is the NSID for it. And that’s a that’s a lexicon. Like the re the reason that’s a lexicon and not a record is because that’s kind of like describing the abstract shape of the thing. And then there are a bunch of space there are a bunch of group chat spaces. Right. That’s kind of like the class. And then the spaces are the instances. And it’s just like it’s very similar to describing like the shape of a record.

This is describing the shape of a space and what would go in that in that space and then yeah, you get the benefit of like rooting that in a in DNS authority and having an NSID that you can refer to these. like space type spy. And then as always, lexicons are published as records and resolvable in the network, which is actually going to be important in the OAuth flow because you resolved that both for the human readable and expressible text of communicating these spaces to users, but then also like what the default permissions for what collections you give authorization for whenever you authorize access to one of these spaces.

Jim Ray: and one last question from Roscoe aka not bin dot com so how integrated will this be with existing endpoints? Will you be able to query records with com.atproto.repo.getRecord normally as long as you’re authenticated and have permission, or are is there going to be a whole new separate set of XRPC endpoints?

Daniel Holmgren: I believe this is going to be a separate set of XRPC endpoints, which is like there’s a few things there. One is it is kind of like owning up to the fact that it is like a separate data protocol, and like possibly a separate addressing scheme. There are also just like especially on the write path, you can kind of like the there’s like a backwards compatibility thing here that’s pretty rough, which is like if you have the space in there is like optional. And if you don’t have the space, then you end up like smuggling it. Like it can be misinterpreted as writing to your public repository instead of a permissioned repository, which is like a really bad user violation.

Basically, like there’s enough differences on this stuff in terms of like the authorization logic for it. Like it’s a completely different scope to read and write from spaces as it is from the public repository. So like the authorizations different, the inclusion of like the space in the addressing is different and the data protocols different, that I think it makes sense to generally support these with separate APIs. Applications, on the other hand, are free to crawl these things and you like applications do not have to maintain a strict distinction between these. They can take stuff from the public broadcast protocol and the permission spaces protocol, munge it all together into whatever application view they want to show.

But for the lower level APIs, I think that they’ll probably be separate.

Jim Ray: And I can see some really exciting applications just thinking like kind of what we were talking about just earlier, not wanting to lose that connection between the broader social, the big, the big social and also the intimacy of the smaller groups. I know I’m hopeful and optimistic that the folks listening will go off and build those amazing cool great things.

Daniel Holmgren: Yeah.

Jim Ray: Daniel, thank you so much. I think we got to most of the questions. I was looking through the chat. There’s some really great discussion in the chat, including a link from protocol. Man about protocol, I guess, Nick Gerakines, who read through the your 0016 there and awesome thoughts. So I haven’t had like I think he just published this, so I haven’t had a chance to read it myself. But I’ll throw this link. The link was in the chat and I’ll throw it in the show notes too. So do give us your feedback. If we didn’t get to your question, I’m so sorry about that. Please, please do add us on Bluesky or jump into the various discussions on discourse or on github where we’ve got our proposals up there.

Daniel Holmgren: Sweet. And yeah, just I do I really want to hear people’s thoughts on this. So hop in, hop into the discourse forum, hop into Bluesky threads you can feel free to DM me or whatever. But if you have feedback on it, please share it.

Alex Garnett: All right. Everyone, thank you. Stay safe out there and never stop posting.