A Bad Idea Until You Think About It

Jim Ray: Okay, we’re here. It is it’s the main event. Everybody’s been waiting for it. And before we get to the clash of civilizations here, we are going to run through the news. I have with me two very special guests. I kind of previewed a little bit that we were gonna have special guests. I didn’t want to reveal anything. I think maybe people kind of suspected who it might be. But we do have with us Mr. Daniel Holmgren, the head of the protocol here at Bluesky. And then with a new stage name, Paul Frazee, aka Thunderguns. Coming in loaded for bear. Welcome. Thank you both for joining us.

Daniel Holmgren: Thanks for having us, Jim. Also that that intro music hits totally different whenever you’re in the waiting room.

Paul Frazee: Pro tip, if you use Gusto, you could put a chosen name and Thunderguns has been my chosen name for quite some time, which means that whenever you get told you’re getting paid, it’ll send an email saying, good news, Thunderguns. Amazing.

Jim Ray: That’s fantastic. Well, you know, just a little bit of a little insight into how we operate here at Bluesky, the professional network. There’s been like so much news happening in the past few weeks. We’re going to run through it really quickly because I do want to get to, like I said, the main event here. We’ll always appreciate any color commentary that you have along the way. As a quick programming note, last night we set up off protocol to run on Voxport. Voxport’s a very cool atproto-based podcasting app. So we actually have. records on our PDS now. I did not realize that it was going to post to the atproto account, so I quickly went and did a little bit of cleanup, but check us out, voxport.

live. Speaking of being live, your baby, Mr. Daniel Holmgren, is the atproto spaces Alpha went live since last we’ve been on the on the live chat here. You know, give us the 30-second rundown of what’s going on with the atproto.

Daniel Holmgren: alpha. Yeah, we were super stoked to get that out. Basically, it’s a bunch of stuff. It has some STKs for working with the new protocol. There’s a distribution of the PDS that you can run and then we stood up alpha PDS that folks can sign up for accounts with. You can just get invite codes for that through the new BPS site to create your account on there. And then I also put together a little example app of using the protocol where you can have a bulletin board that your followers can or folks that you follow can post on, and you can view people’s bulletin boards that you follow as well. So yeah, it’s just been a lot of fun.

People are playing with that, kicking the tires on it. It’s great to see the developer energy on this. It’s like already implemented in a few other PDSs. I don’t know, man. People like just hopped on it immediately and started building stuff like it. It wasn’t even 24 hours before it was in PDSLS and Eteri and developer tools like that. And just seeing the stuff that people are building is awesome. So this is just our opportunity to like kick the tires on it, make sure it’s working, make sure it does what we want it to do, make sure it’s nice to build with. Please give us feedback on it. We want this to be something that we’re all stoked to build on whenever we actually put it out.

So let us know how it’s how it’s working for you.

Paul Frazee: Yeah, now is that time. Let us know, please.

Jim Ray: And also as a reminder, it is an alpha. So please don’t do something like migrate your primary account over to a PDS. with private data on it. Because, you know, things change. We might just wipe all that up. I can’t believe that it’s been almost two weeks since the atproto NYC community day happened. Paul, I feel like you are our biggest FOMO feeler in the room here today. And I know that you were you were you were missing being in that room. I did make it up just because I’m on the East Coast, so it was a pretty easy trip for me. And.

Paul Frazee: thanks. Thanks for rubbing that in.

Jim Ray: You know, I’m just I’m just trying to s to stoke the feelings.

Paul Frazee: here. The whole situation has been really hurtful for me personally, but I yeah, seeing everybody talking about it and going to it was extremely cool. I was extremely jealous. And I didn’t the thing that really was shocked me was that it just seemed to really happen authentically. It was like something that was cooking for a little bit and the next thing you know, everybody’s gone. It was Mecca. And I kinda was like, ah, I could have scheduled a flight. Shoot. So I do think that we’re talking to other meetups to see if we can’t make this sort of thing happen more frequently so that for the poor souls like myself that missed it the last time around that you get another shot at the goal.

So.

Jim Ray: I would actively encourage anyone who has a local meetup group to try to compete with what they’re doing with Apro DMYC to see if we can really get that some head-to-head contests. I know the folks down in LA are feeling that a little bit. Well they’ve got them some pretty big plans. But there were talks, there were lightning talks. I dropped a link in the chat to there were some recordings on streamplace, of course. I do think that the numbers wise, this one was about five three times bigger than last year’s. So the same folks that put together there were some more organizers and we had some product drops. Fig was showing off Hubble. Juliet announced Troposphere.

We had some amazing workshops. JD and Dr. K from Blacksky were talking about moderation. Trezy was showing off HappyView. And I have never personally experienced a Juliet lunch train before. And so just getting to experience that in the flesh was really something else. There was a whole unconference part of it. You know, I got to meet people I hadn’t talked to yet. So anyway, really, really great work. Thanks to everybody who helped organize, who showed up, all that kind of good stuff. So cruising right along here, I think one of the more kind of exciting things that were happening in the ecosystem is Sam Goto, who works on the Chrome team, was showing off what a potential Fed CM integration looks like.

