Bluesky & Open Social Media Tech
[Bey] Welcome to, welcome to the Berkman Klein Center's Spring Speaker Series. Every Wednesday, we gather top academics, industry experts and tech professionals to share cutting edge insights on AI, social media, and more. Today, we are happy to welcome Paul Frazee.
He is the Chief Technology Officer of Bluesky Social and the founder of Blue Lightning Labs, a startup rethinking the web using peer to peer technology. Welcome, Paul. [Paul] Thank you. Thanks for having me. So, are we ready to kick this talk off? It looks like we are. Let's do this. Hey, everybody.
Thanks so much for tuning in. So, the title of my talk, Bluesky and Open Social media. I'm, Paul Frazee. I work at Bluesky. And before we kick off, let's just talk about Bluesky real quick.
We're a public benefit corporation. We develop an internet technology called the atprotocol, and we also build the Bluesky social app. Now most of our code is open source, including that Bluesky social app. Often it's either MIT or it's dual licensed MIT or Apache and a fair amount of all that is what we're going to be talking about here today. Now, in the description for my talk, I wrote for the opening sentence that social media is undergoing a transformation towards open internet technologies.
And I posted the link to the talk and somebody replied to me saying, well, what do you mean? Because social media started with open internet technologies. In fact, I gave a talk 13 years ago about that exact topic to the Berkman Klein Center. And here's the link.
And of course, they're right. Social media did start, with open internet technologies. Around the turn of the century, we had a nice suite of them.
And this was all part of the pendulum swing away from the large service providers that AOL was emblematic of and into the internet culture, which was much more about these open standards and building systems that interoperate with each other. But of course, things changed afterwards. And there are two things that I generally attribute to the swing back away from the open internet technology approach. The first was the release of the iPhone, which brought in mobile computing as a really dominant paradigm of personal computing. And unfortunately, the web did not persist as the application technology in the mobile world.
We moved over to proprietary and closed mobile application tech and also, into the App Store model of application distribution rather than the open internet. We also had the rise of very large social networks and the large social networks also not, inherently built on open technologies. And they really became the dominant means of distribution of information and communication between each other. Now, the reason that we kind of, in aggregate, all moved over and away from open technology is because these products were better.
They were able to be built more quickly and they were more profitable. And so they were able to run away from a lot of the efforts to maintain open technology standards. But now the pendulum is starting to swing back in the other direction, and internet protocols are back. The reason for that, I would say, is that the sort of innovation curve that mobile and all the, internet providers, all those applications were riding on has crested. The markets have become relatively mature, and there are a lot of asks that people have a lot of changes that they want to be able to see, but they're not very empowered, to, to make those changes. And so I think people are a little bit tired of feeling powerless about how online social spaces work.
And that has driven a resurgence of interest in the pendulum swinging back into open internet technologies. So now we're in this period 20 years later where there's a nice new suite of protocols being worked on. Some of them continuances from before, really email and RSS are still in there. And then we have some of the newer ones that are trying to make inroads. Now, all of these different new entrants into the technology space tend to talk about this word cloud of different attributes that they're looking for, things like censorship, resistance, possibly getting into data ownership, algorithmic choice, privacy, things like that. For us at Bluesky And with the AT protocol, there's one attribute that we chose to focus on the most.
I mean, a lot of these attributes are or factored in some way, shape or form. Some of them aren't. But the one that we care the most about is interoperation. This is the target that we were most concerned about as we were working on the AT protocol and in our operation. I think I'll just loosely define it as the ability for two different products, two different applications to work together seamlessly, as if they're a part of the same application as if they're from the same company, able to work together on some shared data space on a shared social space, things like that. Well, why do we care about interoperation? Interoperation means choice.
Whenever you have a world that functions with interoperation, you can have one application. You can have five. You can have ten, as many as you want, that are all working on the same goal, working in that same space. And if your interoperation is working very well, you could start with one application, discover another one that's better, or have a new one come out that you like better, and you could switch over. So interoperation means choice. Of course choice in turn means competition.
And competition is very valuable, at least in the world that we operate in. We like to use markets. It's certainly one of the techniques that we use for kind of collective decision making in society. And markets need to be healthy and competitive to actually represent the collective decision making that they're supposed to. So competition is generally valuable means that we have more choices Relatedly interoperation means shared ownership.
It means that you're able to work in a world or live in a world where things are not owned by one company, making the decisions on behalf of everybody but power is delegated out to the edges. And that can happen while still collaborating in a shared experience. Now, speaking of not very new, interoperation has been around since the beginning of personal computing.
This is the model that I think probably everybody is the most intuitively familiar with, and that's when you're using a desktop application. Desktop applications work with files. And so you can have a text file and you can open it in Notepad. And then you could switch over to some other app like RDS code and work on the file. Both applications are able to work in the same shared data. Interestingly, they don't have to collaborate on this.
They don't have to speak to each other. In fact, they don't even have to be aware of each other in most cases, they're just working on the file. And then another application works on the file.
And it just kind of happens by default. In fact, the web also work to some degree this way, with websites publishing their information and then other applications, different search engines, different RSS readers were able to pull from the website and offer products that were in that shared space simply by reading from the websites. Excuse me. So, this is a model of interoperation that I like to call non-cooperative interoperation because the applications don't have to cooperate with each other.
They don't even have to know about each other. They're just working with a shared data space. And so this is one of the primary models. Of course, if there's non-cooperative interoperation, there's probably also cooperative. And there is.
And that is best embodied by email. In email you have two different email servers communicating with each other, sending messages to each other. But this is a cooperative act. They have to speak to each other to make the exchange happen. And they could choose not to. The sending server could choose not to send along the message.
The receiving server could choose not to accept it. And so this is the cooperative model. Now the AT protocol actually uses a hybrid of these two things but it is primarily non-cooperative.
And we'll talk about why that is a little bit later. And we'll talk about how cooperative works its way in. But to start to give some shape to this, I'm going to need to explain a little bit about how the protocol works.
In the AT protocol, everybody has a personal data server, what we call PDS. And the PDS is actually pretty dumb. It's a pretty simple service. It hosts your account so it keeps online your posts and your profile and your followers and things like that. It hosts it publicly for the world to be able to access. Let's take a look at some of my data on my PDS.
So this is actually looking at my account, using a tool that somebody in our community built called PDS LS. And you can see here all of my different data collections. I've got a profile, the app.bsky.actor.profile.
Very easy to read that. But there it is. That's the profile. You've got my posts, my likes, my reposts. I see my followers and my blocks. They're all listed out right here. For anybody to be able to read.
Almost like a file in a file system. And if I look at one of my posts, here's something that I posted recently trying to rile up the gaming community. Very simple record here, establishes the type that this is a post.
It has some text inside of it, declares what language it is, and when I created it. Now PDSs are very importantly, very, very affordable. They're very cheap to run. I pointed out to one of my engineers, I could probably say get $20 a month server. You can handle a thousand users, right? And I said, yeah. And I said, well, what does it cost us to do this, you know, at scale? And we went in random math and found it's about 0.12
cents per user at the PDS level. And this is just part of the stack. This is not the kind of representing the full cost, but this is what it takes to host your account in the atmosphere. And it was very important that this be cheap because we want anybody to be able to do this. This is your account, this is your data.
This is your identity. It needs to be quite a resilient part of the system. So PDSs are very cheap.
The account hosting is very cheap. It's a bit like a website. We also we're very keen to build this idea of portability into the PDS layer, which means that an account can move between one server to another in the PDS layer. Because if you don't, then PDSs could start to use that lock in to really bind people, you know, and start to be extractive and so we wanted to have competition in that hosting layer. And so account portability or account can move from one to the other key attribute of the PDS layer.
One other fun detail is that everybody has a web address. This is how your usernames work in the system. The reason that we use web addresses is actually pretty simple. We needed a global namespace. We need a way to give people usernames.
We wanted to have something that generally people were comfortable with as a shared infrastructure. And so we thought, well, DNS is pretty well accepted. So if you're looking for me on Bluesky, look for @pfrazee.com. And that's my username. And the thing, works out pretty well. As it turns out, this can also be a pretty useful identity signal.
And then quite a matter of verification. So in certain cases, if you see, for instance, The New York Times, it's the nytimes.com. That's a nice signal of, you know, truth of who they are, because some domain names are well-known. And that's useful to be able to reference whatever you're in the social media environment.
Now, how do applications work? Again, this is kind of like the desktop applications. The apps just talk to the PDS. This diagram is representing reading and writing a post to my PDS here. Got the social app on the left and the user's personal data server on the right.
Reading and writing these records. That's the foundational idea. And to build this large multiplayer experience that we're used to with social media, what you do is you aggregate the activity from all the different PDSs. So an app will crawl across all of these accounts that are being posted publicly, and take up the posts and assemble them into a timeline to make the application experience work. And in this regard, it's a little bit like search engines on the web just drawing in all that data.
That ends up turning into a firehose of data, of posts. So this is a screenshot of another community application called Firesky. If I was actually on it, what you'd be seeing is these posts just whizzing by because it's actually a live stream of all of the traffic that's happening. And here's just a quick snapshot that I got. Now. The applications have a lot of freedom to choose how they view the data.
Again, much like a desktop application can choose whenever they're working with files. The user interface, the algorithms, the moderation. Those are the application's concerns. The PDSs are very dumb, but this is good because it means that the applications can choose to make changes to, have some ownership of the outcomes for, for their social network and move it in kind of whatever direction they want.
And here it is in the case of Bluesky, this is a screenshot of my home page. If you were looking listening to me describe the system and going, that will never work. Well, here it is. So I got that for you. And, as intended, it's meant to, feel quite similar to, to the experience that we're used to.
It was very important to us from the outset that we were able to prove that this open network is capable of achieving the kind of social experiences that people expect. And in particular, we were very concerned about scale, making sure that a system like this could scale up. We're now at about 4 million DAU, and we have about 35, 36 million registered users.
I'm pretty pleased with that scaling amount. I think there's still a couple of orders of magnitude to go. But, at this point, I'm fairly confident that the architecture is holding up, that we've crossed some of the important barriers to feel confident about this. So here's where we're at. So in review we have the PDS, hosts user data, very cheap to run. And then you have applications that talk to the PDSs, interpret those data into the social media experience.
Well now let's get back to the interoperation. Unsurprisingly we interoperate through the PDS. And this is that non-cooperative model. One application will read and write posts. Another application will see the posts suddenly show up and be able to read it from there.
So they don't have to talk to each other. The foundational model of the AT protocol is that non-cooperative interoperation. And again, just like with desktop application sharing of a file. In fact, one of the ways that we think about this is it's not just, that you can interoperate, but to some degree it's forced. If you are using the AT protocol, you are using non-cooperative interoperation. You don't get to choose as the creator of the application if other applications are going to be using that data because you don't control what the PDS, who the PDS speaks to, that's separate layer, a separate part of the system.
And this is our way of locking in or locking open, the system so that we can have that credible exit, we can have that shared ownership, and we can have that competition. So I've been talking about the sort of theoretical basis or mechanics underneath it. Let's move into some examples and see how this plays out in the real world.
This right here is a fork of Bluesky called deer.social. There's actually a lot of different Bluesky clients out there. I don't need to play favorites, but this one has been talked about the most recently. So I'll give deer.social a shout. And so they took our code. They forked it.
They began to introduce new features. Now, historically we've had a lot of clients come in, but those clients continue to use the Bluesky back end. But just recently, there's been a lot of really great work on running the entire stack independently of Bluesky. A very important step forward for getting into this open and decentralized world that we want to have.
And so here we have a screenshot of a stop server running. And you can see there's the Bluesky application back end and the aggregator process running. And here we are in deer.social speaking to that independent back end, speaking to a PDS that is not operated by Bluesky using the network.
Really happy that we've started to cross that milestone and see people hosting more and more of the infrastructure. Now we have a fork here. What else has happened other than independent operation? Well, verification was recently rolled out.
And of course that's a hotly debated topic, how to do verification best. The way the we chose to do it is, we are able as Bluesky to issue verification. We have our process for doing that. But we also introduced the ability to appoint users, with the ability to issue verifications. But there's a set of users that we choose, so that we can uphold some standards for, you know, making sure that a process is being followed.
It's a little bit like the certificate authority model. So we call those trusted verifiers and, some of our users, after this release, say, well, why can't I choose my own trusted verifier so I can make that decision for myself, which was something we had considered but ultimately chose not to do. In the interest of speed and to make sure that we feel good about the outcomes, we felt it was, we weren't ready to take that risk. Well, deer.social was, so deer.social introduced the ability to select your own trusted verifiers and also yourself to issue verifications.
And so it becomes more of a web of trust model as opposed to that kind of certificate authority model. And so now inside deer.social you can have verifications that are being given by other users who you choose to trust.
So that's a case of choice driving innovation. Deer.social is willing to take a, make a bet that we didn't want to make. And that means that the entire ecosystem can move forward independently of Bluesky, independently of whatever application happens to be the dominant one, that there are options out there that can be driving forward new ideas. So now that is all happening at this non-cooperative, interoperation layer.
And I mentioned that actually I thought it was a hybrid. Sometimes we use cooperative interoperation. An example of that is how we do feeds. Feeds are essentially a, how would I put this, might be easiest to show. It looks like this. It's a just a feed, right?
It's, it's a, list of posts that you can scroll through, right? Core part of the social media experience. What we're looking at here is the news feed by Aendra. She does have this feed so that, it, only shows, posts from a set of news organizations that she has curated, and it shows the posts from them when they're posting a news story. So if you're looking for you know, morning read of the news and you want to go from these, sort of approved, journalism, list of journalists, that's what this is for. But this works by interoperation, the news feed is actually hosted on somebody else's server. And Bluesky, whenever you visit the, the feed Bluesky talks.
So that server, it says, hey, what are the posts that you want to show next? And those come back and get hydrated into the experience. And because this is running on somebody else's service, it can actually apply relatively sophisticated logic for the selection. So to show that I'll show another custom feed that somebody made called Quiet Posters. Quiet posters works off of the following graph of however it is it's looking at the feed, and what it's choosing are the posts from people that don't post that often. The folks that tend to get lost in kind of the noise of things, makes it a very valuable feed, because you do tend to lose track of the folks that only post maybe once every two days.
Three days, good friends, for instance. They're just not as online as everybody else is. Really good chance to keep up to date on things. So the feeds are actually able to do their own algorithms, which introduces algorithmic choice. Another example of this cooperative intro is how moderation works. Moderation in the, certainly in Bluesky.
And this is to some degree core to the protocol. We use something called labels. And they're essentially tags or metadata that get attached to an account or to a post or things like that, indicating that, you know, some kind of decision has been made, for instance, this post might be NSFW, or it might have graphic content or things like that, but it's an open system actually, the application has moderation built in one of these labelers built into the application, but end users are capable of standing up their own moderation service able to publish their own labels. And here we're looking at one by a user named Bossett called the Profile Labeller. And this one is actually automated. What it's doing is it's watching the firehose and pulling out objective facts about the different users and putting up labels to work as annotations.
So some of those labels might be this user recently changed their handle or this user doesn't have a full profile. This user only ever replies to peoplw, the true reply guy. And then whenever you enable one of the. When you subscribe to one of these labellers, you can choose how to handle, these different labels. So I could choose, you know, if somebody has recently changed their handle, I can't imagine why I'd want to do this, but I can hide the user entirely.
I don't want to see their posts, or I could choose to just show a badge indicating, hey, this recently happened with all information for me. An example of that you can see here. This is somebody's profile. And down at the bottom where that little red arrow is, there's a badge put on them.
This is a label from the profile labeller saying that this is a bridgy user. Bridgy users are essentially users that have been bridged over from the activity pub world. So this is probably somebody using Mastodon, which is a that bridging is a whole other topic I won't be getting into, but I like to have this one on because I like to see how it's going and make sure that it's working correctly. So it's great to be able to see that little badge on their profiles, on their posts. Another example of this is the pronouns labeller, where users can inform the labeller which pronouns they prefer. The labeller puts that label on them, so I'm able to badge users, and I know exactly what pronouns to use for somebody.
So in this case, the shared ownership creates extensibility through the feeds, through the moderation, it makes it possible for end users to extend the core experience, and conveniently, relatively nicely. It's not actually done in the client. It's not some plugin that you're having to install.
This is all happening in the, in the back end layer, which makes it very low friction. Now that I've explained feeds and labellers, I want to call out, the work by Rudy, who's actually one of the members of ASML. Rudy has taken both of these, systems, the, the feed system and the, moderation system to start to build a community called Blacksky. And what's really quite compelling about what Rudy is doing is that, he and his, his group are starting to build out their own implementation of all of the infrastructure for running this community. They also even kind of moved ahead of us and introduced an informal way for users to join this community. I believe us by posting something like hashtag #addtoblacksky I believe, that they get reviewed and they get pulled in as a member, and that membership database is being maintained on their own infrastructure.
And the vision, with Blacksky is that this space can operate completely independently and perhaps even survive beyond Bluesky. And it could be possible to build entire applications that are focused entirely around the stack, but still capable of entire operating and being a part of the the Bluesky experience. So shared ownership then, is enabling independent operation, pushing ownership, pushing decision making out to the edges of the network instead of keeping it centralized underneath the organization that runs the main application. Finally, I want to rip through some of the different applications that we're seeing in the space. The feeds that I mentioned before, like the one that Rudy has made with Blacksky, like the news feed, like the quiet posters, they run on their own servers.
And as it happens, Bluesky has never actually integrated away or created a tool for people to create feeds. There's tens of thousands of them, but none of them have been made using the Bluesky app. They've all been made using other applications that members of the community have built. Graze is an example of this.
This is a feed builder for Bluesky, and they're doing really great work with it. They're starting to really grow their world. Prior to Graze, there was SkyFeed.
Same idea, much more indie energy. In fact, there's a number of feed builders out there. Another, great thing happening right now in this, world is Surf being built by the, Flipboard, company. I got to see a demo of this thing, and the design is absolutely beautiful. And this is, it's I've heard them pitch this as almost like a browser for the, new social web, and it actually supports both activity hub and atproto and it has these really great tools for creating your own feeds and pulling feeds from both networks.
And I think it'll end up being a really cool product. Taking a little bit of a turn here, we have, Skylight. This is a completely different application that has a more of a video shorts experience as opposed to the text posts. The microblogging that we do is the, microvideos.
And, this, I believe, is. Yeah, this is available now that anybody can try this. What's really cool about Skylight is that it uses the same data model that Bluesky does. So skylight users can see Bluesky posts, and Bluesky users can see Skylight posts and their working together in this shared network.
And then you have Spark, which I believe is still in a closed beta, but exact same target, as a skylight to build out a short form video, social media experience using the AT protocol. And all of these are examples of the competition, that part of it or operation, which leads us to people making better software, creating more choices for everybody. This is a meme that one of our team members made when we started to realize that our metrics were getting skewed because some of the other applications were started to pick up. And, the joke, I don't use Bluesky, I use Skylight. That's a DAU, we count those. The reason I bring this up is to say that one of the goals that we have with this is a sense of a rising tide lifts all boats.
And as these different applications are joining together using a shared network, we all benefit from each other. That network effect is very real, especially as they use the same kinds of content. It doesn't matter which application you're using. We're all connecting together. We're all experiencing a lift by each other's collective effort.
This is a quote that our CEO Jay brings up often, and it's a reason why we care about this. At the end of the day, societies mirror or grow to mirror their dominant form of communication. So if social media is going to be so deeply embedded in society and start to drive our politics and drive the world, I think it's very important, that the way that it's structured, matches the way that we want our real world to be structured.
So thank you very much. That's my talk. [Bey] Sorry, Paul.
Just trying to get my camera to work here. No problem. [Paul] I think you were asking for me to say I am ready for questions. [Bey] There we are.
Well, I would like to start with Andrew. He says I love Bluesky. And thanks for the talk. What role could public media, libraries or municipalities play in supporting interoperability; PDS hosting as a modern post office? [Paul] I love that idea. I couldn't, you know, I can only speculate about something like this. But we certainly want to, the general thinking is that making sure that it's possible for the infrastructure to be run by entities like the post office or to be, for there to be regional hosts, is way in line with what we're looking for.
In general, an ideal world would be that PDS hosting is kind of commodity infrastructure, and that there's a lot of, a lot of secure choice available to people so that that just is not a, a lock in concert, because that really is the foundational basis of ensuring that this system works the way that it should. So, yeah, I love that idea. And if, if there's any interest in that, I'm sure we'd love to chat with them. [Bey] Next question is from Brendan. Can you please speak to the democratization or decentralization of Bluesky? In what ways is it still not decentralized? And is there an approach or roadmap to democratizing and opening them? [Paul] Yeah, it's a pretty hot topic right now. There is a, so to make sure that everybody appreciates the context of that question.
The protocol was, put in place and used from, roughly the time that we actually stopped being in a private beta. And it was kind of an important prerequisite for us to make sure that when we actually opened up to everybody that we hit that target. Yes. This is on an open technology.
We didn't want to stop our closed beta period prior to achieving that. However, the technology is still very new. There has been, on the application side of running things, a lot of clunky bits. And also some costs that were a little bit high. That aggregating process is called a relay.
We recently put a kind of new, relay 1.1, came out and that dramatically reduced the costs of, running one of those relays. And then the kind of the general effort of the Bluesky team has been focused on making sure that we can scale the instance that we provide to the world so that, you know, people could join into this thing and capture the moment that's been made available to us.
So when we're focusing on scaling our instance, we're not focusing on making an easy to run package for people to independently take advantage of it, which is put us in a position where it is possible to run the full stack, independently, but not easy. And so that has led to some questions about, okay, well, how close are we to what people might call operational decentralization or like in practice and that's why I was excited about what I called out before that. We're starting to see the fully independent stacks running, because the community has really begun to embrace this question of embrace this challenge and start to press for, what we generally call the indie sky. And that is an effort that we're pretty excited about and are doing our best to encourage and support to some degree we can always support it. You know, we can't do it ourselves by nature. Right?
So, it's incredibly exciting that the community has been embracing that to the degree that they have. And we're going to continue to try to, help that along in the ways that we can. I do think it's also worthwhile to call out that another way that we look at this is through those co-operative models that I mentioned before, the feeds, the moderation. We want to continue to press in that direction as well, because you have the kind of term running your own application.
And that's great. And it's very valuable and important that that can be done. Can you also decentralize the operation and the day to day without having to change applications? And that's where the idea of the feeds and the independent moderation and how those communities are beginning to form and operate independently, why that's so valuable. Because that is a much more accessible form of delegation out to the edges and decentralization.
So those are the really the two ways that we are pushing for that to happen. [Bey] Bailey writes, I may be misunderstanding the implementation of account portability, but according to the account migration document, it looks like migrating requires a signed PLC operation from the old PDS. And what is stopping a PDS from refusing this operation, thus locking you in? [Paul] Okay, we're going to get really technical here, so I apologize if I lose some folks. That is a good call out and was something that we were concerned about as well.
Let's see. So everybody has, what's called a DID document and it's like a certificate. It tells people where your current host is, and it tells people what your signing keys are, which are used to, create all the data that you publish. So everybody's data is actually signed using cryptography. And you need to use tsome of those keys to make changes to your certificate. So if you want to change a host, you have to issue a new version of your certificate.
You you do that with the keys, and the keys are actually held on your PDS. So the question is being raised is what if your PDS says, no, I will not let you migrate away? To solve that, we introduced what we call well, what's the term we're using now? I believe we call these rotation keys. Essentially, you can create a separate set of more powerful keys that are more powerful than the one that your PDS holds. And you're supposed to, this is still kind of working its way into the toolkit. So that is kind of straightforward for people to do. In fact, one of our community members has been making some cool progress on this.
But the idea is that this is a paper key. This is something that you, as an end user would create. You'd write down somewhere, and this enables you to override the decisions of your PDS. And so in an adversarial scenario like you're describing, you could make the migration away even if your host is unwilling to facilitate it.
It's also designed to help deal with the possibility that your host just decides to shudder to go down. And maybe they don't stay on line long enough for you to execute the migration. So, yes, for that to be effective, we do need to begin to encourage people to create their paper keys and store them away somewhere safe so that they can override it. But, that that is ultimately the solution that we came up with for the adversarial migration scenario. [Bey] Eileen asks questions regarding that which is centralized: What data resources does Bluesky control? Following on the previous question.
And what plans, if any do you have to open that data up systematically and or making it available to researchers? [Paul] Okay. So, I'll step through the particular items. I want to start by saying that these are the exceptions. Most of the interactions in Bluesky and in the atmosphere are public and available.
So the items that I'm going to be enumerated here are the kind of the things that are, not in that way. First one. And the obvious one is, DMs, direct messages. We ended up having time pressure.
Time did not play on our side. In fact, everything about the Bluesky project has moved so much faster, that we were hoping for, I would have loved the leisurely ten years to be working on this protocol before we had went to production. So, the protocol does not yet have good facilities for, doing DMs. And so our solution was, well, okay, we're just going to have to throw one together. Just that runs out our server and then plan to move that onto the protocol. Once the protocol has the technology.
So DMs is one item. The next item would be, our analytics, that is information which we capture and are not sharing publicly for some pretty obvious reasons. I think there's an interesting conversation to be had about, where that should go. But at the moment I would say that I'm more concerned about the privacy aspect of that. And so that's staying in our hands.
Finally, we have the PLC. I mentioned before that DID document that certificate, that works off of a registry that we operate. It's not, a decentralized system. It is open. But it is not decentralized.
And our goals for that and this is actively in motion, is moving it into an independent, organization, an independent legal entity, which can have members, and, be operated independently of the company. We sort of modeled that after DNS and its governance with ICAN is what we're aiming for with that. [Bey] This question is from oh, I'm looking for a Catherine F. As Bluesky explores monetization and growth, how are you thinking about measuring success in ways that don't just mirror the engagement maximization models of other leading platforms? Are the metrics you're exploring that better reflect the community health or long term trust? [Paul] We'd love to have a metric of trust.
Some things are hard to quantify, because we certainly care quite a bit about that. But. Yeah, it's an interesting question. And one of the things that is somewhat inescapable is, we have to, on some level, still think about this as a product in the marketplace. But we think about it more collectively that the entire at what we call the atmosphere, the AT protocol network is, is the goal, the thing that we want to grow, not just our application.
And so we are trying to build a world with interoperative social media. We have to have a theory of change. We have to get this technology into people's hands so that it is their daily driver. That means competing in the market and becoming popular, becoming a dominant product. And with that, you pay attention to number of accounts and you pay attention to DAU.
The decisions about how we try to spur that growth and make this, something that is healthier for folks. It's challenging. It comes a lot of that tend to it tends to trend towards algorithm design. And a lot of folks in our user base quite prefer just a good old fashioned following feed because it kind of takes the the question out about whether or not the algorithm is driving something toxic or not.
But I wish I had a great answer for a metric that could drive us to somewhere healthier. At the end of the day, you want to get users. It's part of this, part of the project. [Bey] Thank you.
Combining a couple questions here from Nick and Jordan, how are you approaching safety and content moderation? [Paul] Yeah. [Bey] And how this was you - sorry. And how have you approached security and privacy on Bluesky, where the openness is such a core philosophy? [Paul] Yeah.
So I'll work back. Well, no I won't work backwards. So, security and privacy can also, that can touch on moderation in terms of making a kind of a healthy and, safe experience that it could touch on security, privacy questions. And so sounds a little bit like this is trending towards the privacy and security question, more than the kind of, is this a moderated space, but I'll answer both. In terms of having a moderated space we wanted to make sure that there were good facilities for that from the get o.
And as an operator of an application, your job is to moderate the application. And so that's what we've done. We've spun up a TNS division. We have moderators, and we do our best to make sure that it is a good experience for everybody.
Regarding the safety aspect of this, yes. It's public. The content is public. And we've been pretty persistent about communicating that, we don't want that to be a surprise to folks.
We don't. That's a the worst thing is actually an intent violation. And worst thing you could do is give people a sense that, oh, no, it's this is just between me and my friend.
And oh no, that was public. So we're very, very persistent in the education side of this thing. Eventually the protocol is going to develop private sharing flows.
And that will begin to, modify, you know, how that works, and add some better privacy options. We're also quite interested in end to end encryption, and there's some really great work happening in these standards world around, a standard called MLS for end to end encryption, that we're paying quite a bit of attention to. But there is a bit of tension between perhaps not everybody really wants to have all of their posts being seen or pulled together, but we need to make sure that, interoperation is guaranteed.
And that is our goal. And, by nature, when I say force interoperation and non-cooperative interoperation, that means that this is public and that Bluesky is not choosing who gets to have these posts that is designed to fight against the monopoly impulses that start to show up. Once we start to gate that access.
So, that's the trade and that's the trade that we've chosen. And, hopefully that's the right call. But that's, that's what we're about. [Bey] Next question.
What is your view on the increasing number of decentralized clients and networks? Won't it become confusing which client or network to use, or even ignorant of others? [Paul] Yeah, of course it will. Right? Whatever you have the, you know, I just listening to, Mike McCue, the founder of Flipboard talking to Mike Masnick about this in their podcast recently. And they talked about when the internet came along, and all that kind of, and the web came along and comparing it to AOL and how it was not as nice of a UX, right? AOL had just like a button. This is the example they gave; AOL You just like, you know, type it in flight. There's a button to book a flight. It's a really nice experience.
When you get to the web, you have to sit and you know, the the URLs. It's not as easy, right? And you have a bunch of different options. And it's a big, messy market that will confuse people.
That's just part of how it goes. But then eventually it'll settle down. Eventually people will find things that they like and they'll tell people about what they like, and things will kind of round out into, a stable state. But I would say yes. But, and everybody's going to do their best to try to make it clear as we go and make it as good as it could be as it happens. But some agree we got to embrace the mess.
So yeah. [Bey] Nick asks, would interoperability inadvertently create more echo chambers? [Paul] Oh, maybe. I mean, would interoperation necessarily provoke it? I don't really love the discourse around echo chambers, to be honest. I kind of, I think maybe I'd be a little bit more concerned with, a... I might be concerned about echo chambers, if it truly is pervasive in a way that you're not even aware that there is an outside world.
So, sure, there's a little bit of concern about it, but it also kind of tends to lead to decisions that I think are frustrating to people, where you're kind of making calls on their behalf, you know, making judgment calls saying, oh, no, you're in an echo chamber. You need to be exposed to opposing views. So we're going to step in here and start to expose you to stuff that drives you crazy. I just don't really love the discourse around that. So I don't know, maybe interoperation does, maybe it doesn't.
I don't actually have a hot take on that, but I'm just not that keyed up about the topic. I kind of think you should let people associate with the people they want to. [Bey] While it's very exciting and overwhelming to see all those standards appearing; lens, activity hub, interoperability needs a shared standard. What is your prediction for the evolution of the standard ecosystem? Are we waiting for one leader to establish itself? Probably, yeah. I mean, the dominance of a given standard is downstream of the adoption of applications. In most of the standards, bodies will end up becoming, most likely, driven by the, industry members that have successful applications and the different standards.
So, you know, look, there's a lot of healthy competition at the protocol level right now, and there's a lot of great work being done by all the different groups. I think it's possible some of them will coexist. It's hard to, you know, I don't have a crystal ball on this. But, it's certainly possible that, one of them will end up really taking the lead.
And that'll end up answering that question, on how that goes. [Bey] Thank you. Leo asks, and this follows on Catherine's question. If you are competing with existing social media models, does this not mean that you will be encouraged to implement addictive design both in its UI and algorithms, meaning that over time, Bluesky will slowly become the sites that it's aiming to replace? Is attempting to measure time well spent not crucial to true success? I think that's a credible question. And none of the work that we've done, all of the technology that we've created, necessarily answers that by nature. Right? I didn't have, in my wordcloud, guaranteed nontoxic application design.
What, again, though, what we do focus on is choice and the ability to move past what we do. So that if we do go down that path, that there can be an opportunity for other people, with a better sense of how this should work to step in and and beat us out. But I can't, you know, I don't want to stand here and make claims that I can't support.
And it's a very valid concern. [Bey] Sorry about the delay. We're just pulling up the question. [Paul] No problem.
[Bey] I understand Bluesky is registered as a social enterprise or public benefit corporation in the US. What is the business model as far as revenue goes? Would it be ad, AI training, licensing, etc.? [Paul] Yeah. I can. We are, I want to say close to ready to share what we are, going to do. And I don't want to run ahead of the org and talk out of turn.
But I can tell you about where we're leaning and why. In particular, our largest concern is ensuring that we're creating a good incentive model, for ourselves, as well as for the entire ecosystem. And we want to make a world where everybody is able to earn money in this scenario and not just us. If we're trying to hydrate an open ecosystem, that open ecosystem needs to be able to sustain itself and make good money. And, consequently, things like the advertising model is not really appealing to us at this stage because the advertising model pushes us towards maximizing time spent in our application. Instead of clicking on links or going to other applications, that's the wrong incentive model for us, as we were trying to build out a world where there are, there's choice, right, where we're embracing, the work being done by other people.
So we're not keen on ads. I wouldn't say it's never going to happen. But in general, one of our, one of the things I would say is that over enough time, it's pretty tough to imagine any business staying away from an opportunity to make money. Which again, goes back to my choice,topic and why we care about setting interoperation as a forced matter from the get go. But, that does trend us towards, something more in the, payments space and, or, you know, subscriptions or, you know, something like that, people paying for more things.
And that's where we're much more interested, than something like advertising. [Bey] Denny asks, or says, I am guessing the clients for Bluesky mobile or web apps need to take a call on which labels to surface in their UI and which labels to support. Is there a recommended way for client app makers to collaborate and coordinate, or is the vision to allow hundreds of client apps to proliferate? [Paul] Yeah. That is frankly true of like kind of everything in this space. When you have an open network your parameters become not the network itself, but compatibility.
And getting on the same page with the other applications is very important. You don't want to do something that surprises somebody on another application or breaks, again, you don't want to break intent. And we put a fair amount of work into structuring how data works in this world. You may recall seeing what I showed in my posts, there's a typo on the poster.
No. Schemas are very well defined, Ww call that lexicon where the language that they speak. Moderation labels are still a little bit less developed, by comparison. They presently use a, a pretty well specified set of effects. But they are limited.
It's things like this is supposed to blur content whenever it's enabled. This is supposed to entirely hide content when it's enabled or this is only supposed to be an informational badge. I expect that in the future that is going to elaborate more so that more varied behaviors can be introduced into the world. But we tend to not try to design ahead of building, ahead of a particular use case.
This is a learned behavior for us. We all come from the decentralization world, all the core team at Bluesky, we all built a bunch of protocols and then built applications and then realized that is a bad way to do things that you should design with a practical use case in mind. So we with labels are just kind of we've taken it as far as we know, what is necessary. And then we've just been kind of waiting to see what the needs are, what the requirements are, and how they evolve before we start to try to structure that more. So I do think it'll probably evolve in some interesting places once we start to understand that use case better. [Bey] Thank you.
From Eli, the AT protocol can be difficult to explain to end users. Many of them have never encountered the concept that all of their data lives somewhere other than the app they're using. People see log in with Bluesky and assume it's the same kind of thing as log in with Google. Even though something different and more profound is happening behind the scenes. How do you approach explaining atproto's architecture to an indifferent audience? [Paul] Yeah, I'll tell you, I wish I had a wonderful answer for you.
The explanation that I gave here in my talk is kind of trending towards one of the ways that I do it, I analogize. Right, I kind of depending on how deep I'm trying to go. I usually start by saying, well, it's a social network where it's not all just run by one company. More, you know, lots of companies can can build applications and kind of cooperatively on it. That's like my V0 my, my initial kind of way of explaining it to folks.
If I'm trying to get a little bit more specific, I'll probably bring up the, I might bring up the files metaphor, you know, and say like, yeah, you got your files hosted here. And that's like separate from the application. But it takes time. And to some degree, I think you always have to meet people where they're at and figure out how much you want to try to educate them at any given moment.
So, doing it incrementally is is a good idea. And we've done our best to try to kind of pick what we think people understand and explain that bit and then move on to the next piece that we try to get people to understand and then explain that a bit. And it does happen, it is worth having some amount of faith in that, over time. But the login question still is that's, that's kind of our biggest question that everybody's asking right now is we just recently introduced a sign in flow for the protocol, using OAuth.
And everybody is asking, how do we explain that to people? Do we say sign in with Bluesky? Do we say sign in with atproto? Do we come up with, as I mentioned before, we informally call the network the atmosphere. So do we say log in with the atmosphere? Well, the market doesn't know what the atmosphere is yet. Right. There's been no work into the getting to to brand that premise. So we're in a little bit of a pickle.
I don't know exactly where that's going to land. But I agree that it's a problem. And, it's kind of one of the most active conversations right now. So, it's, if I had to guess, it's probably because of where we're at.
If nobody comes up with something smart for the near term, we'll probably say sign in with Bluesky, and then try to push any kind of branding effort, that would start to have, you know, once that has made its way out there, we can start to transfer it out. But the paint doesn't dry permanently. You know, you can always stage things on this.
And that would be probably what I hope happens here. [Bey] Well, we're going to squeeze in one final question. Current decentralized stacks are often the architecturally distributed yet ontologically centralized.
They still trace one ledger, one history, one metric just enforced by math instead of monarch c-suite. Escaping the isomorphism means designing for many partial truths that can interoperate without collapsing into a single throne. That requires, contextual proofs, rotating authority plural dashboards, and not merely copying the cathedral into a data center. There are a lot of Bluesky architecture addressing the sociotechnical razor's edge. What kind of innovations do you think are needed to push this conversation further? [Paul] It's messed up that I was able to follow that [laughs]. That's a real...
[Bey] It's messed up that I was able to read it. [Paul] [Laughs] I actually have some guesses about who shared that. Do we have a name for who that was? [Bey] Johnathan Zong. [Paul] Oh, okay. No. Well, whoever that is, Jonathan, I apologize if we've met before, but they're clearly deeply embedded in the conversation. Okay.
Okay. Let me let me real quick try to summarize what Jonathan was getting at. So, it basically this has to do with, are we all kind of collaborating on making one thing, or is it everybody kind of working in different pockets of things that they're building together? And particularly when it comes to actual information. So Wikipedia is an example of everybody collaborating to make one thing, the Wikipedia article for we'll go with Bluesky. There's just one, right. There's a global article for Bluesky, at least in the English Wikipedia.
And we're all working together to make that one thing and decide on what that one thing is. And, they brought up blockchains as an example of that same story. Actually, blockchains is a one giant ledger of everybody's balances that we're all working together to, to agree upon. Now, another, counterexample to the Wikipedia model is actually how the web works, where everybody has their own website and they're publishing to their own website.
And so they don't actually have to come to agreement with each other about what's being published, and everybody's doing it themselves. The AT protocol is much more of the latter. The AT protocol is not designed to come to agreement about one shared resource. It's actually everybody. Everybody is, representing themselves as their, as an account, and speaking independently. And then consequently, the application that assembles all those conversations into a feed and into the threads and things like that has a lot of discretion over the selection of that content and what shows up there, which is why the application matters.
There are two separate systems. The application generally, I mean, you know, if it ever gets caught lying about what people are saying, well, then you definitely want to get away from that application. But, if you assume honestly, you still then have ranking decisions being made, moderation decisions being made, algorithm decisions being made. And, so it is a, in effect, a kind of a collaboration between the end users and the applications. But that creates flexibility. You're supposed to the goal is to have an open market of these applications. And,
then that means choice about how that is done, including the choice to be able to run it on your own and like, have your own application. Now, that's pretty technical. But in theory, that's that's what we're aiming for. So, I think Jonathan's prompt was, you know, how do we avoid, the sort of, one thing that everybody works on and I would say personally that that is kind of baked in to what we're doing, but I'm sure Jonathan and I can go a couple of rounds and have an interesting conversation. Well, thank you so much for joining us today. I hope everyone at home found this a useful and informative hour, and you will join us again next week for our next session. Have a great day.
Thanks everybody.
2025-05-16 04:38
