I agree that this is not an apocalyptic moment for the protocol. And I support what Blacksky is doing, so I kind of hate that this will probably be the only thing I get to say to you.
But the argument that established, profitable organizations in the atproto space have no qualms with this move is not as reassuring as you might think.
I would not be surprised based on the post that the trademark will be given to some sort of non-profit foundation. The post itself made it seem pretty clear that the current reasons to have the PBC acquire it were:
1. An adversary attempting to do so in order to extract money (rent seeking).
2. There was less legal and financial overhead in doing so via the PBC.
While not everything BlueSky has done has been stellar, and there have been missteps, I think they’ve generally been exceptional stewards of atproto and the ecosystem. As a result, I’m willing to give them the benefit of the doubt they will stand by their word.
FWIW— shithead trolls doing things like acquiring copyrights to extract “rents” are exactly why every org I’ve ever worked for pays lawyers for bullshit copyright and patent applications. It’s not because they’re valid, it’s because it’s cheaper to do so upfront, than fight to disprove someone else own’s them later.
Then they start calling it "buproto" or something. Firefox has a trademark too, but that didn't stop debian from distributing the same thing under the name Iceweasel...
> We’ve taken inspiration from other open-source projects that have taken a similar approach, including Wikimedia, Red Hat, Rust, Python Foundation, Apache, Mozilla, Linux, and Debian.
> Bluesky recently acquired the rights to the trademark for “ATPROTOCOL” and its variants—including “AT Protocol” and “atproto”—from another company that was threatening to take legal action preventing the company and others from using the term. Now that Bluesky owns it, the atproto community’s continued use of the mark can be protected.
The policy around usage is shared in the rest of the post but the goal is to make this very simple for everyone
I don't remember ever hearing that called AT proto or AT protocol, just AT commands or AT commandset etc.
Even though I'm that old, even I don't care even if it was anyway.
...as long as the reason is what it looks like. Rather have Bluesky claim it for the purpose of having the officially recognized legal authority to grant usage to everyone else, than have a rando douche company think they can claim it to extort or simply inhibit everyone else.
Is this a real thing? I don't think I've ever heard "AT protocol" before Bluesky. My first modem was 300 baud, so I wasn't totally out of the loop on this. DDG finds four hits for the phrase before 2020 used to describe the Hayes command set.
Depending on how you search specifically, you may or may not get all of them. For example, if you searched for "at protocol" specifically, you wouldn't get comments that are like "I thought we were talking about the old modem protocol!" and similar.
Anyway I don't think that it means that atproto was misnamed or anything, just that this thread isn't the only time people have brought this up.
>We plan to transfer that ownership to an appropriate, independent protocol governance organization in the future.
I never realized there is no independent governance org that should have registered this. So AT is governed by a single for-profit entity, that also runs the only viable instance?
It segments the network differently (into "hosting" and "apps"), and on both axes anyone can run their independent app-agnostic hosting, as well as an independent hosting-agnostic app.
Thanks, this is informative. I had meant 'instance' from more of a general user adoption perspective (i.e. Bluesky app user plus Bluesky PDS tenant), but based on other comments here that may not be too accurate either.
I don't mean it as a linguistic gotcha ("ha, you said instances! but we call them something else"). I'm saying this is a category error because the network topology is different. This is like saying that web is not free because people aren't running Google-scale indexes in their garages.
Dan, you really should refine this line of reasoning a bit as it feels not very nice in some way: it feels like you're picking an unintuitive/uncommon definition for "instance" and then using that to tell everyone they're misunderstanding stuff then they're using different, arguably more widely accepted, definitions.
We've had a very similar discussion in response to this same argument recently elsewhere on HN. If you enjoy having this debate, then carry on, but I don't think it endears non ATProto users to the ATProto cause. I think it seems needlessly controversial/pedantic. Sorry for the blunt feedback, it's because I expect better from you:)
The parent post says "the only viable instance" which implicitly packs an assumption of Mastodon-like topology: a single product is expected to be split into many "instances", with some of them being more or less "viable", and that a lack of many "viable" "instances" is perceived as the protocol not being a real thing, or failing to live up to its promise. (How else are you reading "viable instance"?)
I believe that if you look at the network topology, this argument becomes much closer to "Google Reader being the only viable instance of Google Reader means RSS is a scam with a single player". Which is an absurd thing to say. That is what I'm trying to show by picking at the word "instance".
Do you find my argument flawed, or just the way I present it? How do you prefer I present it alternatively? And how do you read the parent post? My issue isn't with the word, but with the implication in the parent post.
I think you're inferring something that people aren't implying, and that inference leads to you eventually discussing how ATProto is better than mastodon. I think this doesn't look great, particularly at a time where there's quite a few posts of about unproductive conflict between open social network contributors. I don't think there's any bad intent or malice on your side: there is value in comparison between AT/AP to help understanding.
Your argument that there are no instances in ATProto isn't flawed if you redefine instances as this thing that ATProto doesn't have. But if I run it by the various computer science definitions I can find (e.g. https://en.wikipedia.org/wiki/Instance_(computer_science)) then your argument seems like it depends on a niche interpretation. So it can be technically correct, but just irrelevant or inconvenient when used in a comp sci discussion involving the word "instance".
But your blog post on the subject is interesting, and informative, and has some great diagrams, and the original parent poster agreed and learned stuff from it. Despite that, I think the implication in the parent post was, IMO, "so the main, largest implementer (instance) of the protocol is also a for-profit which owns the trademarks? I never realised that, I'd assume the protocol was governed and run by a not-for-profit independent governance org, charity or consortium" (like some other open protocols).
I think that's a fair and slightly critical implication that has nothing to do with network topology. I completely get how you would want to take issue with that implication alone, because without context like the trademark was acquired with good intent to protect protect openness, and that the Bluesky org is a specific type of for-profit (PBC) that expresses intent to favour public benefit and openness, it makes things sound more sinister than they are.
Ultimately, from an openness and independence position, I think it would be better looking from the outside if the ATProto and trademarks were governed and managed by a separate not-for-profit entity that wasn't tied to the biggest instance/implementation of the protocol. I think that was the point being made, and I don't think it's absurd. But I think refuting that argument by focusing on network topology and instance definitions seems like a misunderstanding somewhere.
I don't think the Google comparison is doing you any favors in resolving the concern behind the category error, though. What I'm hearing is that AT is like the web if Google had started the web themselves and designed it around their index as the primary means of accessing anything on the web. Sure, they still have Don't Be Evil as their motto at this stage, and in the 90s maybe we would have been naive enough to believe them.
But in the 2020s, after watching what Google did to the web without being able to control the protocol from the beginning, a comparison of Bluesky to Google doesn't really assuage the concern people have about centralization.
>designed it around their index as the primary means of accessing anything on the web
That doesn't actually translate from the analogy though.
You don't use Bluesky to access other apps' data on atproto, you use those apps. You go to https://tangled.org/ for Tangled (atproto github), you go to https://leaflet.pub/ for Leaflet (one of atproto blogging platforms), and so on. Bluesky is not a "one stop shop" for all atproto stuff, it's just one of atproto apps, and anyone can make their own app.
The apps themselves have to compete on their own merit, completely unrelated to the protocol stuff. The protocol just makes them all interoperable and changes market dynamics (e.g. someone can resurrect a dead app by creating a new projection of existing data). If your criticism is that there aren't many apps on atproto yet — fair, but you can make those! People are making those. This is something you can actively contribute to, there's no permission you need to ask.
The "Bluesky index" is the index of Bluesky posts, so naturally you access that primarily through the Bluesky app. (Although even that isn't set in stone — see Blacksky who run their own stack for everything, but also show Bluesky posts.) And then, if you make your own app with your own data types, it would not be related to Bluesky in any way.
>But in the 2020s, after watching what Google did to the web without being able to control the protocol from the beginning, a comparison of Bluesky to Google doesn't really assuage the concern people have about centralization.
Sure, and is your argument that it's better if the web had never happened? Atproto is going to IETF so it will become a "proper" internet standard. The way you shift the balance of power is by building your own stuff on it.
It's great that you can make your own independent apps on atproto, and you're right that I overstated the "anything on the protocol" in the analogy. Analogies are always lossy, but that was worse than necessary.
But notice that what you're now arguing is not that Bluesky is equally decentralized to Mastodon as a social network, you are arguing that while Bluesky the app may be in practice highly centralized that doesn't mean other apps can't exist:
> The "Bluesky index" is the index of Bluesky posts, so naturally you access that primarily through the Bluesky app.
It probably is entirely true that different apps can spin up on atproto independently, but that was never the actual point of concern. This, what you say right here, is the actual concern. This specific app (or any atproto app) appears to have significant lock-in—to the point where you identify it as "natural" that it would be so—while selling itself on decentralization.
Blacksky is an interesting case, and I'm wondering why you didn't roll it out at the beginning and why you still hedge it as "natural" that you'd access the Bluesky app data through Bluesky? I'm actually unfamiliar with the territory here, but coming from my knowledge of the fediverse that seems an odd pairing. If a fully independent implementation exists, why is it natural that you'd use the central one?
>It probably is entirely true that different apps can spin up on atproto independently
It's true, and I want to emphasize that they need nothing to do with microblogging or Bluesky posts. I think it's important to internalize this because most discussions about Mastodon are about microblogging modality. But, say, Tangled is a git hosting with social layer (issues, PRs) on atproto. So we are really comparing fundamentally different ecosystems already. Atproto is not centered around Bluesky posts or Bluesky app; it's just that Bluesky app happens to be the biggest app built on top of atproto primitives.
>This, what do you say right here, is the actual concern. This specific app (or any atproto app) appears to have significant lock-in—to the point where you identify it as "natural" that it would be so—while selling itself on decentralization.
You're starting with the Mastodon perspective of "a social network is a set of fragmented views of the network with no shared sense of identity or global aggregation/search which talk to each other" and consider it natural.
Whereas I start with the regular user's understanding of a social app — it's a place where you can come, where you can see the entire world at once, where all features (global search, recommendations, follow graph) are global by default, and where you don't "belong" to any particular community to an extent that this community can cut you off from your followers or ban you. Instead, the app is serviced by app's developers and you're at their mercy.
Now, what does atproto try to do?
From the user's point of view, it looks as the familiar "centralized" approach — apps can have global search, recommendation algorithms, there's no fragmentation. Each app is a prism over the entire network and always shows a consistent view over it. App developers do have full control over how the app presents it. There aren't 100 copies of the same app because there are 100 communities on it. This split into instances is a "Mastodon-brained" way of thinking.
However, the underlying data lives in an app-agnostic layer. So Blacksky was able to kickstart their own projection of atproto network (filtered down to Bluesky stuff since their app is initially a clone of Bluesky). It's not an easy job to make it work for billions of posts, but no Mastodon instance even tries to support that scale. Atproto makes supporting that scale possible, and then we say "oh but this is expensive". Of course it is — it's expensive to store content from millions of people with any technology. But unlike centralized services (which atproto tries to match in baseline UX expectations), it is possible to spin up alternative projections of the same network that fully participate in it, when folks have concrete reasons to do so. (For example, Blacksky is able to take different moderation decisions as a result.)
You can go further. https://reddwarf.app/ is a working app displaying Bluesky data that does not have a backend at all and does not use Bluesky (or Blacksky) API servers. Instead, it loads data directly from the hosting layer, and uses https://constellation.microcosm.blue/ network index for querying relationships (like "give me a list of likes for this post"). This is less efficient than maintaining an index (so it loads a bit slower) but it's totally a workable model. The Constellation index itself, if I'm not mistaken, runs on someone's Raspberry Pi.
Of course, you can also "scale down" atproto to make it apples-to-apples with Mastodon. You'd add some code that filters down events only to those that are "relevant" to people who are "on" your "server" and their follows. This would be a "small world" atproto that would be easy for anyone to spin up. It's not very exciting but I guess we'll see more experiments in that area as people realize it is possible. But it's also just less exciting because you can also run the real thing if you're motivated enough. And the fact that anyone can choose to do it if there's a real need means people don't create a 1000 of shallow Bluesky clones. It just doesn't solve any actual problems other than trying to win arguments like this.
I don't think "decentralization" is a super useful prism to think about atproto. Atproto is a high scale syndication protocol, like typed signed RSS via HTTP and WebSockets with a shared data model and identity upstreamed into the web. This protocol enables independent apps, independent hosting providers, and independent caches and relays to build and participate in a shared ecosystem. That ecosystem lives on the web, so it's "decentralized" in the same sense that web itself is. But it doesn't mean that each product must be split into a thousand pieces at the UX level.
> and designed it around their index as the primary means of accessing anything on the web
Except that you don't have to use an ATproto relay (the “index” equivalent here) to access anything on ATproto; there's nothing stopping you from grabbing records directly from anyone's PDS. You'd just need some way to know which PDS to consult; that's normally the relay's job, but it doesn't have to be (nor does the relay necessarily need to snarf every record from every PDS if you know you only care about a subset of that info).
I haven't worked at Bluesky for over a year now. I'm genuinely excited about the protocol, and have written a bunch of things about it while I had free time between jobs. (Ironically I had no time to write about it while at Bluesky because I was too busy working around React Native bugs.)
>it's impossible to actually participate in Bluesky using an alternative relay
Here's an example of connecting to one of them: https://pdsls.dev/firehose?instance=wss%3A%2F%2Feurope.fireh.... From an app's perspective, they're completely interchangeable, so as an app developer you can switch to any relay you want, or run your own.
Does the IETF register trademarks on behalf of their working groups? It’s possible that I’m just misinformed about that.
I left this comment shortly before bed and my thought process was “a working group isn’t a legal entity and therefore can’t do this” but it’s entirely possible that that was shortsighted of me.
ATProto is closer to how RSS works than ActivityPub. In the same way talking about "RSS instances" makes little sense, the same goes for "ATProto instances".
It makes sense to talk about “RSS aggregators”. Especially it makes sense to talk about “RSS aggregators that speak a specific vocabulary on top of RSS, host 99% of content using that vocabulary, and if you host your own RSS feed with said vocabulary they’ll show it in their aggregator but can ban it any minute”.
Did I just describe Apple Podcasts? Huh. Regardless, yeah, there’s no “ATProto instances” technically, but there are ATProto apps and the single biggest one now owns the trademark to the protocol name.
i guess that's fair, but i've never listened to a podcast from a non-foss app; i'm not really "in" the podcast sphere, but from where i'm sitting it seems podcasting would survive and migrate just fine if apple podcasts had to go away suddenly
I guess that’s fair, too. I’m not really into podcasts either, and the ecosystem seems healthy enough. Many FOSS podcast clients use Apple for discovery, which I guess make sense; but there’s probably other databases, and the contents themselves aren’t usually hosted by Apple, just the metadata.
So yeah, podcasts are in good shape. In fact, they are probably the most used decentralized media right now (apart from torrents, maybe). I hope Bluesky gets to that point, and I do wish them luck, but we’ve got to see the incentives are not that well aligned. As for the trademark... it’s surely weird, it’s not the end of the world if they continue to hold it, but setting up a non-profit (not in US, perhaps) for the protocol itself would probably be more appropriate down the road.
The thing with ATProto is, there is little incentive in creating apps that speak the app.bsky vocabulary. If I understand correctly, there is one other full-fledged app that does that, Blacksky [0]. By full-fledged, I mean they host a PDS, a relay, an app view, a moderation service, and a bunch of feeds and other doodads. If Bluesky goes down, Blacksky will probably be fine. They are, however, yet another US company [1], which is not ideal.
"Only viable instance" is not really the correct framing - Bluesky doesn't have instances. Anyone using ATProto without Bluesky will still be "on Bluesky".
When you go to bsky.app, you're interacting with the Bluesky AppView; one key feature of ATProto is that any AppView can interact with any (consenting) Personal Data Server (PDS). So you can self-host your PDS but still use bsky.app if you so choose. But critically, anyone can write an AppView; there are reimplementations of Bluesky as well as other social apps that use the same ATProto infrastructure. That would be closest thing to a Mastodon instance, except you don't have to host your data on it in order to use it. Imagine being able to go to a Lemmy instance and just post things with your Mastodon identity, and have everything show up without Mastodon having to know anything about Lemmy magazines or its special upvote / comment formats.
The actual centralization in ATProto lies in a combination of unfortunate design decisions and genuine friction in the self-hosted path. Being totally reliant on Bluesky is the happy path, self-hosting your PDS data is difficult but doable, and being totally independent of Bluesky is only possible if you do everything correctly right at the start.
First off, Bluesky doesn't offer any GUI tools for PDS migration. If you want to get off their PDS, you'll need to bust out command-line tools and possibly do some steps in advance of when you need to migrate in order for everything to work properly.
Second, even if you're on a PDS, you're still reliant on the Public Ledger of Credentials (PLC) to host your Distributed ID (DID) document. The PLC is run by Bluesky, although they've taken steps to make it easy to notice if they were to do something fucky with the PLC. But let's say we don't like that. There is a solution: you can host your DID document on a normal web server. Problem solved?
Well, if you were setting up an account for the first time, then yes, the problem is actually solved, you're 100% independent of Bluesky. But if you made the mistake of registering an account normally, you have a did:plc identity. And one core principle of ATProto is that identity names never ever ever change. So if you go and make a did:web identity, it's like having a second account, there is no way to tie your old did:plc identity into it. In fact, I'm pretty sure you can't even redirect one did:web identity to another (say if you need to switch domain names)
Regarding Bluesky's "independent protocol governance organization", they made the same promise about the PLC; but it hasn't actually been transferred yet. I would be a lot more bullish on ATProto if there was a way to migrate DIDs and retain all your followers and shit. And if there was proper graphical tools for data migration.
The PLC governance not having been moved yet is my one main gripe against ATProto/Atmosphere now. There is so much being built on top of this protocol, and I truly believe it has the chance to make the social web more decentralized while keeping everything connected. The PLC being controlled by one major commercial entity allows them to pull the plug so to speak. Say someone is sanctioned by the US, what stops Bluesky from pulling the plug on their DID thereby blocking and censoring this person from the network all together.
Half the point of ATProto is that identities are used across a host of apps, and therein lies a big vulnerability. If identities are not truly independent of centralized infrastructure, then you are vulnerable to losing access to a number of apps at once similar to Google services black hole if your Google account is banned (not to mentioned anywhere you've logged in with SSO).
It would be much better if the PLC was somehow decentralized itself. Barring that it should at least be finally spun out as the independent Swiss organization they've talked about for some time now. The organization could form a board with interested parties to set the future of PLC development if needed.
As for PDS migration, there are good options if you are migrating away from Bluesky. There are lots of GUI tools that work well now like https://pdsmoover.com/moover, Eurosky has https://move.eurosky.tech/, etc. It would be cool though if Bluesky actually linked to the other big PDS-providers on the Bluesky sign-up page to actually promote decentralization. But I guess it is hard to vouch for other services.
I still think the future of ATProto is bright, but there are definitely some obstacles before I'm comfortable with the whole setup. The network needs more decentralization in the PDS-layer, and the PLC needs to spin out in the separate governance organization pronto.
Did they actually create the org yet? I saw the news you are linking that they were going to start the process. But I've seen no follow up news about the organization actually being here and the ownership of the PLC directory having been transferred.
> Say someone is sanctioned by the US, what stops Bluesky from pulling the plug on their DID thereby blocking and censoring this person from the network all together.
How does IANA handle this with domain names? genuine question, i'm not sure. is it enough to have distinct registrars and distinct jurisdictions for some TLDs and so on?
They don't. All domains have US jurisdiction except the ones that are underneath country TLDs.
IANA could stop publishing country TLDs in their root zone file but it would probably split the internet in two, and everyone involved knows that. Several root server operators would refuse the update, and many recursive resolver operators would put them back in.
>First off, Bluesky doesn't offer any GUI tools for PDS migration. If you want to get off their PDS, you'll need to bust out command-line tools and possibly do some steps in advance of when you need to migrate in order for everything to work properly.
This is getting much better recently. I migrated to https://eurosky.tech/accounts/ with no command line — just needed to wait for a wizard in my browser to move my records. It could've been much faster and seamless (the app was confused after this and I had to re-login), but it's definitely accessible to non-technical people, and the share of independent hosting is growing.
Bluesky has a data store, handles account authorization, and runs a web app that provides a UI to access the backend services. That's an instance, whether they call it one or not. Refusal to admit this is obfuscation for reasons I cannot understand.
The reason is that "why aren't many people running Bluesky instances" is a loaded question — it presupposes that's something you should expect. But it's like asking "why aren't many people running Google". It's expensive to store billions of posts!
This is usually compared to Mastodon, but it's not apples to apples since "running a Mastodon instance" always mean a tiny partial view of the network. You can do a partial view of atproto too for the same cost, it's just not very interesting because what's the point? Every app can "see" the entire network (unlike in ActivityPub) so there's a lot less motivation to create these fragmented views into it.
> I would be a lot more bullish on ATProto if there was a way to migrate DIDs and retain all your followers and shit. And if there was proper graphical tools for data migration.
This is exactly where I’ve landed re: ATProto. If you actually want to self-host everything you lose one of the biggest draws of it, the migratable IDs.
I was looking into it to build an alternative to Threads/IG/TikTok for one of my hobby communities that’s become almost entirely reliant on Meta/Tencent. Being able to plug into the wider AT Proto world was a big draw, but not being able to self host a true alternative to did:plc has put a halt to that for now while I figure out what I want to do.
I didn’t fully understand the part of the stack you’re talking about, but it always seemed like one of ATProto’s design goals was to really keep everything on the same distributed system (so to speak) while allowing people to host the bits individually that all contribute to the same connected system. Eg not having fully separate networks that don’t talk to each other
I don't know what you mean by this. You absolutely can self-host all your data on your own. And if you also don't want to rely on PLC for identity, you make a `did:web` identity, and then you're completely decoupled from Bluesky-operated infra.
Dan my concern is explicitly that did:web is not the same experience for users as a did:plc.
If I host AT Proto infra for my community and want to give people <usename>.<domain> accounts, I can either host a did:web for them which ties their account permanently to that domain, or they have to register with the centralized PLC to actually have all the benefits of a migratable DID. did:web does not provide the same UX as did:plc
From the post I was responding to:
> Second, even if you're on a PDS, you're still reliant on the Public Ledger of Credentials (PLC) to host your Distributed ID (DID) document. The PLC is run by Bluesky, although they've taken steps to make it easy to notice if they were to do something fucky with the PLC. But let's say we don't like that. There is a solution: you can host your DID document on a normal web server. Problem solved?
>
> Well, if you were setting up an account for the first time, then yes, the problem is actually solved, you're 100% independent of Bluesky. But if you made the mistake of registering an account normally, you have a did:plc identity. And one core principle of ATProto is that identity names never ever ever change. So if you go and make a did:web identity, it's like having a second account, there is no way to tie your old did:plc identity into it. In fact, I'm pretty sure you can't even redirect one did:web identity to another (say if you need to switch domain names)
I did read your post :) Yes, you can't migrate between PLC and WEB methods. It's not possible. I get that it's frustrating if you learn about it after making an account. Is that the whole concern?
I was replying to this:
>not being able to self host a true alternative to did:plc has put a halt to that for now while I figure out what I want to do.
I'm saying I don't know what this means. You can fully self-host with `did:web`. Yes, it's unfortunate that you've already made an account by the time you've realized that. I think that's still different from "not being able to self host".
Unless I'm just parsing what you wrote incorrectly, which is quite possible!
My understanding is that if I want to host AT Proto infra for my community and want to give people <usename>.<domain> account, I can either host a did:web for them which ties their account permanently to that domain, or they have to register with the centralized PLC to actually have all the benefits of a migratable DID, while tying themselves to a central authority. Ergo, did:web does not provide the same UX as did:plc and there’s currently no way (that I know of) to provide such UX to users without requiring them to register did:plc accounts
To clarify, do you mean you want their domain handles to look like this, or do you want to make them all have `did:web` identities? These are two different questions. Domain handles would work either way (with `did:plc` or `did:web`).
Indeed, the choice between `did:plc` and `did:web` is precisely "would I rather host tie identity JSON document to an entry in a centralized open source publicly verifiable registry that is moving to be maintained as neutrally as possible, or would I rather choose to tie my identity JSON document to a domain". And that choice has to be done at the account creation because every DID, by design, is immutable.
What options are lacking in that choice? It feels like it has an option for a pragmatist and an option for a purist.
>Ergo, did:web does not provide the same UX as did:plc
I mean, that is the difference between them. `did:web` means "I don't want to depend on anyone except domain authorities; I'm fine with losing identity if I lose the domain". Choosing `did:plc` means "I'm okay with depending on a central registry and find the threat model around it acceptable; I never worry about losing a domain". Both options are available.
The nightmare of the Wsocial rollout is a testament of the massive control Bluesky has on the ATProto network.
If Wsocial was on ActivityPub or Nostr nothing similar would have happened.
ATProto has serious centralisation problems, baked into the design. And it makes sense, considering it came out of a Twitter R&D experiment to "decentralise" Twitter itself. Pure federation was never part of the initial design.
I think decentralization is just not something users care about generally.
- many people wish they could control what they see and who they talk to. (Eg control the algorithm, avoid censorship from big tech)
- some people care about owning their data so it doesn’t go away when a company fails
- technical people are interested in building more types of social apps that aren’t just twitter posts etc
- nearly everyone just wants a fairly seamless experience without a lot of gotchas or technical problems to solve like self hosting an instance for your friends that falls over if too many people use it and is tricky to network with others.
Bluesky is trying to solve all those kinds of problems, which I think is pretty interesting, and I don’t think the others are quite doing the same thing technically. At the end of the day they are all pretty niche.
> - content not in line with the political left is censored
What do you mean? Individual apps can choose to censor I guess, but you can fairly trivially run an AppView with no filtering whatsoever if that's what you fancy.
> - sure, you have your data in your PDS, but it is de-facto useless if the central identity server of Bluesky goes down
That's not correct. You can use plc, which Bluesky operates the largest directory for, but you can also use web, which completely bypasses Bluesky all together.
> - ActivityPub and Nostr solve this already without being owned by a company
What's 'this' here?
> - you cannot easily and cheaply have an ATProto instance. AP and Nostr solve this already
The terminology here of 'ATProto instance' doesn't really make sense. If you're talking about a PDS, you can use one of thousands of free PDS hosts, or host your own for free on Cloudflare (https://cirrus.earth/) or on your own hardware (there are PDS implementations which fit comfortably onto a Raspberry Pi, or an old phone, etc.)
Sure you can host your PDS, but if you want to deploy your own instance like you would do with Mastodon, you need to deploy a Relay and an AppView as well. And the way the network works, you need beefy servers for that.
On ActivityPub and Nostr you develop all kind of applications already, it is not only Twitter clones, but also Instagram clones, Reddit clones, on Nostr there is even the resurrected Vine (https://about.divine.video/).
And it is not trivial to switch from the Bluesky did:plc (which you cannot run in write-mode on your own and need to use the official Bluesky owned) to did:web, which you can run on your own.
The idea of an 'instance' is not really clear. If you want to run a social network on ATProto, you do need the relay and app view, and those are indeed heavy requirements, but the architecture is not the same, and it depends what you're actually trying to achieve.
If you just want to use ATProto for your own small app, there are ways to do it on more constrained hardware. The more usage it gets, the more it scales up.
> On ActivityPub and Nostr you develop all kind of applications already, it is not only Twitter clones, but also Instagram clones, Reddit clones, on Nostr there is even the resurrected Vine (https://about.divine.video/).
Same! You can explore the (unfortunately named, given the point I'm trying to make :)) 'Bluesky directory' to see apps which use ATProto: https://blueskydirectory.com
Note that most of these have nothing to do with Bluesky.
> And it is not trivial to switch from the Bluesky did:plc (which you cannot run in write-mode on your own and need to use the official Bluesky owned) to did:web, which you can run on your own
That's true, but it's not trivial to run your own Mastodon instance either...
>If you want to run a social network on ATProto, you do need the relay and app view, and those are indeed heavy requirements, but the architecture is not the same, and it depends what you're actually trying to achieve.
Note those are not heavy requirements in any atproto-specific sense.
Running an atproto relay (at the current scale) is $30/month. If you're running a popular app, this is probably comparable with some of your SaaS subscriptions. Or you could use a community-run one or pool resources with other apps. Also, many atproto apps don't use a relay at all, and rely on a community cache like https://constellation.microcosm.blue/ instead.
Running an AppView is only as expensive as running any backend. "AppViews are expensive" is a myth extrapolated from "Running a copy of a Bluesky AppView is expensive", which is true because a Bluesky AppView is a backend server that's supposed to store and serve millions of posts. It would be expensive with any technology! Atproto isn't adding an extra tax here. Running a centralized service at the same scale would be equally expensive, and a Mastodon instance at that scale would simply not run.
If your AppView only serves your app's users (and has nothing to do with Bluesky), the cost is cheap or nonexistent. It's just a normal backend that listens to a websocket stream and writes some stuff to a database.
Effectively what I meant by 'if you just want to use ATProto for your own small app, there are ways to do it on more constrained hardware. The more usage it gets, the more it scales up', but appreciate the top-up!
Relays are trivial to run now with changes to how syncing works a while back. AppViews are entirely up to the designer of the view. You can make it as complex and expensive or cheap and fast as you want, it’s entirely up to you. You do not have to provide the exact same functionality as Bluesky’s AppView and can basically do whatever you want.
> it's more of a problem that it's so heavily dominated by US politics.
I agree the default Discovery feed is not great, but you can just switch to a different feed like For You or the recent Eurosky version of it, called 'fu'. It vastly improves the experience.
and only have one feed? forgive me if I understand incorrectly but I'll take an open market of thousands of feeds and easy tooling to make my own that can pull from the whole network over just one local feed controlled by a server admin
It's not that they didn't warn bluesky specifically. It's that they didn't warn relay operators in general. And IIRC they just needed to coordinate with a single relay operator who is reasonably trusted (ex blacksky or eurosky) but they didn't do that either.
The default rate limits are quite reasonable but big launches will blow past them so you gotta coordinate with someone.
And note that the relay federation/gossip agreements are largely manual configuration at the moment. Until someone pushes a proposal for an automated/dynamic topology management algorithm that doesn't get plagued with spam issues it'll stay this way.
It absolutely is. Mastodon has rate limits and administrators have to manage and adjust them as necessary for their instances.
You probably just don't notice it as a user or as the operator of a small instance which to be fair is exactly the same with atproto. Users rarely notice rate limits and small operators rarely do either. It's the operators of large services that see these limits and have to coordinate with other operators.
The issue with W social is that they have a chronic inability to coordinate or play nice with anyone else in the atproto space. Rate limits aren't a problem if you are a good neighbor and you know your neighbors but frankly they just don't.
My Mastodon instance blocked Threads preemptively because they were afraid of the traffic driving up their hosting costs so you’re basically just very wrong or lying about this. A huge flood of incoming traffic can be hugely expensive for ActivityPub node operators. The problem of giant onboarding events is real, there’s just no default protection against them in Mastodon like there is in Bluesky, so operators either have to take matters into their own hands with defederation or risk driving their bill through the roof.
Tons of people have started products without issue. But if you flood a popular relay with data that exceeds its rate limit then getting throttled is to be expected. This doesn’t prevent your participation in the protocol or network.
There are other relays and indexes out there that may have different rate limits. That’s just how these things work. The data from W is still there on their PDS, still public, still crawlable, and able to be backfilled within rate limits.
That literally prevents your participation in the network, because you need the relay to be forwarding your messages to participate in the network. There is only one relay in BlueSky that matters. If the BlueSky relay is not relaying your messages, then you aren't on BlueSky.
Bluesky is not all of atproto, first of all. There are a bunch of apps thats don’t use any relay at all. Second, even if you aren’t on bsky’s relay, there are others, like the Blacksky relay.
I’m guessing from your constantly-incorrect capitalization of “BlueSky” that you’re not familiar with any of this even a little bit and you’re just repeating what you’ve heard from other, equally unfamiliar people.
Nothing Bluesky does is really independent. This is such a transparent playbook and yet folks keep falling for a couple of open source repos and whatever hot takes Dan Abramov posts to reframe “instances” to “open social” bs.
In the same way that 99.99% of standard mastodon users are on mastodon.social, yes.
No, the million of users sharing porn on entirely isolated mastodon instances that absolutely nobody wants to federate with because you'd be exposed to pictures of minors within 5 minutes do not count.
yes, mastodon.social is big but there is more plurality. There is about 250k users on mastodon.social while whole fediverse is about 10 milion
On the other hand while tere is roughly 35 milion bluesky users there is only ~50k on non-blusky PDSes (https://blue.mackuba.eu/directory/pdses) so there's that…
Your diagram at the top of that explainer doesn't include the various Mastodon (not sure if instance<->reader is ActivityPub) client apps, but does include ATProto/Bluesky client apps. Without that, it seems rather incomplete and I don't feel like so can take away much from it?
Are you going to write it below my every comment? I've already replied to this here: https://news.ycombinator.com/item?id=48933050. Also, I don't think either claim in my reply is dependent on who wrote it. You can trivially verify them yourself.
I'll try to mention it once per discussion page in the future. Also, I have not been working at Bluesky for over a year. While I was there, I was working on the client app and not the protocol. In fact, initially I thought the protocol stuff was a bunch of nonsense.
In this case? Social Network protocol scene but generally the open source world (and every other niche interest in existence) has it's own bouts with scene drama.
This is part of the reason why I stopped heavily engaging with ActivityPub. It's not everyone because I know the team of folks who make apps for the space but it's engagement like this who convinced me to write https://www.jacky.wtf/essays/2024/one-over-other/ and had me just step away from ActivityPub (at least until I can see https://github.com/swicg/activitypub-api drop and I'll reengage).
This is a non-sequitur? ATProto was explicitly designed to not be compatible with ActivityPub. They shot first. So why are you focused on tone-policing ActivityPub?
What do you mean by “explicitly designed to not be compatible with ActivityPub”? What proof do you have for that other than “it doesn’t use ActivityPub”?
And you can’t tone police a standard. That’s very weird.
The single point of failure is always the biggest instances or communities, which impose their rules on everyone else under threat of refusing to communicate with them.
This has happened with every single federated platform, and it can’t be solved with technology because it’s fundamentally not a technology problem. People want to be where other people are, so once the community reaches a critical mass it inevitably degrades into the same sump of mediocrities and their rules as everything else.
I think you will find that a lot of people find that to be a feature of the federated networks. It's how society works outside of social networks. You aren't likely to see football fans of different teams sharing pubs here in Europe. You wouldn't see judgemental people be allowed in accepting roleplaying communities and so on. Why would a network of community controlled servers be any different than this? IRC was like this, Discord is like this. When you give people control they are going to kick out the opinions and people they don't want around.
If you find yourself on the outside, it might just be that you're the village idiot. Before SoMe platforms like twitter, facebook and other places without local moderation the village idiot didn't have much of a voice either.
Email and Usenet are both decentralized systems that in theory aren't affected by instance admin bitchfights anywhere near to the level of drama in the fediverse. Yes: many providers didn't mirror the binary groups due to piracy, and in email, deliverability is a constant issue thanks to spammers.
But the fediverse? Can't count how many times I've seen instance admins hold their users hostage in bitchfights over the Israel/Palestine stance of other instance admins.
Usenet was(is?) moderated similar, to IRC, Discord and so on with some newsgroups needing moderator approval for every single post. Also, there was a lot of drama on Usenet. I don't think it's that different from the fediverse. I guess you could debate whether moving your "personality" from one fediverse server to another when is worse than having to use a new email to access groups that banned you. With the fediverse you can certainly be punished for the actions of other people on your instance much easier compared to other platforms.
Email is probably the closest to anarchy. If you could get people to use it for group communications, every user could decide who they include in their "reply all", which would probably lead to absolute chaos.
The village idiot analogy is misguided and unnecessarily accusatory.
However, I do feel internet communities were better when they were smaller due to being special interest driven and self-policing. People wore different hats according to the community they were engaging with.
You're right, landsbytosse doesn't not translate well. To be fair the literal translation is village fool, which isn't much better. It's meaning would be more along the lines of village eccentric, which could be the village idiot, but not always.
There was a very steep curve to access the Internet back then (both economically and technically), and that was a very big filter (although it let through many smart assholes anyway).
Look at how ActivityPub works before saying it's single vendor controlled.
Really basically: Everyone can have their data (posts, media attachments) on whatever server they want or control, easily self hosted.
And at the same time, people can also host "apps" like Bluesky that read said data and interpret conventions in naming to show it in a meaningfull way like as posts.
you can self host your data.
you can self host a bluesky view.
It actually kind of reminds me of openstreetmap, where it's actually only a database of keys and values, but apps interpret their meanings based on conventions
I can’t imagine being a first time bootstrapped founder running a business without a trademark and not knowing that someone with bad faith would just register a trademark and just sue or order you to change your name.
These are the things that most startups account for when raising capital.
The community probably would have complained if they registered the trademark preemptively. But if they let the bad guys register it and then save the day it's the least bad solution.
The timeline just seems like two different brands wanted the name. atSign was using atProtocol as their thing. And trademarks are defend-or-lose. That AT Proto would grow so much more than atSign is just a thing we know now. They were both contemporaneous and it doesn't seem to have been some kind of gazumping operation so much as two groups landing on a name.
Chiming in to say as the CEO of Blacksky that not only do we have an independent AT Protocol implementation in Rust (https://github.com/blacksky-algorithms/rsky)
Not only do we run a fully independent stack (https://docs.blacksky.community/readme/list-of-our-services)
Not only are we getting paid by other orgs to stand up independent app view servers.
We also received a license from Bluesky for the atproto trademark.
There are no qualms in the ecosystem from people making money, getting users, and providing new experiences about this.
It’s not “AT Protocol fans” who aren’t taking issue with this. It’s business with employees and organizations making a positive impact.
It’s easy to criticize if you’re not actively shipping things.
I agree that this is not an apocalyptic moment for the protocol. And I support what Blacksky is doing, so I kind of hate that this will probably be the only thing I get to say to you.
But the argument that established, profitable organizations in the atproto space have no qualms with this move is not as reassuring as you might think.
I would not be surprised based on the post that the trademark will be given to some sort of non-profit foundation. The post itself made it seem pretty clear that the current reasons to have the PBC acquire it were:
1. An adversary attempting to do so in order to extract money (rent seeking).
2. There was less legal and financial overhead in doing so via the PBC.
While not everything BlueSky has done has been stellar, and there have been missteps, I think they’ve generally been exceptional stewards of atproto and the ecosystem. As a result, I’m willing to give them the benefit of the doubt they will stand by their word.
FWIW— shithead trolls doing things like acquiring copyrights to extract “rents” are exactly why every org I’ve ever worked for pays lawyers for bullshit copyright and patent applications. It’s not because they’re valid, it’s because it’s cheaper to do so upfront, than fight to disprove someone else own’s them later.
> We also received a license from Bluesky for the atproto trademark.
Is that license irrevocable/permanent from their side?
(It really needs to be, except for clauses against misconduct from your side.)
Yeah, I had significantly less apprehension about it myself on reading their docs, but thought it was still news XD
> We also received a license from Bluesky for the atproto trademark.
For now
Then they start calling it "buproto" or something. Firefox has a trademark too, but that didn't stop debian from distributing the same thing under the name Iceweasel...
Notably, from their FAQ:
> We’ve taken inspiration from other open-source projects that have taken a similar approach, including Wikimedia, Red Hat, Rust, Python Foundation, Apache, Mozilla, Linux, and Debian.
"I'm altering the deal. Pray I don't alter it any further."
Darth Vader, VP of Contract Renegotiation
> Bluesky recently acquired the rights to the trademark for “ATPROTOCOL” and its variants—including “AT Protocol” and “atproto”—from another company that was threatening to take legal action preventing the company and others from using the term. Now that Bluesky owns it, the atproto community’s continued use of the mark can be protected.
The policy around usage is shared in the rest of the post but the goal is to make this very simple for everyone
So what about the existing AT protocol modems use?
That's the Hayes command set[1]. Hayes was a registered trademark up until 2022[2].
[1] https://en.wikipedia.org/wiki/Hayes_AT_command_set [2] https://tmsearch.uspto.gov/search/search-results/73319703
I don't remember ever hearing that called AT proto or AT protocol, just AT commands or AT commandset etc.
Even though I'm that old, even I don't care even if it was anyway.
...as long as the reason is what it looks like. Rather have Bluesky claim it for the purpose of having the officially recognized legal authority to grant usage to everyone else, than have a rando douche company think they can claim it to extort or simply inhibit everyone else.
No one cares.
I had to shake my head for a moment as I was instantly transported back to 1998 with that comment lol
Anyone who's worked with cell modems knows that AT commands are very much still a thing, see here for example: https://www.etsi.org/deliver/etsi_ts/127000_127099/127007/17...
They use AT command set, not protocol.
I've heard it referred to as "AT command protocol." I googled it myself and this terminology is common enough.
... which is a protocol, thus pre-existing colloquial use of "AT protocol" that makes this trademark questionable.
The mere "pre-existing use" of a word or phrase does not disqualify a trademark.
Maybe you're thinking of prior art in a trademark? Or trademark genericization? But neither would apply here.
Is this a real thing? I don't think I've ever heard "AT protocol" before Bluesky. My first modem was 300 baud, so I wasn't totally out of the loop on this. DDG finds four hits for the phrase before 2020 used to describe the Hayes command set.
It is an incredibly common comment to be made on posts about atproto, so there certainly are a lot of people here for whom it was a thing.
I did a search and there are like three such comments in the past year, including this one.
Depending on how you search specifically, you may or may not get all of them. For example, if you searched for "at protocol" specifically, you wouldn't get comments that are like "I thought we were talking about the old modem protocol!" and similar.
Anyway I don't think that it means that atproto was misnamed or anything, just that this thread isn't the only time people have brought this up.
Government bodies can work for us at the point we collectively decide it’s a priority.
>We plan to transfer that ownership to an appropriate, independent protocol governance organization in the future.
I never realized there is no independent governance org that should have registered this. So AT is governed by a single for-profit entity, that also runs the only viable instance?
>that also runs the only viable instance?
This is a category error. There are no "instances" in atproto.
https://overreacted.io/there-are-no-instances-in-atproto/
It segments the network differently (into "hosting" and "apps"), and on both axes anyone can run their independent app-agnostic hosting, as well as an independent hosting-agnostic app.
Thanks, this is informative. I had meant 'instance' from more of a general user adoption perspective (i.e. Bluesky app user plus Bluesky PDS tenant), but based on other comments here that may not be too accurate either.
This "gotcha" might get cheers from your fellow AT proto fans but only eye rolls from everyone else.
I don't mean it as a linguistic gotcha ("ha, you said instances! but we call them something else"). I'm saying this is a category error because the network topology is different. This is like saying that web is not free because people aren't running Google-scale indexes in their garages.
Tried to clarify this here: https://news.ycombinator.com/item?id=48932956
Dan, you really should refine this line of reasoning a bit as it feels not very nice in some way: it feels like you're picking an unintuitive/uncommon definition for "instance" and then using that to tell everyone they're misunderstanding stuff then they're using different, arguably more widely accepted, definitions.
We've had a very similar discussion in response to this same argument recently elsewhere on HN. If you enjoy having this debate, then carry on, but I don't think it endears non ATProto users to the ATProto cause. I think it seems needlessly controversial/pedantic. Sorry for the blunt feedback, it's because I expect better from you:)
Let me try to explain my position.
The parent post says "the only viable instance" which implicitly packs an assumption of Mastodon-like topology: a single product is expected to be split into many "instances", with some of them being more or less "viable", and that a lack of many "viable" "instances" is perceived as the protocol not being a real thing, or failing to live up to its promise. (How else are you reading "viable instance"?)
I believe that if you look at the network topology, this argument becomes much closer to "Google Reader being the only viable instance of Google Reader means RSS is a scam with a single player". Which is an absurd thing to say. That is what I'm trying to show by picking at the word "instance".
Do you find my argument flawed, or just the way I present it? How do you prefer I present it alternatively? And how do you read the parent post? My issue isn't with the word, but with the implication in the parent post.
I think you're inferring something that people aren't implying, and that inference leads to you eventually discussing how ATProto is better than mastodon. I think this doesn't look great, particularly at a time where there's quite a few posts of about unproductive conflict between open social network contributors. I don't think there's any bad intent or malice on your side: there is value in comparison between AT/AP to help understanding.
Your argument that there are no instances in ATProto isn't flawed if you redefine instances as this thing that ATProto doesn't have. But if I run it by the various computer science definitions I can find (e.g. https://en.wikipedia.org/wiki/Instance_(computer_science)) then your argument seems like it depends on a niche interpretation. So it can be technically correct, but just irrelevant or inconvenient when used in a comp sci discussion involving the word "instance".
But your blog post on the subject is interesting, and informative, and has some great diagrams, and the original parent poster agreed and learned stuff from it. Despite that, I think the implication in the parent post was, IMO, "so the main, largest implementer (instance) of the protocol is also a for-profit which owns the trademarks? I never realised that, I'd assume the protocol was governed and run by a not-for-profit independent governance org, charity or consortium" (like some other open protocols).
I think that's a fair and slightly critical implication that has nothing to do with network topology. I completely get how you would want to take issue with that implication alone, because without context like the trademark was acquired with good intent to protect protect openness, and that the Bluesky org is a specific type of for-profit (PBC) that expresses intent to favour public benefit and openness, it makes things sound more sinister than they are.
Ultimately, from an openness and independence position, I think it would be better looking from the outside if the ATProto and trademarks were governed and managed by a separate not-for-profit entity that wasn't tied to the biggest instance/implementation of the protocol. I think that was the point being made, and I don't think it's absurd. But I think refuting that argument by focusing on network topology and instance definitions seems like a misunderstanding somewhere.
I don't think the Google comparison is doing you any favors in resolving the concern behind the category error, though. What I'm hearing is that AT is like the web if Google had started the web themselves and designed it around their index as the primary means of accessing anything on the web. Sure, they still have Don't Be Evil as their motto at this stage, and in the 90s maybe we would have been naive enough to believe them.
But in the 2020s, after watching what Google did to the web without being able to control the protocol from the beginning, a comparison of Bluesky to Google doesn't really assuage the concern people have about centralization.
>designed it around their index as the primary means of accessing anything on the web
That doesn't actually translate from the analogy though.
You don't use Bluesky to access other apps' data on atproto, you use those apps. You go to https://tangled.org/ for Tangled (atproto github), you go to https://leaflet.pub/ for Leaflet (one of atproto blogging platforms), and so on. Bluesky is not a "one stop shop" for all atproto stuff, it's just one of atproto apps, and anyone can make their own app.
The apps themselves have to compete on their own merit, completely unrelated to the protocol stuff. The protocol just makes them all interoperable and changes market dynamics (e.g. someone can resurrect a dead app by creating a new projection of existing data). If your criticism is that there aren't many apps on atproto yet — fair, but you can make those! People are making those. This is something you can actively contribute to, there's no permission you need to ask.
The "Bluesky index" is the index of Bluesky posts, so naturally you access that primarily through the Bluesky app. (Although even that isn't set in stone — see Blacksky who run their own stack for everything, but also show Bluesky posts.) And then, if you make your own app with your own data types, it would not be related to Bluesky in any way.
>But in the 2020s, after watching what Google did to the web without being able to control the protocol from the beginning, a comparison of Bluesky to Google doesn't really assuage the concern people have about centralization.
Sure, and is your argument that it's better if the web had never happened? Atproto is going to IETF so it will become a "proper" internet standard. The way you shift the balance of power is by building your own stuff on it.
It's great that you can make your own independent apps on atproto, and you're right that I overstated the "anything on the protocol" in the analogy. Analogies are always lossy, but that was worse than necessary.
But notice that what you're now arguing is not that Bluesky is equally decentralized to Mastodon as a social network, you are arguing that while Bluesky the app may be in practice highly centralized that doesn't mean other apps can't exist:
> The "Bluesky index" is the index of Bluesky posts, so naturally you access that primarily through the Bluesky app.
It probably is entirely true that different apps can spin up on atproto independently, but that was never the actual point of concern. This, what you say right here, is the actual concern. This specific app (or any atproto app) appears to have significant lock-in—to the point where you identify it as "natural" that it would be so—while selling itself on decentralization.
Blacksky is an interesting case, and I'm wondering why you didn't roll it out at the beginning and why you still hedge it as "natural" that you'd access the Bluesky app data through Bluesky? I'm actually unfamiliar with the territory here, but coming from my knowledge of the fediverse that seems an odd pairing. If a fully independent implementation exists, why is it natural that you'd use the central one?
>It probably is entirely true that different apps can spin up on atproto independently
It's true, and I want to emphasize that they need nothing to do with microblogging or Bluesky posts. I think it's important to internalize this because most discussions about Mastodon are about microblogging modality. But, say, Tangled is a git hosting with social layer (issues, PRs) on atproto. So we are really comparing fundamentally different ecosystems already. Atproto is not centered around Bluesky posts or Bluesky app; it's just that Bluesky app happens to be the biggest app built on top of atproto primitives.
>This, what do you say right here, is the actual concern. This specific app (or any atproto app) appears to have significant lock-in—to the point where you identify it as "natural" that it would be so—while selling itself on decentralization.
You're starting with the Mastodon perspective of "a social network is a set of fragmented views of the network with no shared sense of identity or global aggregation/search which talk to each other" and consider it natural.
Whereas I start with the regular user's understanding of a social app — it's a place where you can come, where you can see the entire world at once, where all features (global search, recommendations, follow graph) are global by default, and where you don't "belong" to any particular community to an extent that this community can cut you off from your followers or ban you. Instead, the app is serviced by app's developers and you're at their mercy.
Now, what does atproto try to do?
From the user's point of view, it looks as the familiar "centralized" approach — apps can have global search, recommendation algorithms, there's no fragmentation. Each app is a prism over the entire network and always shows a consistent view over it. App developers do have full control over how the app presents it. There aren't 100 copies of the same app because there are 100 communities on it. This split into instances is a "Mastodon-brained" way of thinking.
However, the underlying data lives in an app-agnostic layer. So Blacksky was able to kickstart their own projection of atproto network (filtered down to Bluesky stuff since their app is initially a clone of Bluesky). It's not an easy job to make it work for billions of posts, but no Mastodon instance even tries to support that scale. Atproto makes supporting that scale possible, and then we say "oh but this is expensive". Of course it is — it's expensive to store content from millions of people with any technology. But unlike centralized services (which atproto tries to match in baseline UX expectations), it is possible to spin up alternative projections of the same network that fully participate in it, when folks have concrete reasons to do so. (For example, Blacksky is able to take different moderation decisions as a result.)
You can go further. https://reddwarf.app/ is a working app displaying Bluesky data that does not have a backend at all and does not use Bluesky (or Blacksky) API servers. Instead, it loads data directly from the hosting layer, and uses https://constellation.microcosm.blue/ network index for querying relationships (like "give me a list of likes for this post"). This is less efficient than maintaining an index (so it loads a bit slower) but it's totally a workable model. The Constellation index itself, if I'm not mistaken, runs on someone's Raspberry Pi.
Of course, you can also "scale down" atproto to make it apples-to-apples with Mastodon. You'd add some code that filters down events only to those that are "relevant" to people who are "on" your "server" and their follows. This would be a "small world" atproto that would be easy for anyone to spin up. It's not very exciting but I guess we'll see more experiments in that area as people realize it is possible. But it's also just less exciting because you can also run the real thing if you're motivated enough. And the fact that anyone can choose to do it if there's a real need means people don't create a 1000 of shallow Bluesky clones. It just doesn't solve any actual problems other than trying to win arguments like this.
I don't think "decentralization" is a super useful prism to think about atproto. Atproto is a high scale syndication protocol, like typed signed RSS via HTTP and WebSockets with a shared data model and identity upstreamed into the web. This protocol enables independent apps, independent hosting providers, and independent caches and relays to build and participate in a shared ecosystem. That ecosystem lives on the web, so it's "decentralized" in the same sense that web itself is. But it doesn't mean that each product must be split into a thousand pieces at the UX level.
> and designed it around their index as the primary means of accessing anything on the web
Except that you don't have to use an ATproto relay (the “index” equivalent here) to access anything on ATproto; there's nothing stopping you from grabbing records directly from anyone's PDS. You'd just need some way to know which PDS to consult; that's normally the relay's job, but it doesn't have to be (nor does the relay necessarily need to snarf every record from every PDS if you know you only care about a subset of that info).
[flagged]
I haven't worked at Bluesky for over a year now. I'm genuinely excited about the protocol, and have written a bunch of things about it while I had free time between jobs. (Ironically I had no time to write about it while at Bluesky because I was too busy working around React Native bugs.)
>it's impossible to actually participate in Bluesky using an alternative relay
I don't know what you mean by this. https://blacksky.community/ is definitely running their own relay. Here's a community listing of some relays: https://atproto.at/relays.
Here's an example of connecting to one of them: https://pdsls.dev/firehose?instance=wss%3A%2F%2Feurope.fireh.... From an app's perspective, they're completely interchangeable, so as an app developer you can switch to any relay you want, or run your own.
Many apps don't even use a relay at all, instead relying on caches like https://constellation.microcosm.blue/.
There is an IETF Working Group these days https://atproto.com/blog/kicking-off-the-atp-working-group
Those can't register trademarks, of course.
> that also runs the only viable instance?
This is false, both in the framing ("instances") and in the viability of running alternative infrastructure.
But it’s true in the general idea of Bluesky being highly centralized and dependent on a single for-profit entity.
https://news.ycombinator.com/item?id=48931191
Why can't the IETF register trademarks?
Does the IETF register trademarks on behalf of their working groups? It’s possible that I’m just misinformed about that.
I left this comment shortly before bed and my thought process was “a working group isn’t a legal entity and therefore can’t do this” but it’s entirely possible that that was shortsighted of me.
(Obviously the IETF itself can.)
Well, clearly they can:
https://static.ietf.org/logos/ietf.svg
How do you mean? As in you can run different instances or as in it's a false open protocol?
It's a different network topology. ActivityPub couples three things into one box: community, hosting, and an app.
Atproto decouples them: there's app-agnostic hosting (which anyone can run), and there's hosting-agnostic apps (which anyone can run).
I wrote about it here: https://overreacted.io/there-are-no-instances-in-atproto/#so...
Read the recently frontpaged "There are no instances in ATProto" by dan abramov <https://news.ycombinator.com/item?id=48599515>
ATProto is closer to how RSS works than ActivityPub. In the same way talking about "RSS instances" makes little sense, the same goes for "ATProto instances".
It makes sense to talk about “RSS aggregators”. Especially it makes sense to talk about “RSS aggregators that speak a specific vocabulary on top of RSS, host 99% of content using that vocabulary, and if you host your own RSS feed with said vocabulary they’ll show it in their aggregator but can ban it any minute”.
Did I just describe Apple Podcasts? Huh. Regardless, yeah, there’s no “ATProto instances” technically, but there are ATProto apps and the single biggest one now owns the trademark to the protocol name.
i guess that's fair, but i've never listened to a podcast from a non-foss app; i'm not really "in" the podcast sphere, but from where i'm sitting it seems podcasting would survive and migrate just fine if apple podcasts had to go away suddenly
I guess that’s fair, too. I’m not really into podcasts either, and the ecosystem seems healthy enough. Many FOSS podcast clients use Apple for discovery, which I guess make sense; but there’s probably other databases, and the contents themselves aren’t usually hosted by Apple, just the metadata.
So yeah, podcasts are in good shape. In fact, they are probably the most used decentralized media right now (apart from torrents, maybe). I hope Bluesky gets to that point, and I do wish them luck, but we’ve got to see the incentives are not that well aligned. As for the trademark... it’s surely weird, it’s not the end of the world if they continue to hold it, but setting up a non-profit (not in US, perhaps) for the protocol itself would probably be more appropriate down the road.
The solution to that is to create more apps, and for one of them to become more popular. This is entirely in our hands as developers.
The thing with ATProto is, there is little incentive in creating apps that speak the app.bsky vocabulary. If I understand correctly, there is one other full-fledged app that does that, Blacksky [0]. By full-fledged, I mean they host a PDS, a relay, an app view, a moderation service, and a bunch of feeds and other doodads. If Bluesky goes down, Blacksky will probably be fine. They are, however, yet another US company [1], which is not ideal.
[0]: https://docs.blacksky.community/
[1]: https://blackskyweb.xyz/about/support/tos/#:~:text=Blacksky%...
Even if that was the case, Google Reader's death almost took RSS with it so the concern remains valid.
> So AT is governed by a single for-profit entity
A Public Benefit Corporation to be precise. So they are legally obligated to favor public benefit.
OpenAI proved even being a nonprofit can be handled away if the money's good enough. PBCs are much weaker in that regard than nonprofits.
No, public benefits are allowed to include public interest reasons in their decision making, they are not required.
This structure was created to allow a business to protect the interest of the public when it conflicts with the interests of their shareholders
"Only viable instance" is not really the correct framing - Bluesky doesn't have instances. Anyone using ATProto without Bluesky will still be "on Bluesky".
When you go to bsky.app, you're interacting with the Bluesky AppView; one key feature of ATProto is that any AppView can interact with any (consenting) Personal Data Server (PDS). So you can self-host your PDS but still use bsky.app if you so choose. But critically, anyone can write an AppView; there are reimplementations of Bluesky as well as other social apps that use the same ATProto infrastructure. That would be closest thing to a Mastodon instance, except you don't have to host your data on it in order to use it. Imagine being able to go to a Lemmy instance and just post things with your Mastodon identity, and have everything show up without Mastodon having to know anything about Lemmy magazines or its special upvote / comment formats.
The actual centralization in ATProto lies in a combination of unfortunate design decisions and genuine friction in the self-hosted path. Being totally reliant on Bluesky is the happy path, self-hosting your PDS data is difficult but doable, and being totally independent of Bluesky is only possible if you do everything correctly right at the start.
First off, Bluesky doesn't offer any GUI tools for PDS migration. If you want to get off their PDS, you'll need to bust out command-line tools and possibly do some steps in advance of when you need to migrate in order for everything to work properly.
Second, even if you're on a PDS, you're still reliant on the Public Ledger of Credentials (PLC) to host your Distributed ID (DID) document. The PLC is run by Bluesky, although they've taken steps to make it easy to notice if they were to do something fucky with the PLC. But let's say we don't like that. There is a solution: you can host your DID document on a normal web server. Problem solved?
Well, if you were setting up an account for the first time, then yes, the problem is actually solved, you're 100% independent of Bluesky. But if you made the mistake of registering an account normally, you have a did:plc identity. And one core principle of ATProto is that identity names never ever ever change. So if you go and make a did:web identity, it's like having a second account, there is no way to tie your old did:plc identity into it. In fact, I'm pretty sure you can't even redirect one did:web identity to another (say if you need to switch domain names)
Regarding Bluesky's "independent protocol governance organization", they made the same promise about the PLC; but it hasn't actually been transferred yet. I would be a lot more bullish on ATProto if there was a way to migrate DIDs and retain all your followers and shit. And if there was proper graphical tools for data migration.
The PLC governance not having been moved yet is my one main gripe against ATProto/Atmosphere now. There is so much being built on top of this protocol, and I truly believe it has the chance to make the social web more decentralized while keeping everything connected. The PLC being controlled by one major commercial entity allows them to pull the plug so to speak. Say someone is sanctioned by the US, what stops Bluesky from pulling the plug on their DID thereby blocking and censoring this person from the network all together.
Half the point of ATProto is that identities are used across a host of apps, and therein lies a big vulnerability. If identities are not truly independent of centralized infrastructure, then you are vulnerable to losing access to a number of apps at once similar to Google services black hole if your Google account is banned (not to mentioned anywhere you've logged in with SSO).
It would be much better if the PLC was somehow decentralized itself. Barring that it should at least be finally spun out as the independent Swiss organization they've talked about for some time now. The organization could form a board with interested parties to set the future of PLC development if needed.
As for PDS migration, there are good options if you are migrating away from Bluesky. There are lots of GUI tools that work well now like https://pdsmoover.com/moover, Eurosky has https://move.eurosky.tech/, etc. It would be cool though if Bluesky actually linked to the other big PDS-providers on the Bluesky sign-up page to actually promote decentralization. But I guess it is hard to vouch for other services.
I still think the future of ATProto is bright, but there are definitely some obstacles before I'm comfortable with the whole setup. The network needs more decentralization in the PDS-layer, and the PLC needs to spin out in the separate governance organization pronto.
Technically it has moved (last year actually) but it just doesn't really look all that different in the day to day.
https://atproto.com/blog/plc-directory-org
Did they actually create the org yet? I saw the news you are linking that they were going to start the process. But I've seen no follow up news about the organization actually being here and the ownership of the PLC directory having been transferred.
> Say someone is sanctioned by the US, what stops Bluesky from pulling the plug on their DID thereby blocking and censoring this person from the network all together.
How does IANA handle this with domain names? genuine question, i'm not sure. is it enough to have distinct registrars and distinct jurisdictions for some TLDs and so on?
They don't. All domains have US jurisdiction except the ones that are underneath country TLDs.
IANA could stop publishing country TLDs in their root zone file but it would probably split the internet in two, and everyone involved knows that. Several root server operators would refuse the update, and many recursive resolver operators would put them back in.
>First off, Bluesky doesn't offer any GUI tools for PDS migration. If you want to get off their PDS, you'll need to bust out command-line tools and possibly do some steps in advance of when you need to migrate in order for everything to work properly.
This is getting much better recently. I migrated to https://eurosky.tech/accounts/ with no command line — just needed to wait for a wizard in my browser to move my records. It could've been much faster and seamless (the app was confused after this and I had to re-login), but it's definitely accessible to non-technical people, and the share of independent hosting is growing.
Bluesky has a data store, handles account authorization, and runs a web app that provides a UI to access the backend services. That's an instance, whether they call it one or not. Refusal to admit this is obfuscation for reasons I cannot understand.
The reason is that "why aren't many people running Bluesky instances" is a loaded question — it presupposes that's something you should expect. But it's like asking "why aren't many people running Google". It's expensive to store billions of posts!
This is usually compared to Mastodon, but it's not apples to apples since "running a Mastodon instance" always mean a tiny partial view of the network. You can do a partial view of atproto too for the same cost, it's just not very interesting because what's the point? Every app can "see" the entire network (unlike in ActivityPub) so there's a lot less motivation to create these fragmented views into it.
I've already linked elsewhere, but I've written an article on precisely this topic, curious to see if this can clarify it for you: https://overreacted.io/there-are-no-instances-in-atproto/#so...
> I would be a lot more bullish on ATProto if there was a way to migrate DIDs and retain all your followers and shit. And if there was proper graphical tools for data migration.
This is exactly where I’ve landed re: ATProto. If you actually want to self-host everything you lose one of the biggest draws of it, the migratable IDs.
I was looking into it to build an alternative to Threads/IG/TikTok for one of my hobby communities that’s become almost entirely reliant on Meta/Tencent. Being able to plug into the wider AT Proto world was a big draw, but not being able to self host a true alternative to did:plc has put a halt to that for now while I figure out what I want to do.
I didn’t fully understand the part of the stack you’re talking about, but it always seemed like one of ATProto’s design goals was to really keep everything on the same distributed system (so to speak) while allowing people to host the bits individually that all contribute to the same connected system. Eg not having fully separate networks that don’t talk to each other
If you want a nice overview of the DID stuff, Steve Klabnik just recently made a post going into detail about did:plc and did:web
https://steveklabnik.com/writing/too-many-words-about-dids/
I don't know what you mean by this. You absolutely can self-host all your data on your own. And if you also don't want to rely on PLC for identity, you make a `did:web` identity, and then you're completely decoupled from Bluesky-operated infra.
Dan my concern is explicitly that did:web is not the same experience for users as a did:plc.
If I host AT Proto infra for my community and want to give people <usename>.<domain> accounts, I can either host a did:web for them which ties their account permanently to that domain, or they have to register with the centralized PLC to actually have all the benefits of a migratable DID. did:web does not provide the same UX as did:plc
From the post I was responding to:
> Second, even if you're on a PDS, you're still reliant on the Public Ledger of Credentials (PLC) to host your Distributed ID (DID) document. The PLC is run by Bluesky, although they've taken steps to make it easy to notice if they were to do something fucky with the PLC. But let's say we don't like that. There is a solution: you can host your DID document on a normal web server. Problem solved?
>
> Well, if you were setting up an account for the first time, then yes, the problem is actually solved, you're 100% independent of Bluesky. But if you made the mistake of registering an account normally, you have a did:plc identity. And one core principle of ATProto is that identity names never ever ever change. So if you go and make a did:web identity, it's like having a second account, there is no way to tie your old did:plc identity into it. In fact, I'm pretty sure you can't even redirect one did:web identity to another (say if you need to switch domain names)
I did read your post :) Yes, you can't migrate between PLC and WEB methods. It's not possible. I get that it's frustrating if you learn about it after making an account. Is that the whole concern?
I was replying to this:
>not being able to self host a true alternative to did:plc has put a halt to that for now while I figure out what I want to do.
I'm saying I don't know what this means. You can fully self-host with `did:web`. Yes, it's unfortunate that you've already made an account by the time you've realized that. I think that's still different from "not being able to self host".
Unless I'm just parsing what you wrote incorrectly, which is quite possible!
My understanding is that if I want to host AT Proto infra for my community and want to give people <usename>.<domain> account, I can either host a did:web for them which ties their account permanently to that domain, or they have to register with the centralized PLC to actually have all the benefits of a migratable DID, while tying themselves to a central authority. Ergo, did:web does not provide the same UX as did:plc and there’s currently no way (that I know of) to provide such UX to users without requiring them to register did:plc accounts
>want to give people <usename>.<domain> account
To clarify, do you mean you want their domain handles to look like this, or do you want to make them all have `did:web` identities? These are two different questions. Domain handles would work either way (with `did:plc` or `did:web`).
Indeed, the choice between `did:plc` and `did:web` is precisely "would I rather host tie identity JSON document to an entry in a centralized open source publicly verifiable registry that is moving to be maintained as neutrally as possible, or would I rather choose to tie my identity JSON document to a domain". And that choice has to be done at the account creation because every DID, by design, is immutable.
What options are lacking in that choice? It feels like it has an option for a pragmatist and an option for a purist.
>Ergo, did:web does not provide the same UX as did:plc
I mean, that is the difference between them. `did:web` means "I don't want to depend on anyone except domain authorities; I'm fine with losing identity if I lose the domain". Choosing `did:plc` means "I'm okay with depending on a central registry and find the threat model around it acceptable; I never worry about losing a domain". Both options are available.
Thanks for your clear and concise explanation!
The nightmare of the Wsocial rollout is a testament of the massive control Bluesky has on the ATProto network.
If Wsocial was on ActivityPub or Nostr nothing similar would have happened.
ATProto has serious centralisation problems, baked into the design. And it makes sense, considering it came out of a Twitter R&D experiment to "decentralise" Twitter itself. Pure federation was never part of the initial design.
ActivityPub and Nostr solve the issue already.
I think decentralization is just not something users care about generally.
- many people wish they could control what they see and who they talk to. (Eg control the algorithm, avoid censorship from big tech)
- some people care about owning their data so it doesn’t go away when a company fails
- technical people are interested in building more types of social apps that aren’t just twitter posts etc
- nearly everyone just wants a fairly seamless experience without a lot of gotchas or technical problems to solve like self hosting an instance for your friends that falls over if too many people use it and is tricky to network with others.
Bluesky is trying to solve all those kinds of problems, which I think is pretty interesting, and I don’t think the others are quite doing the same thing technically. At the end of the day they are all pretty niche.
But Bluesky does not solve these points:
- content not in line with the political left is censored
- sure, you have your data in your PDS, but it is de-facto useless if the central identity server of Bluesky goes down
- ActivityPub and Nostr solve this already without being owned by a company
- you cannot easily and cheaply have an ATProto instance. AP and Nostr solve this already
> - content not in line with the political left is censored
What do you mean? Individual apps can choose to censor I guess, but you can fairly trivially run an AppView with no filtering whatsoever if that's what you fancy.
> - sure, you have your data in your PDS, but it is de-facto useless if the central identity server of Bluesky goes down
That's not correct. You can use plc, which Bluesky operates the largest directory for, but you can also use web, which completely bypasses Bluesky all together.
> - ActivityPub and Nostr solve this already without being owned by a company
What's 'this' here?
> - you cannot easily and cheaply have an ATProto instance. AP and Nostr solve this already
The terminology here of 'ATProto instance' doesn't really make sense. If you're talking about a PDS, you can use one of thousands of free PDS hosts, or host your own for free on Cloudflare (https://cirrus.earth/) or on your own hardware (there are PDS implementations which fit comfortably onto a Raspberry Pi, or an old phone, etc.)
Sure you can host your PDS, but if you want to deploy your own instance like you would do with Mastodon, you need to deploy a Relay and an AppView as well. And the way the network works, you need beefy servers for that.
On ActivityPub and Nostr you develop all kind of applications already, it is not only Twitter clones, but also Instagram clones, Reddit clones, on Nostr there is even the resurrected Vine (https://about.divine.video/).
And it is not trivial to switch from the Bluesky did:plc (which you cannot run in write-mode on your own and need to use the official Bluesky owned) to did:web, which you can run on your own.
The idea of an 'instance' is not really clear. If you want to run a social network on ATProto, you do need the relay and app view, and those are indeed heavy requirements, but the architecture is not the same, and it depends what you're actually trying to achieve.
If you just want to use ATProto for your own small app, there are ways to do it on more constrained hardware. The more usage it gets, the more it scales up.
> On ActivityPub and Nostr you develop all kind of applications already, it is not only Twitter clones, but also Instagram clones, Reddit clones, on Nostr there is even the resurrected Vine (https://about.divine.video/).
Same! You can explore the (unfortunately named, given the point I'm trying to make :)) 'Bluesky directory' to see apps which use ATProto: https://blueskydirectory.com
Note that most of these have nothing to do with Bluesky.
> And it is not trivial to switch from the Bluesky did:plc (which you cannot run in write-mode on your own and need to use the official Bluesky owned) to did:web, which you can run on your own
That's true, but it's not trivial to run your own Mastodon instance either...
>If you want to run a social network on ATProto, you do need the relay and app view, and those are indeed heavy requirements, but the architecture is not the same, and it depends what you're actually trying to achieve.
Note those are not heavy requirements in any atproto-specific sense.
Running an atproto relay (at the current scale) is $30/month. If you're running a popular app, this is probably comparable with some of your SaaS subscriptions. Or you could use a community-run one or pool resources with other apps. Also, many atproto apps don't use a relay at all, and rely on a community cache like https://constellation.microcosm.blue/ instead.
Running an AppView is only as expensive as running any backend. "AppViews are expensive" is a myth extrapolated from "Running a copy of a Bluesky AppView is expensive", which is true because a Bluesky AppView is a backend server that's supposed to store and serve millions of posts. It would be expensive with any technology! Atproto isn't adding an extra tax here. Running a centralized service at the same scale would be equally expensive, and a Mastodon instance at that scale would simply not run.
If your AppView only serves your app's users (and has nothing to do with Bluesky), the cost is cheap or nonexistent. It's just a normal backend that listens to a websocket stream and writes some stuff to a database.
Effectively what I meant by 'if you just want to use ATProto for your own small app, there are ways to do it on more constrained hardware. The more usage it gets, the more it scales up', but appreciate the top-up!
Relays are trivial to run now with changes to how syncing works a while back. AppViews are entirely up to the designer of the view. You can make it as complex and expensive or cheap and fast as you want, it’s entirely up to you. You do not have to provide the exact same functionality as Bluesky’s AppView and can basically do whatever you want.
> - content not in line with the political left is censored
Can you provide examples to me of this being true?
Wait, how do you think these two things relate, exactly, and how does it point in the direction of “Bluesky has so much control”?
Thats a claim with zero evidence put forward, and one that if evidence were put forward, would swing the opposite way.
What went wrong with Wsocial?
I don't mind the quasi-central nature of bsky, it's more of a problem that it's so heavily dominated by US politics.
> it's more of a problem that it's so heavily dominated by US politics.
I agree the default Discovery feed is not great, but you can just switch to a different feed like For You or the recent Eurosky version of it, called 'fu'. It vastly improves the experience.
Or join a European Mastodon server and solve the problem at the root.
and only have one feed? forgive me if I understand incorrectly but I'll take an open market of thousands of feeds and easy tooling to make my own that can pull from the whole network over just one local feed controlled by a server admin
https://blog.elenarossini.com/w-social-a-broken-ghost-town/
Basically, because they didn't warn Bluesky that they were going live, they had their traffic heavily trottled and they were unable to function.
So long for decentralisation if you need to talk to the owner of the protocol you are trying to use...
It's not that they didn't warn bluesky specifically. It's that they didn't warn relay operators in general. And IIRC they just needed to coordinate with a single relay operator who is reasonably trusted (ex blacksky or eurosky) but they didn't do that either.
The default rate limits are quite reasonable but big launches will blow past them so you gotta coordinate with someone.
And note that the relay federation/gossip agreements are largely manual configuration at the moment. Until someone pushes a proposal for an automated/dynamic topology management algorithm that doesn't get plagued with spam issues it'll stay this way.
No such problem on Mastodon/ActivityPub.
It absolutely is. Mastodon has rate limits and administrators have to manage and adjust them as necessary for their instances.
You probably just don't notice it as a user or as the operator of a small instance which to be fair is exactly the same with atproto. Users rarely notice rate limits and small operators rarely do either. It's the operators of large services that see these limits and have to coordinate with other operators.
The issue with W social is that they have a chronic inability to coordinate or play nice with anyone else in the atproto space. Rate limits aren't a problem if you are a good neighbor and you know your neighbors but frankly they just don't.
My Mastodon instance blocked Threads preemptively because they were afraid of the traffic driving up their hosting costs so you’re basically just very wrong or lying about this. A huge flood of incoming traffic can be hugely expensive for ActivityPub node operators. The problem of giant onboarding events is real, there’s just no default protection against them in Mastodon like there is in Bluesky, so operators either have to take matters into their own hands with defederation or risk driving their bill through the roof.
Wsocial turned out to be a WEF honeypot or something.
That is not the point.
The point is that without talking with Bluesky, you cannot start your own ATProto product or you'll get throttled from the network.
Tons of people have started products without issue. But if you flood a popular relay with data that exceeds its rate limit then getting throttled is to be expected. This doesn’t prevent your participation in the protocol or network.
There are other relays and indexes out there that may have different rate limits. That’s just how these things work. The data from W is still there on their PDS, still public, still crawlable, and able to be backfilled within rate limits.
This is a non-issue.
That literally prevents your participation in the network, because you need the relay to be forwarding your messages to participate in the network. There is only one relay in BlueSky that matters. If the BlueSky relay is not relaying your messages, then you aren't on BlueSky.
Bluesky is not all of atproto, first of all. There are a bunch of apps thats don’t use any relay at all. Second, even if you aren’t on bsky’s relay, there are others, like the Blacksky relay.
I’m guessing from your constantly-incorrect capitalization of “BlueSky” that you’re not familiar with any of this even a little bit and you’re just repeating what you’ve heard from other, equally unfamiliar people.
Almost like the network is centralised.
Yes. It has never been decentralised.
Nothing Bluesky does is really independent. This is such a transparent playbook and yet folks keep falling for a couple of open source repos and whatever hot takes Dan Abramov posts to reframe “instances” to “open social” bs.
If you have concrete counterarguments to what I said in my articles, I would be happy to debate these counterarguments here.
Cool people use ActivityPub.
Single vendor owned & controlled standards always turn out badly, just a question when.
>Cool people use ActivityPub.
ActivityPub solves a completely different (arguably, smaller) set of problems. This is like saying "Cool people use email instead of web".
I have a few diagrams here that may help see just how different they are: https://overreacted.io/there-are-no-instances-in-atproto/#so...
>Single vendor owned & controlled standards always turn out badly, just a question when.
Yeah, which is why atproto is going to IETF: https://atproto.com/blog/kicking-off-the-atp-working-group. You can join the mailing list to participate in the discussions: https://mailarchive.ietf.org/arch/browse/atp/?gbt=1&index=.
Right… and still 99,99% of everything is held by bsky PDS and goes through their rely and appview… so much for "distributed federation"
In the same way that 99.99% of standard mastodon users are on mastodon.social, yes.
No, the million of users sharing porn on entirely isolated mastodon instances that absolutely nobody wants to federate with because you'd be exposed to pictures of minors within 5 minutes do not count.
A bizarre exaggeration. In my feeds, maybe 1/4 to 1/3 of the people I follow use non-.social instances. The same cannot be said of Bluesky.
maybe 1/2 of the people in my bsky feeds use non bsky pds'es & clients?
Mastodon.social is too big, but it is on a different scale: https://arewedecentralizedyet.online
(Though I do agree it's partially irrelevant, depending on what problem you're trying to solve.)
yeah… but nope.
yes, mastodon.social is big but there is more plurality. There is about 250k users on mastodon.social while whole fediverse is about 10 milion
On the other hand while tere is roughly 35 milion bluesky users there is only ~50k on non-blusky PDSes (https://blue.mackuba.eu/directory/pdses) so there's that…
check your sources
Your diagram at the top of that explainer doesn't include the various Mastodon (not sure if instance<->reader is ActivityPub) client apps, but does include ATProto/Bluesky client apps. Without that, it seems rather incomplete and I don't feel like so can take away much from it?
The author of this comment is an engineer at Bluesky.
Are you going to write it below my every comment? I've already replied to this here: https://news.ycombinator.com/item?id=48933050. Also, I don't think either claim in my reply is dependent on who wrote it. You can trivially verify them yourself.
It's relevant, disclosure is a sign trust and failure to disclose past relations breaks that trust.
I'll try to mention it once per discussion page in the future. Also, I have not been working at Bluesky for over a year. While I was there, I was working on the client app and not the protocol. In fact, initially I thought the protocol stuff was a bunch of nonsense.
If it's no issue, why not put a "note: I work for bluesky" on your posts?
Never underestimate the siren song of scene drama.
What scene?
In this case? Social Network protocol scene but generally the open source world (and every other niche interest in existence) has it's own bouts with scene drama.
this is no longer true as of a year ago. also “the author” is dan abramov lmao
This is part of the reason why I stopped heavily engaging with ActivityPub. It's not everyone because I know the team of folks who make apps for the space but it's engagement like this who convinced me to write https://www.jacky.wtf/essays/2024/one-over-other/ and had me just step away from ActivityPub (at least until I can see https://github.com/swicg/activitypub-api drop and I'll reengage).
This is a non-sequitur? ATProto was explicitly designed to not be compatible with ActivityPub. They shot first. So why are you focused on tone-policing ActivityPub?
What do you mean by “explicitly designed to not be compatible with ActivityPub”? What proof do you have for that other than “it doesn’t use ActivityPub”?
And you can’t tone police a standard. That’s very weird.
Actually, it is possible to join Bluesky without relying on the single point of failure, as Cory Doctorow highlighted here: https://pluralistic.net/2026/03/05/executive-dysfunction/
The single point of failure is always the biggest instances or communities, which impose their rules on everyone else under threat of refusing to communicate with them.
This has happened with every single federated platform, and it can’t be solved with technology because it’s fundamentally not a technology problem. People want to be where other people are, so once the community reaches a critical mass it inevitably degrades into the same sump of mediocrities and their rules as everything else.
I think you will find that a lot of people find that to be a feature of the federated networks. It's how society works outside of social networks. You aren't likely to see football fans of different teams sharing pubs here in Europe. You wouldn't see judgemental people be allowed in accepting roleplaying communities and so on. Why would a network of community controlled servers be any different than this? IRC was like this, Discord is like this. When you give people control they are going to kick out the opinions and people they don't want around.
If you find yourself on the outside, it might just be that you're the village idiot. Before SoMe platforms like twitter, facebook and other places without local moderation the village idiot didn't have much of a voice either.
Email and Usenet are both decentralized systems that in theory aren't affected by instance admin bitchfights anywhere near to the level of drama in the fediverse. Yes: many providers didn't mirror the binary groups due to piracy, and in email, deliverability is a constant issue thanks to spammers.
But the fediverse? Can't count how many times I've seen instance admins hold their users hostage in bitchfights over the Israel/Palestine stance of other instance admins.
Usenet was(is?) moderated similar, to IRC, Discord and so on with some newsgroups needing moderator approval for every single post. Also, there was a lot of drama on Usenet. I don't think it's that different from the fediverse. I guess you could debate whether moving your "personality" from one fediverse server to another when is worse than having to use a new email to access groups that banned you. With the fediverse you can certainly be punished for the actions of other people on your instance much easier compared to other platforms.
Email is probably the closest to anarchy. If you could get people to use it for group communications, every user could decide who they include in their "reply all", which would probably lead to absolute chaos.
The village idiot analogy is misguided and unnecessarily accusatory.
However, I do feel internet communities were better when they were smaller due to being special interest driven and self-policing. People wore different hats according to the community they were engaging with.
You're right, landsbytosse doesn't not translate well. To be fair the literal translation is village fool, which isn't much better. It's meaning would be more along the lines of village eccentric, which could be the village idiot, but not always.
There was a very steep curve to access the Internet back then (both economically and technically), and that was a very big filter (although it let through many smart assholes anyway).
> People want to be where other people are
not neceessarily true, see Matrix where it pretty much doesn't matter where you are
> This has happened with every single federated platform
It didn't happen with the internet itself. You still can avoid Facebook and co. and happily discuss things on HN.
And with the email, it is much less serious than people assume. I do not use gmail or MS and practically nobody I talk to does.
actually, you did not respond to what parent said. How is the standardization process related to joining the network?
Look at how ActivityPub works before saying it's single vendor controlled.
Really basically: Everyone can have their data (posts, media attachments) on whatever server they want or control, easily self hosted.
And at the same time, people can also host "apps" like Bluesky that read said data and interpret conventions in naming to show it in a meaningfull way like as posts.
you can self host your data.
you can self host a bluesky view.
It actually kind of reminds me of openstreetmap, where it's actually only a database of keys and values, but apps interpret their meanings based on conventions
This would be much better titled "Bluesky Acquires the AT Protocol Trademark"
Any word on which entity was trying to trademark it first?
You can see the original application here: https://tsdr.uspto.gov/documentviewer?caseId=sn97700166&docI...
Atsign, Inc. for this thing probably https://atsign.com/resources/white-papers/the-atprotocol/
I can’t imagine being a first time bootstrapped founder running a business without a trademark and not knowing that someone with bad faith would just register a trademark and just sue or order you to change your name.
These are the things that most startups account for when raising capital.
The community probably would have complained if they registered the trademark preemptively. But if they let the bad guys register it and then save the day it's the least bad solution.
The timeline just seems like two different brands wanted the name. atSign was using atProtocol as their thing. And trademarks are defend-or-lose. That AT Proto would grow so much more than atSign is just a thing we know now. They were both contemporaneous and it doesn't seem to have been some kind of gazumping operation so much as two groups landing on a name.
Yeah, the much more common scenario with startups is exactly what happened here:
1. you choose a name for your product, start using it
2. you try registering it as your business starts to materialize
3. "oh shit we weren't the only ones who picked that name"
[flagged]
[flagged]
Thank god!
Who? What?
Interesting, I believe that's a pretty good move from them.