Dion, as we were as we were getting ready, you were mentioning that was probably one of the more exciting things that’s happening. What is it that excites you about this Fed CM integration into Chrome?

Daniel Holmgren: Yeah, this is this is like so cool. If you haven’t seen it, go to Sam Goto’s page and just take a look at it. He gave an example of what it would look like to sign into. Leaflet, like how login with atmosphere is like at the top of everybody’s mind. Like we have to figure out how to convey this concept to users in a way that they understand. And it’s a little bit, it’s like it’s a new thing. It’s a new thing with like the atmosphere that you have this account that you take around to all of these websites that isn’t necessarily tied to like a particular brand or something like that. Like you can have this account with many different service providers and use it across many websites.

That’s a new thing and we can do decently with a text box and a button on websites.

Jim Ray: Yeah.

Daniel Holmgren: But if you push this down into the browser, it’s like really, really good. And it feels like the future of the internet. Internet. And we’ve been partnering with Amelia Smith and like hanging out in these FedCM working groups. This is all built around the standard Fed CM, which is basically pushing this down into the browser. So we’ve been like engaging in that process. It’s been going well and seeing Sam, who works on the Chrome team, getting excited about this and embracing it, it I think that there’s just like some really cool stuff that’s gonna happen around atmospheric login. So.

Paul Frazee: This is so much the tip of the iceberg of all the kinds of things that are happening underneath the water with pretty together the atmosphere branding and things like that. But given that it’s still just a wildly exciting tip to have coming up out of the water because oh boy, this could be such a great experience.

Daniel Holmgren: Yep.

Jim Ray: And integrating that into the browser really does solve a lot of the problems that we run into when it comes to UX and explaining it and things like that. So really exciting to see that work happening.

Daniel Holmgren: Yeah, it genuinely makes it feel like it’s your internet login.

Jim Ray: Yeah, right, exactly.

Daniel Holmgren: What the atmosphere login is.

Jim Ray: We had a couple launches on the Bluesky side of the house and we’d think about redesigning the notifications tab. Poor Danielle launched that from her personal Count. Danielle’s one of the designers of our team. And you really got to experience what it’s like to get lots of notifications all at once. We also launched 10-minute videos and the ability to hide your posts from Discover, a long-standing request. A little bit of an atmospheric feel to it. They can also read from that. Any takes on some of those releases?

Paul Frazee: I don’t know. Has anybody noticed that their Discover is getting a little bit better recently? I don’t want to say they’re related, but no the actually the Discover team has been doing some pretty good work as well, so we’ll probably make a little bit more noise about that when we’re ready to, but definitely give it another look. I’ve started to get a lot more use out of it. Notification stuff is also really exciting, I would say to everybody, keep your eyes peeled for possibly some more exciting things coming on the notifications interface.

Jim Ray: I will say it’s been really great seeing the Bluesky app team really get into their grooves. They’ve been shipping, it’s like, I feel like this summer has just been the summer of shipping in addition to being the summer of standard sites. So really, really awesome to see that. A few more announcements before we get into it. So leaflet is piloting paid memberships. Our friends at Graze joined the good people at Flipboard, which is just such a great collaboration. Graze on the feed side, flipboard on how you navigate all those feeds. Roomy is teaming up with the Modal Foundation, so great to see that there. Another great collaboration. The good folks at Germ launched voice notes.

I am I’ve never sent a voice note in my life and don’t put don’t plan on it.

Paul Frazee: But we.

Jim Ray: sick of that.

Paul Frazee: relations, guys.

Daniel Holmgren: You need to be about twenty years younger.

Jim Ray: Yeah, exactly. I feel like we’ve always got some kind of a standard.site piece here. Tim Disney has been cooking with Skyreader. He posted a kind of a forward vision about what’s going on with kind of his vision for Skyreader, which is awesome. Keith Kirsten launched Atmo BB, which I logged into that and immediately got hit with all of the late 90s, early 2000s bulletin board fuels.

Paul Frazee: I love that thing. That aesthetic is awesome.

Jim Ray: So good. And Keith, I think, has the best handle on the network. He’s KeithLaugh. love, which is just so, so very good. And then if you missed Toni’s AMA last week, we had a kind of a special live stream with our fearless ladder, Toni. The folks at Chicago. com are they’re bit they’re building an atproto-based kind of community site with the folks at Roundabout who are doing some great work with currently they’re doing some kind of Off Protocol bits for permissioned data, but are going to be moving into at protospaces Land. And then of course all the latest meetups are at atmosphere. community slash events. Okay, that was the quickest news roundup I think we’ve ever done.

Paul, you looked like you had.

Paul Frazee: I did. I was just saying saw something in the chat I want to say, but first boy, it’s a bit of a crime that we’re having to rocket through all that news because that’s a lot of good stuff each on its own.

Jim Ray: We said we were gonna give ourselves 10 minutes. We’ve blown past that, and now we are here for the main event. Surreptitiously, Daniel, you and Paul both launched blog posts within minutes, certainly within an hour.

Paul Frazee: Within 30 seconds. Yeah, within 30 seconds of each other.

Daniel Holmgren: We’re not joking. Literally no clue that the other person. I had no idea that’s all out of them.

Paul Frazee: Yeah. If.

Jim Ray: only there was some kind of developer relations team that would help.

Paul Frazee: to coordinate these things. Well let me just say I was furious. You know, the minute I saw that, I couldn’t believe what a process meltdown had occurred that my greatest enemy would be allowed to do such a thing at the same time. So obviously Jim, we’ll be having many discussions about that. But here we are now, I guess. And so I guess we’re just gonna have to deal with this head on finally address this simmering.

Jim Ray: We called it a blog off. It went, you know, started last week, went into this week. We’ve had multiple ways of trying to determine who won the blog off. We’ve used Attie.

Daniel Holmgren: No, my favorite is Haley has Haley’s robot which is a like Slackbot integration and she asked Haley’s robot to do an analysis of who won the blog off and it said Paul but then she said, do an advanced analysis. And it said, Daniel.

Jim Ray: Do a breakthrough.

Paul Frazee: And this is this is just a really good reminder to everybody that AIs can hallucinate and you have to be really careful about how you use them. It brought up the exactly something that we had already pointed out, which is like given the relative follower counts, Daniel outperformed me significantly, which is pretty fair. I think probably Daniel got some reposts by some, you know, accounts that maybe gave him a leg up, whereas I had to kind of carry it all.

Daniel Holmgren: back.

Paul Frazee: I think is maybe what happened. You know, here we are. And it was it was actually shockingly close, like within the network. They we were going like for like on it but then I did manage to make it to Hacker News with this, which I actually was hoping for. It was meant to try to reach a wider audience and say it went about as well as you could hope for a Hacker News comment section. So.

Jim Ray: it’s kind of warming to us a little bit. We’ve we’ve had some issues with that in the past. Let’s not.

Paul Frazee: go crazy here. I don’t know if no, yeah, I think that I think that everybody’s got different points of view that they’re working from whenever they’re kind of engaging with the AT Protocol. You know, a lot of the stuff that’s you got some folks that are just pretty dedicated to the activity pub world and we’ve been doing a lot more outreach to those folks. And so I think in fact a lot of that part is kind of calming down. The theme that really stood out to me, we’re just sort of jumping ahead to we do actually want to talk about the content of what we’re writing about. But I think the thing that’s out to me the most is that there are just still a couple of folks who are looking at it and going like why couldn’t we just do RSS?

Right? Which I think is a really valid like that’s just kind of saying like, ah, there’s a lot of complexity here and it’s I still it’s bouncing off for me, which is a completely understandable thing. In fact. It’s always been a shock to me that anybody understands what the heck we’re doing. So, you know, I think now we should just tackle that. You know, there’s a just a little bit of like I think something kind of coming up for me will be a step by step on explaining like why didn’t we make each of the choices as we did? And I think you could even do that by going like, all right. Start from RSS and then like add requirements and then you’ll pretty quickly get to an atproto-shaped thing.

You could change a couple of details, but the reality is that the choices I feel were quite pragmatic. We have always prided ourselves on being a pretty pragmatic crowd with the design and they all come from somewhere.

Daniel Holmgren: Well actually I think that there’s something that we should put talk about with your blog post real quick because you’ve had you’ve done a couple of talks lately at localfirstconf and render ATL. And I don’t know if there’s recordings of those online, but if there are, people should definitely watch them. I like they’re very, very I need to help design this protocol and I got something out of those you know. One of the framing devices that you use in that is talking about atproto as a data replication protocol.

Paul Frazee: Yeah.

Daniel Holmgren: And you like, you sort of hint at that in this blog post, but I don’t know. I think it’d be interesting to talk about that for a second. Because that really answers the question of like why not ActivityPub? Why not RSS? And it’s like, well, it’s just kind of a different problem, you know?

Paul Frazee: Yeah. Well, so with this blog post, the title of this blog post is Select Star from internet Docblogposts, which rolls off the tongue. The reason I started with that angle on this blog post was data replication is still kind of hitting you from kind of a mechanism and what I wanted to talk about here is like what are we aiming for? What is the what’s the point of the technology from a developer experience point of view? What are we trying to get to? And you the magic moment is that we are all someday gonna have infrastructure in which we can just easily fire off queries that hit the internet. And the delta between being able to do that conveniently and not is still an active point of development inside of the AT Protocol, I think, because having to engage with, you know, doing backfill and active replication and things like that is all the things that you do in service of getting to that point where you can just fire off a query and say, hit me with all the blog posts that happened in the last 24 hours from my followers so the way to accomplish that has been I you know in the blog post I chart and I actually cut a segment that I had talking about the last 15 years of efforts to essentially create that user experience.

This is kind of the thing that I think that a lot of the open web, open internet people have been just trying to accomplish ever since I would say the RDF era, the semantic web era. When TBL and the rest of the W3C was trying to push on this, how do we get to the point of structured data getting published on the web, not websites, these things that lead to walled gardens, but instead create an open database and it’s hard. It’s a really hard thing to do. And that’s why there have been so many shots on goal over the past 15 years. the basic answer that we landed on was data replication is the necessary way to do this because you need to fire off queries somehow that is going to span data that is being produced from lots of different services across the internet.

And you can’t do that in the critical path. You can’t wait to the time that you’re trying to satisfy, answer this question of give me all the blog posts and go to each of the servers and go, do you got any blog posts in the last 10 you know, last 24 hours. Like it’s just we all know that kind of like a federated query model ain’t gonna cut it. So you need to have some kind of a way to pull in all that information into a database that does actually hit the performance requirements of a real service. And so to do that, you kind of need to start to think about the entire internet as publishing data streams that can then be collected into technologies that we know do scale.

And or scale to the needs, you know, like if it’s a smaller thing, if it’s like a standard.site aggregator or blog post aggregator, I bet good money you could probably always live on the Postgres. You know what I mean? You don’t have to go crazy with it obviously, someone like Bluesky, a lot of content coming in all the time. We’re having to do things like using SolaDB to handle the kind of volume of read requests that we have to satisfy. The write-throughput isn’t even really the hardest part. It’s the read throughput. But some of that also tells you about the scaling properties. We also have 2.5 to 3 million DAU. So a lot of people to in you know more to go.

RSS the comes up a lot and I think for good reason. Because RSS essentially was a data replication protocol. It was so close to getting it right. And I think the basic problem is it just didn’t go far enough. It is not a robust data replication protocol. It gives you a small window into the past couple of items and it doesn’t get into specifying the many different details of like beyond just articles or items and things like that. So it ended up being wonderful for podcasts and blog posts. You know, I guess I’ll say wonderful for podcasts, because it certainly survived for podcast blog posts. It didn’t quite get all the way to where it needed to be to survive the walled gardens coming in and knocking them out by podcasts.

It kept doing it, right? And it remains resilient there so we want to have that take that intuition, what’s great about RSS and go, okay, all the way to the end, let’s make this entire internet work this way so that the there is a commons of data. And that’s how we stop the monopolization of the internet. Which is a goal worth having, which brings me to the other point about that blog post talking about Knitter, right? And what happened to Knitter recently where X said, you know what, putting a proxy in front of our site so that you can read pages, even that’s too far for us now. You have to go on to our s to my site.

This place where lots of people are producing, you know, their own information, their own activity, and just saying, you know what, let’s not even pretend anymore at this point that this is yours or that this is collectively, should be collectively owned by everybody. This public square is Elon Musk’s. You are staying here under his terms. And if there is any inch of desire within the internet community still to have an open internet. We have got to take these moments and point to them and say, this is wrong. This is not how the world should work and that’s what I’m getting at here. This is because we’re downstream of the fact that we never created that open internet database.

And that’s what we’re trying to introduce now.

Jim Ray: I there were so many things about your post that I appreciated. That that piece about RSS too, you had a thread my gosh, it’s probably two years old now on Bluesky that started off just kind of talking about RSS. And I remember that was one of the first pieces that I encountered this before I even worked here. that really kind of hit home for me what some of the architectural goals were. And then using the example of knitter, I think there was another one, X cancel maybe, that ran into the exact same problem. And it really kind of lays out very succinctly like the kind of the bargain that we made over the past 25 years, right?

Is that RSS, as great as is, would like it did have some usability issues. You know, in addition to like not quite going far enough into the data replication and adding some of the other pieces that we’ve been able to add on with atproto and things like that. It also just had some basic usability issues. And people always point to the fact that like, oh, Google killed Google Reader or whatever it was. But like at the end of the day, RSS was just kind of not quite there in terms of like a UX. And then Facebook and Twitter and everybody else kind of came along and essentially took the components of RSS and built the user experience around it, but as you’ve pointed out, like also built the wall garden around it.

Paul Frazee: Every technology that is an open internet technology has to meet users where they’re at. And we’ve seen time and time again that if you don’t do that, you’re just you’re gonna get beaten out of the market by the competitors who don’t care a lick about that, but will meet people where they’re at. And so there was just always with the RSS stuff, I wish I could go back in time and be in those rooms and press them on y’all keep moving. You can’t. This is we’re not done. We are far from done here. Keep moving. Here we are. Having those conversations now.

Jim Ray: And Amelia Smith just found that thread that I was looking for. So thank you so much, Amelia all right, Daniel, your turn. Good luck following that one, I guess.

Daniel Holmgren: You know, someone like commented on both blog posts and they’re like, yeah, it’s kind of like two sides of the same coin because it’s like in some ways it’s the same problem. In other ways, it’s like the flip side because we’re working on like non-public data. Or I guess like the point of this blog post is I’ve been writing this like permissioned data diary as we worked on as we kind of explored the problem space for non-public data and like tried to build up a solution to it. And there’s been all sorts of, you know turns and going back on stuff and conniptions about naming and all of these things. And after launching the alpha, I kind of like wanted to take a look at it, step back and be like now that now that we kind of know what we came out of this with, can we like look back at the original problem and sort of like succinctly remotivate this new primitive that we’re working with?

Part of this also came out of there were some conversations that I would say expressed some like surprise at the idea of having two protocols, both the public broadcast protocol and at protospaces. Which are really part of the same thing, the same network, even if it’s two different data mechanisms underneath it. And also like surprised that records couldn’t fluidly move between spaces. And so like kind of those conversations also played a role in like what I was trying to address in this blog post, like brought to the surface again what our goals were with this. And one of the big goals, like kind of the I’d say the biggest goal is that we wanted to be able to enable social use cases, right?

There’s a way to think about stuff as just publishing and that is like a big part of the internet is publishing things in a non-public way. Ultimately we’re trying to design a social protocol. And so the foremost goal was enabling social use cases. So like the thing that we went into in the design process was like this needs to support a private forum, right? Or a private group or something like that. that, which is different from saying like I use like a recipe app as an example. I have some recipes and I want to share these with different people. Right. Like I kind of talk about that as like permissioned publishing. Like you’re publishing something and you have some permissions on the thing.

that you publish. Whereas something like a forum, you’re establishing a shared social context. Ted Hahn called it common ground is the word in linguistics. For it. But you have this shared notion of space and everybody has the same understanding of what’s in that space, right? So that was like the core thing that we were trying to do with the design of atproto spaces. And I listed some other design goals and I really think that spaces as a primitive kind of uniquely thread these goals. And then to sort of like kind to sort of explain that, I talked about, I compared them to circles, which is something that has also come up, people draw comparisons. to circles all the time, thinking that spaces are basically like circles.

And the point that I try to make in this blog post is that spaces and circles are actually the opposite primitives for this problem. Circles is I’m abusing the term a little bit. I took the term from like Google Plus Circles.

Jim Ray: Right.

Daniel Holmgren: Take a post and share it with you know you could have your friends which have these 20 people and your family which has these five people and your what it but you had these different circles of people and whenever I publish a post I say okay I want to share this with you know, friends, family, and colleagues, right? Or something like that. Instead of just pa instead of having something like what people were familiar with Facebook, where you just have friends as a list of everything. So it kind of gives you these like dynamic social circles. And the way like the extreme version of that, if you were to apply that to the atmosphere, which is this like Universal data network, multimodalities, all of these like very dynamic, remixing stuff across social context.

The extreme version of this is to say you have these circles that accounts define and anyone can use that circle on any piece of content, right? And out of that you establish these shared social content. So for instance, if I want to set up a forum like a protocol nerds forum, I create a circle and I list everyone that I want. in the circle as a protocol nerd or whatever. Maybe I have like a thousand of us in there or something like that. And then whenever I create a post in that forum, I tag it with the protocol nerds. circle. And anytime someone replies to it, they also tag it with the protocol nerd circle.

And if you upboat it, you tag it with that circle. Anything happening in this circle, you tag those pieces of content. With the circle. And this is like sort of the opposite notion of what spaces try to do. It’s like the focus on with circles is it’s still individuals publishing something and tagging it. with an ACL. Like the content is the foremost thing and then you’re tagging it with who gets access to this. And spaces sort of takes a different approach where it has this notion of locality baked into it. It says first, we’re establishing this social context. And everyone participating in it has this shared notion of the social context. And then I’m posting something.

into it. So the sort of the locality is has primacy and then the content is posted into that space. I would say maybe like the biggest rationale for this is just like legibility of the network. It’s like we’re doing something pretty zany with the atmosphere. It’s like kind of confusing as a user whenever you first encounter it. Just like the web was really confusing and it took years and decades for people to build up intuition around it. And I think that you need a core grounded concrete primitive for people to build intuition around it. And the example of that with the web is the web page, right? And if you look at the web, it’s like, what do people trust?

There are very few trust cues on the web, but if anyone has if there’s any one thing that people actually trust, it’s domain names, right? And that that’s like the core intuition underlying this whole like modality of browsing the web and going to different websites is that you can trust the domain name as the concrete legible thing that instructs like the entire like model, you know. And so I was looking for something concrete and legible to structure social context and social interaction. And I think spaces give that to us in a way that it was like really hard to see how you got there with. Sorry. There was waxing codic on that proof. I hope that made sense.

Paul Frazee: Well, so yeah, let me if you don’t mind, Jim, I want to follow up with a little back and forth with you, Dan. So you know, one of the things I think we’re all doing right now is engaging with these the choices and trying to weigh like, you know, you know, how does this hit us? Where is the this approach useful versus do we want to modify it? And I think all of us are also looking for a beat to sit with it and kind of find where we’re at. So the important thing is that we have that beat and then we render kind of our feelings. Now what you’re really getting at, I think the locational aspect of it really is the most important thing.

Spaces are, interestingly, they’re not in an abstract sense. And the in the s in that sense of whenever you use an API, you kind of have this like material notion in your brain. Like a like when you say like a file with that’s like ten gigabytes feels heavy. You know, I mean there’s this kind of like new sphere sort of concept that you get out of like the ideas. And in this case, location. It’s that a space is a place. in the kind of abstract sense and that things are going into it and that you’re publishing within to it. Which is one of the reasons I’ve also liked the s kind of misleading but accurate enough notion that each space is like a mini ad.

Daniel Holmgren: proto.

Paul Frazee: Because it you know, it still works like atproto, you’re still publishing records off of your repository within this space. The semantics from that look and feel sense are still the same. It’s just all living underneath that. When we’ve been having conversations about this internally about making the spaceness or the locationness of spaces upfront, having it in the URL even. The general sense has been that this gives you the exact right understanding of what’s happening when you’re using the technology this is this is the conversation that’s happening now. Is like, does that give is that intuition at the right, is that the right intuition to work from? I think we’re probably the spaces concept is pretty locked into that.

There is a locational nature to it. Do we want to abstract that away at all or in certain use cases? I think that’s the question that we’re now engaging with. And I think that’s what we’re kind of waiting to hear. from everybody as they not just didn’t get their initial reaction to it, but also spend some time with it to be able to tell us, yes, that that placiness really should be right up front. Or, you know maybe we could abstract that away. I think that’s what we’re one of the big conversations that we’re engaging with now. And so far, it seems like the locational aspect of it being right up front is resonating with people.

But it is the thing that I think we have to focus on communicating now.

Daniel Holmgren: Yeah, it is a new thing because the your the initial whenever you first hit this problem, like your shoe from the hip reaction is you’re like oh yeah, throw some, it’s like, oh, you don’t want everything to be public? Throw some ACLs on the content. You know? That’s like my that was my shoot from the hip reaction to it as well. That’s like how that’s where you come in from and it is like kind of a shift in thinking to say actually we’re pushing like we’re introducing this new notion of locality into the data. Like that is a different way of thinking about it. And it really shines in some use cases. Whenever you’re establishing social context, I really, really think that this shines.

People have correctly pointed out that it’s not as well tuned to the permission publishing, right? If you if you’re it’s least well tuned to having something where you publish individual pieces of content and every piece of content has a different access control list. Right. That’s the use case that it’s like least well tuned to. I do think it still works. And I there’s always an escape hatch on this, which is like you can just share it with applications, put app give applications access to the space and then applications can do kind of arbitrary access control logic on it. And but I still think it works in those use cases, but people are correct to point out that it’s not as well tuned to those as it is for social context.

But I just also think that the shared social contexts are the interesting thing. I think that that’s like the future of the internet. And I think that that’s the thing that it needs to be built into.

Paul Frazee: So an interesting, if you don’t mind to press on that a little bit more, let’s say I let’s do that recipe example. So I’m going to publish a do a private publish of a recipe that I only my subscribers or my friends or whatever are supposed to be able to read. That’s under a self-space. It’s under a space that I control that I’m choosing who can access it and stuff like that. And that’s where you get into that realm of like, maybe we could like somehow shorten the URL. You know, there’s kind of like an implied selfness to it. Maybe there’s something you could do there. And we’ll just put aside. We’ll see. You know, maybe, maybe not.

Don’t really matter. But that’s where you start to get into this realm of like the placiness is sort of like redundant. Maybe I can we’re get rid of that. One of the interesting things to observe is that the comments, the likes, any of the interactions from other people, that actually is entering into that has a placiness. That’s happening in the space. It is for you, yourself space, right? But all those comments and all that stuff, that’s actually in somebody else’s place in somebody else’s location, the space. So that’s one of the areas where you pretty quickly find discover like, oh yeah, you could abstract away the placiness of it. Oh wait. One step forward and you go, no, I’m now all the interactions that are happening around it are in that other in that space.

Daniel Holmgren: Yeah.

Paul Frazee: So that’s another reason why I think we keep coming back to even whenever it feels like, ah, well, I’m just doing this myself. you know, this is a personal a private publishing thing. It’s like, no, any interactions that happen afterwards, if they’re gonna be in that space, the place is right back up front.

Daniel Holmgren: That’s exactly right. It’s like anytime, yeah, anytime you want social interaction, like you’re establishing a social context and that social context kind of has like rules about who can participate in it and who can see it. One thing that I ran into, like as I was like, I spent a little bit of time looking back at Google Plus circles as I was writing this. And like one weird thing about it is that if you if I share a post with friends and family, right, and one of my friends comments on it, my family can see it right. And so you’d think that you’re treating these as two separate circles or something, but really what you’re doing is you’re establishing a shared social contract.

That both of those circles have access to. Right. And Google can abstract over that because it’s like a centralized server and they just like can do all of this stuff. But if we’re trying to encode those semantics in a protocol then you actually can’t like your friends have to apply the family your friends have to apply your family ACL to their content to give the same experience, right? And like the only way that you can do that, I think, is like by establishing one of these shared social contexts around stuff, if you want to enable that same thing. So yeah, I think I think you’re right, Paul, that anytime yeah, whenever you get into social interaction, you just require one of these shared social context in order to like facilitate it.

Paul Frazee: Like Waze washing against the beach we will or against a rock cliff we will erode down. over time, the to the necessary core of it. And if everything we’re saying here still holds, then great, we’ve already got it. But I think that’s part of what we’re doing now is like we’ll keep we’ll keep stepping up to the plate and trying it as it currently exists. And then if it turns out, oh, you know what, there are some abstractions that make sense, we’ll find them. You know what I mean? But that’s what we’re all doing together as a community with this, I think, at the current stage.

Jim Ray: As we kind of wrap up here, one thing that I have enjoyed about working with the two of you on is, and we this has come up in a couple of different ways in this conversation, is the most obvious or maybe as we often say the most kind of naive implementation is often not the one that ends up making sense in the end. I think if I were to sit down and figure out like a permission space is way of doing it, I would I would have veered toward something like circles. And even going back to some of the points you were making in your piece, Paul, about how to do these decentralized networks that actually scale, I certainly would not have come up with the way that atproto works.

And I even think about some of the kind of more elegant concepts. Recursion was one of those things for me. When I first learned recursion, it was just kind of like this doesn’t make any sense at all. And then at some point it just kind of snaps and hits. As y’all have thought about your careers, because you’ve both taken cracks at this one in a couple of different ways before. So I maybe what are some of the things that have helped you? Is it really just kind of like going back again and again like that wave up against the rock or how have how are some things that that have helped you think about some of these things a little bit differently, a little bit more dynamically, and not just going for that first naive implementation?

Daniel Holmgren: Yeah, that’s a good question. Well, for I’ll share maybe my favorite compliment that I’ve received about the protocol. I think I think Ziklag said it. atproto stuff always seems like a bad idea until you think about it I like my ideas are initially hitting people as bad ideas. The thing for me is that it’s like I think like simple ideas often hide like a hidden complexity and sometimes you can have a more sophisticated idea that has like or more complex idea or something that hide that hides like a deeper simplicity. I and I think that that’s the thing with spaces and circles. That’s also the thing with in one of my data diaries about like the I forget what I called them, but if you store everything in a space in the same spot versus storing it on the author’s PDS is there’s like sort of conceptual simplicity to say everything goes in the same spot but it actually hides all of this complexity that you inherit the second that you start doing it and pushing it out to the author’s PDSs isn’t maybe the initial way that you think about doing it, but you get all these like really nice like simple things.

Paul and I both share a history in like the peer-to-peer ecosystem. I always felt this feeling of vertigo in a lot of peer-to-peer stuff. I’m just like, it was, it’s very hard to find solid ground. You know, like we’re trying to do something and you this whole thing’s eventually consistent. And some event can come in from years prior that makes me reshuffle my entire history or something like that. And I’m just like, when do I ever get solid ground. And so there’s several things in atproto that are, I think, kind of responding to that feeling that I had, which are just trying to make things concrete. It’s like you have a repository. That repository tells you exactly what’s in, exactly what’s out.

These aren’t just records flying about in the ether. You’re not going to be like, oh, there was this record that I just missed for years, and now I found it. No, you have a you know exactly what’s in, you know exactly what’s out. You have this very concrete data replication protocol. To me, a space is similar to that. It’s this concrete thing. Shared social context, everyone that can read it has the exact same view over it. And so I think I like look for things like I think that that’s probably the thing that I learned from earlier in my career. It’s like whenever you’re in this flux. There’s so many variables. There’s so many dynamic things.

What can you make concrete? And then that concrete thing gives you a foundation that you can build up your model off of.

Paul Frazee: Yeah, I think my big insight right before atproto while working peer-to-peer, and this is a funny thing to be a big insight, but it was it cannot be rocket science to implement a comment.

Daniel Holmgren: section. I.

Paul Frazee: just been I realized that somewhere around like twenty-one or so that I was just like, for the past ten years I’ve tried to do this probably six times and each time gone like ah, you know, screw it. It’s like, wait, wait, what is going on here? This is rookie. Regarding this question of like simplicity. Or like the kind of surprising way that we come in sometimes to sol solving things, there’s a pretty well understood idea of essential versus accidental complexity. For any kind of, you know, real world application that’s operating at a larger scale, social application in particular in this case, right? There’s a lot of essential complexity, actually. Like the it’s just not a small thing to implement a social network.

You’d be surprised when you really get down to it for a product surface like Bluesky, which seems very straightforward and how you kind of receive it at its core. how many different touch points there are in there, how many things you have to do to get to get it right. It’s very shocking actually. So if you have a target experience, which has a known high amount of essential complexity. And then you have some solution come along, some spec. If the observations about that spec is that it’s an incredibly simple spec, then it’s actually under specified. End of story.

Jim Ray: Yeah.

Paul Frazee: We were we decided that we were going to be thorough in the specification up front. And we have I think we correctly identified it. We can simplify the abstractions later and start talking about it more simply in its entry points, which is right, which is why we now say things like, it’s just JSON. Because in a lot of ways, you know, like what is that look and feel story like, right? And this is when it reduces it down to its w the contact points of the developers, that then you can, right? But along the way, you actually have to specify how this network functions. Regarding spaces in particular, Daniel, would you say this has been an easy protocol to implement and design?

Daniel Holmgren: To design, no. To implement it actually is.

Paul Frazee: Very true, right. Well we s from the beginning.

Daniel Holmgren: It’s been a constant thing of questioning assumptions. that I that I had.

Paul Frazee: The design space was broad, multivariate, and had an incredible kind of combinator combinatorial effect as you would take different decisions. try something else, see how that would affect the entire system. You and I both and other members of Bluesky for since we launched have been taking passes at it. in our private time up until this year. prior to you formally starting to work on it at the beginning of this year. I had done two more passes on it in a little notepad that I walked in with. And they it all looked different. We got together in a team week at the end of last year and we whiteboarded and came up with like three or four different ideas.

It looked different than this.

Daniel Holmgren: Yeah, totally.

Paul Frazee: And for at that point, I was pretty convinced that there wasn’t going to be a single solution to everything. I was beginning to suggest like multiple kind of use case specific solutions. And we still have an invites question, which may end another conversation, but we’ll see. But that’s a s much smaller problem than what I was kind of or solutions based than what I was describing. Nonetheless, yeah, this was a this is a tricky one. And as somebody that’s been on the outside or and the inside of that seeing what Daniel came up with. I don’t want to like gas it up you know state propaganda now but I’m impressed you know like I was impressed by the fact that you did manage to find something which by and large is pretty straightforward compared relative to the difficulty of the of the problem space.

So as you’re as folks are looking at it and like engaging with it, just know that like it matters that it is easy to engage with, and it matters that everybody loves the feel of working with it and feels like it’s doing what it needs to do so this isn’t a you know an attempt to deflect critique. We want that. We want everybody to engage honestly with it. But also just know like when you hit those moments of complexity, just there’s quite a lot in there. There’s a lot of history and requirements that are inside of this thing. And the design came to where it did for some pretty good reasons. We.

Jim Ray: we’ve got a great comment in the in the chat here from lineelevin.com. atproto is probably the first time I’ve seen a decentralized data ownership that isn’t complete complexity slop. So that feels like as high a compliment and lots of people agreeing and thirding and fourthing. So.

Daniel Holmgren: Well.

Paul Frazee: happy to hear that.

Jim Ray: I feel like maybe we entered as enemies and we’re leaving as friends. Is that.

Paul Frazee: no? Nah, come on.

Jim Ray: Is that too much to hope for?

Paul Frazee: Let’s not force it.

Daniel Holmgren: The real friends are the protocols we designed along the way.

Jim Ray: All right. Daniel and Paul, I can’t thank you enough. Excuse me, Thunderguns. And thanks so much for popping in. We’ll have to do this you know, once a quarter at least, where you both just throw out some competing ideas at the exactly the same time. I’m gonna actually try to try to make that happen more often.

Daniel Holmgren: Yeah, yeah, work in the work in the background. Make it happen without us knowing.

Jim Ray: Exactly. So the response to the announcement was pretty good. So people love a little bit of you know what’s what they say. There’s a story without conflict. So.

Paul Frazee: that’s true. Well I just hope next time Daniel can bring a little more heat because it if it’s gonna stay interesting.

Daniel Holmgren: Yeah, yeah.

Jim Ray: Thanks again, fellas. I really appreciate it. And we’ll get this one on the podcast soon and then we’ll be back on our regular live stream schedule shortly. Thanks again.

Daniel Holmgren: Sweet.

Paul Frazee: Thanks everybody that joined us.