TIL about the Herfindahl–Hirschman Index and I wanted to test it with a weird corner-case that I remember.
At one point in the late 1980's Microsoft had a GREATER than 100% market share of the Macintosh spreadsheet market.
How is this possible?
Market share (for a given period) is the participant's sales in the market divided by total sales. It just so happened that Lotus had more returns than sales of their failed spreadsheet, Lotus Jazz. So Lotus, had a negative market share and Microsoft had more sales of Excel than total sales in the market, resulting in a greater than 100% market share.
I don't remember the exact numbers and I believe there was at least one other competitor in the study. But let's just say the numbers were:
Microsoft: 102%
Lotus: -2%
In that case the Herfindahl–Hirschman Index would be 102^2 + (-2)^2 = 10404 + 4 = 10408.
So, in this pathological case it is possible for the HHI to exceed 10,000.
Edited: Added (for a given period) above, for clarity.
I have diligently searched for this article online and have been unable to find it. (It might be on microfiche somewhere...)
I did however, find this humorous anecdote:
> A Lotus executive later joked, "The first month we shipped 62,000 copies, and the following month we got 64,000 copies back. It was such a failure they sent us the bootlegged copies back."
That's not a thing. Market share has no time period. It's an instantaneous measure of the state of things right now. How many of your company's units are out in the wild right now being used, vs. how many total units (sold by any company) are out there in the wild right now being used.
That number can and will be different at different points of time, as people buy and return your products, and buy and return your competitors' products[0]. You can certainly say that your market share increased by 300% or by -40% over a given period of time, but your actual market share is always a number between 0% and 100%.
> Market share (for a given period) is the participant's sales in the market divided by total sales.
No, that's a company's share of sales as compared to the industry/product category as a whole. Not market share.
[0] You also should take into account people who throw your product in the trash (or for software, delete it) without returning it. Depending on context, you might even want to take into account people who put your product in a box in their basement and never use it again. Assuming you could actually divine those numbers, which of course you likely can't.
There are multiple methods of measuring multiple (related) things. What you are describing sounds more like the share of the installed base, which only works for certain types of products. (i.e. it doesn't work for consumables like apples or electricity)
It gets really interesting when you look at the precinct and county level in the US, and similar types of views in European countries where they do real representative government.
It's ironic that national level politics mirrors the kind that the founding fathers did not ever want happening, while local politics has the kind of representation that they actually had in mind (in most places).
Neat! I'm not surprised at the findings here. BlueSky (for the average user) is pretty much a drop in replacement for Twitter.
Despite the smaller total numbers in Mastadon, it's great to see that the ecosystem seems to be successfully avoiding centralization like we've seen in the AT-Proto ecosystem.
I suspect that the cost of running AT proto servers/relays is prohibitive for smaller players compared to a Mastadon server selectively syndicating with a few peers, but I say this with only a vague understanding of the internals of both of these ecosystems.
Running a PDS server for yourself and a few friends is not very expensive afaik, but there's also not much benefit to doing so, because the point of the PDS is to have a clean separation between your own data and the rest of the network.
The expensive things in ATProto are the Relay (crawls/listens to PDSs to produce the firehose) and the AppView (keeps a DB of all posts/likes/etc to serve users' requests). Expensive at scale anyway; if you want your own small network for hosting non-Bluesky posts (like WhiteWind's longer character limit), the event volume will be manageable.
For a lot of stuff though ATProto is built in a way that you shouldn't have to host your own; you can implement your own algorithmic feed that reads from the Bluesky Relay's firehose, or your own frontend that still gets data from the Bluesky AppView.
> For a lot of stuff though ATProto is built in a way that you shouldn't have to host your own; you can implement your own algorithmic feed that reads from the Bluesky Relay's firehose, or your own frontend that still gets data from the Bluesky AppView.
ATProto isn't "built this way".
Twitter was also built in a way where you could implement your own stuff - and then Twitter took that away.
With Mastodon, there is one large instance (controlled by the non-profit Mastodon gGmbH). If they tried closing themselves off, their users would be losing access to the majority of people in the network. Plus, while non-profits aren't perfect, they don't have VC investors to answer to.
Bluesky could decide to stop publishing the firehose or restrict its APIs - just as Twitter did. Given that they control 99.55% of the network, they can close it off without worrying about their users losing access to anything. And Bluesky is a for-profit company that has raised around $30M in VC.
What you talk about isn't a feature of ATProto. It's a feature of being centralized and having a company willing to let you use their servers for free (at least for now). This was the case with Twitter for a long time. You could read the Twitter firehose and build your own apps and frontends getting data from the Twitter APIs - just as you can do from Bluesky today.
But unless there's a reason why shutting off the firehose/APIs would be bad for Bluesky, they can do that at anytime. It might anger some users (as Reddit and Twitter both did), but they control the network and network effects are powerful. For most Bluesky users, they'd continue using it because they aren't there for some open protocol. They're on Bluesky because Twitter became a nazi bar. Until we see real decentralization with ATProto, it's just a centralized network like Twitter or Reddit which hasn't shut off its firehose and public API yet. Hopefully that won't happen, but it certainly could.
ATProto is built this way. "Closing off bluesky" would be an extraordinarily non-trivial process and would break basically everything. This is in large part why private data isn't a thing yet. The architecture is diametrically opposed to it.
> Bluesky could decide to stop publishing the firehose or restrict its APIs - just as Twitter did.
They could "technically" completely rearchitect their application frontend and backend to do this but any effort to do so would be visible from miles away given the architecture and warning claxons would start ringing immediately.
> And Bluesky is a for-profit company that has raised around $30M in VC.
Bluesky PBLLC is a for-profit "public benefit corporation" for what it's worth and the way they are structured would open them up to legal consequences if they were to move diametrically opposed to the mission they were founded on. Not just because they are a PBLLC but because their initial investment funding was drawn up under an explicit contract that views moves against "the development of decentralised social media" as a violation of the terms of that contract.
No I think ATProto is "built this way". The firehose is just the output of the Relay. If Bluesky wanted to shut off the firehose, they would have to make changes to ATProto or stop conforming to ATProto.
I understand that Bluesky's conformance to ATProto is just a promise, but it's a better promise than you get from most websites. Also in the meantime, if you migrate to a self-hosted PDS, you can ensure that even if Bluesky restricts access to their Relay's firehose, 3rd party Relay servers can still pick up your posts and publish their own unrestricted firehose.
What do you think would happen if the Bluesky company suddenly blocked everyone but https://bsky.app/ servers from using their relays?
And what if, before they did that, they updated the PDS code so it blocked all relays except for their one?
I'm not asking what you would do. I'm asking what would happen because of what everyone does. I think the name "Bluesky" would refer to the fully centralized bsky.app, and 99.9% of users would never notice a difference. Users who had other PDSes would either quit (nobody noticing their departure) or sign up to bsky.app like everyone else. The events of Twitter show it's probably the latter - people bent over backwards to comply with Musk to keep their accounts.
> What do you think would happen if the Bluesky company suddenly blocked everyone but https://bsky.app/ servers from using their relays?
That's not how it works. Appviews pick the relay they use, not the client/user. The relay is used for gossip into the appview (and other things).
More importantly, appviews never see the client/user directly. Appviews only talk to the PDS. Really most things other than the client ever only talk to the PDS or listen to the relay. The only thing that ever directly talks to the client is the PDS.
The way atproto services generally work is the client configures a series of XRPC requests with HTTP headers to determine what appview, labelers, etc to use and it issues that request to the PDS. The PDS then proxies that request to the appview or wherever and they respond back to the PDS which routes the response back to you.
So in a real sense your PDS is not just a data host, but also operates akin to an IRC bouncer.
-----
> And what if, before they did that, they updated the PDS code so it blocked all relays except for their one?
PDS relay routing, etc is mostly all handled manually via config files,etc so this isn't really a concern. And PDS code is probably the "easiest" part of the ecosystem to hack on which is why there are like 6 different implementations with the majority (like 4) that maintain near feature parity with the "bluesky PDS" software.
And importantly, the bluesky PDS is literally a sqlite DB, an OAUTH implementation, some go IPLD data structure manipulation code, and a go XRPC router. It's fairly trivial to hack on as needed.
------
> I'm not asking what you would do. I'm asking what would happen because of what everyone does. I think the name "Bluesky" would refer to the fully centralized bsky.app [...]
Migration currently isn't perfect but within ~6 months it should be ironed out by the community at which point migrating off a PDS to another is just a matter of:
1. click button on new PDS to transfer/"create new account".
2. set your new email, password, and list your old/current handle.
3. get auth code via email (one from the new PDS and one from your DID provider)
4. input codes into migrator interface (for whichever migrator you are using)
5. log into your apps again.
There are multiple large PDS operators working really really hard to spin up operations (proper backups, failover, HA, etc) so they can run reliably and avoid the "my mastodon instance imploded guess everything is gone" issue. Open federation is only about ~ a year old (plus change) so the community is only just now really reaching the "mature third parties" stage.
First of all, Bluesky the company would have to implement auth on the communication between relay and AppView, cut off everyone from using their relay, and specifically stop ingesting content from non-Bluesky PDSs. There would be time when we realize that's happening to get another AppView up and running. There are arguably enough resources in either the ATproto dev community or other funding sources that another AppView could pop up within a week or two, and be maintained by the community for months without issue. And Bluesky wouldn't likely stop existing altogether, so people would log into Bluesky, see the news (or hear it elsewhere), and see people talking about how to get access to your account.
Secondly, while you're right that most people don't have copies of their repos, some copies of the entire network exist in the community, as well as copies of the PLC Directory. Within a couple weeks we would have community run versions of the AppView, PDSs, Relays, and PLC, and some seriously pissed off community members who would now want to do everything they can to take up the mantle temporarily. Soon Bluesky the app, as well as Instagram and Twitter, would be flooded with tutorials of how to recover your accounts and migrate to another PDS.
If your point is that we'd lose at least half of the users of Bluesky, then yea probably. But ATproto would be just fine, and if people want to get their data back they likely can, as long as they can stomach a little work. And that process is getting easier all the time.
Who would use the new network? It would just be Mastodon Vs Twitter again. All the people you want to read the tweets of would (still) be on Blue Sky, not Black Sky or Red Sky or President Zelen Sky or whatever.
"Convince a HN user that a corporation with the ability to cut you off from your feed sources for more profit won't do exactly that and just because they use something decentralised-ish today doesn't mean they have to keep using that thing if they don't want to" challenge (difficulty: impossible)
> "Convince a HN user that a corporation with the ability to cut you off from your feed sources for more profit won't do exactly that
It's not just a technical restriction though. It's also a legal restriction. Bluesky PBLLC is a public benefit corporation and they are at least in moderate part beholden to their charter.
More importantly, their initial investment contract requires them to further the decentralisation of social media and exposes them to legal consequences should they deviate from that mission.
Those combined make it effectively impossible for them to lock in bluesky. Doing so would require technical changes that would be under no uncertain terms against the charter of the company and against the terms of the investment contracts that initially funded the company. It's a poison pill that would kill the company and destroy any "shareholder value" the moment they try to lock down the service or lock in the users.
You aren't going to see them try this type of brazen lock-in because it'd be explicitly harmful to every investor/VC and saddle the company in legal hell until it smoulders into ash.
OpenAI managed to escape its nonprofit status, becoming incredibly closed and self-serving. There's no reason to expect any other VC-funded nonprofit won't do the same.
Sure they may. And the moment they try to it'll signal to the entire ecosystem what is coming, giving us time to migrate people off to third parties and batten down the hatches. A change like that never happens overnight.
Why didn't everyone abandon Twitter for Mastodon when Elon bought it? Why didn't they even abandon it for Blue Sky until years later? Why is Twitter still as busy as it was when Elon took it over?
Because it requires a new account. Migrating PDS on bluesky does not require a new account, is invisible/transparent to your followers and following, and the end goal is that migration will be easy enough that you can do it in less than 5 minutes with no technical skill.
Bluesky/atproto is still very early/very young but the general theme is to focus on the UX and ergonomics to make decentralisation viable without forcing the user to be technical enough to care about it.
i.e. The end goal is that people should be able to say "fuck bluesky", click a button, wait for a loading bar to finish, and continue using bluesky without using bluesky PBLLC stuff.
To be clear we are not at this point yet and bluesky PBLLC is not suddenly hostile yet either. Triage is in order of priorities so some more important UX aspects are being handled first.
My personal prediction is that this should be a solved problem within less than a year but of course we'll see.
No. That's just not remotely close to true or feasible.
> So, you're making stuff up that obviously has no basis in reality here.
I cannot understand why you are claiming this. I'm basing off the actual architecture and the way the parts interact. The design is just not feasible for locking down. Doing so completely breaks the model and it still leaks like a sieve if you try to.
----------
> Migration would be impossible because the bsky.app PDS wouldn't allow anyone to access the data except for the bsky.app relay.
Nope. Migration is still fully possible. Migration doesn't happen via the relay or any PDS->PDS mechanism. Migration is done via the client. The client/user runs operations on the source PDS, the destination PDS, and the DID registry. All the data is transported between by the client.
Specifically the way it works is you export/backup your information from your current PDS (in the form of a CAR file + blobs). Technically this step is optional. Even if the PDS goes offline or becomes hostile you can actually largely reconstruct this data from the network. Then you "create a new account" on the new PDS and upload your data that you backup up/recovered onto the new PDS. Then you update your DID to point to the new PDS. And finally you deactivate the account on the original PDS (basically saying I no longer store stuff here anymore).
This is part of the reason why migration tooling is a bit bumpy. Your JS script or app has to do the entire process by itself rather than letting the backends handle it. However it does make them extraordinarily resistant to data loss and/or takeover.
----------
> other appviews wouldn't display bsky.app data because both the PDS and relay would block them.
Relays work via gossip. If you can see the relay at any point, you can gossip 100% of their contents to another relay.
In the event bluesky PBLLC locked down their appview and PDS, they'd still have to make the relay open or everything breaks. Feed providers need access to the firehose. Labelers/Moderation Services need access to the firehose. And so on.
Everything is built with an assumption of a public firehose and if you lock down the firehose, all you need is one person to listen to the locked down firehose to 100% replicate it and gossip onto any other relay.
Running a relay is not expensive anymore (it used to be), with recent changes it's about $30/mo. Running an AppView that ingests all ongoing Bluesky traffic (and puts it into database) is more expensive ($300/mo currently) but if you were happy with a partial view of the network, you could get it down by a lot.
$30/mo is $360/yr, which for most people is a prohibitively large sum of money. That would make Bluesky access more expensive than even the most expensive Netflix subscription; closer to the cost of a cellular plan.
For comparison: for my Mastodon account I pay $5/mo or $60/yr to a dedicated hosting provider. This puts it in the same ballpark as paying for a private email host or a VPN subscription.
This makes sense, but a Relay isn't something you'd expect a normal user to run.
It doesn't meaningfully make you "more independent" because all Relays are trivial (they're just dumb re-broadcasters of a stream) and it makes sense to use one run by somebody else — a company or a community that's pooling resources.
Aren't the entities who manage relays the ones who broker access to the network? E.g. if you subscribe to a relay, you must also subscribe to their moderation decisions.
Say if Bluesky (the company) bans someone, that person could still have the keys to their data, but their feeds will no longer be "re-broadcast" by that company's servers - right?
Relays aren't really user-facing, so most relay operators would probably only censor a user on the relay if there is some legal or network reason to do so, say content illegal in their jurisdiction or excessive spam.
If an app is concerned that a relay is censoring some user that they care about, the easiest solution is just to host their own relay. It's probably cheaper to operate than their app is. But if they really wanted to, they could listen to multiple relays to "cover the gap" or just manually listen to the event stream from specific users' PDSs directly whenever they notice censorship (effectively operating a partial relay in addition to listening to a full but censored one). But, again, in reality they'd just host their own relay and not bother complicating things.
The hardest problem of relays censoring content is to notice it happening, but once you notice you can easily verify it and switch to a different relay.
The PDS is closer to the Mastodon account and will run you the same amount of money. The relay or appview is what takes the load when one of your posts goes viral, whereas in mastadon your $5 VPs has to handle that spike in traffic. Been several a story about how AP has DDoS'd a small server because there is no equivalent to the relay
I thought only the way to avoiding the full firehose was connecting to Bluesky's centralized Jetstream instances, and that if anyone else wanted to host Jetstream without depending on Bluesky infra other than the PDS, they would still need to pay the full price for the firehose bandwidth and storage.
If you want to avoid the entire bandwidth of the firehose, you need something like jetstream (at least until something like sharded relays come around).
However the relay gossip protocol is not as taxing as it used to be. Relay Sync 1.1 massively decreased overhead and it allows relays to run "thin", i.e. running with only a certain backlog of history and not carrying the full history of the network. So you can make a relay that only keeps 24 hours of history and it'll perpetually stay under like 100gb of storage (I don't remember the exact storage amount but storage size is pretty linear with backlog history).
I'm admittedly not versed in the AT protocol, but $30/month is high for me. Something like $10/month is quite fair, and i would expect should be more than enough for a VPS to host my and 2 other members of my family for any social network service...This $10/month is overkill for other servers on the ActivityPub via say gotosocial, pleroma, etc. Not that ActivityPub is perfect or anything like that, i just mean that $30/month is not yet what i would call a sweet spot for self-hosting something...but of course, that is absolutely leagues better than any cost that the bluesky team or other bigger players would naturally have to pay for ongoing infra., etc.
Then again, i will not deny that there's also the possibility that i am simply cheap! :-)
Right, but a Relay is literally a network-wide optimization. That's why in my other comment I'm mentioning that it's hard to do apples-to-apples comparison. With Mastodon, you only have one possible role: "hosting an instance" (which is like hosting a mini-Twitter with almost no data). ATProto aims higher in terms of UX (shared world by default) so there are different distributable pieces with different incentives to run. Anyone can self-host a PDS for super cheap (which will store only your data). But running a Relay is useful as an optimization for whoever's running the actual backends. So if you're a company building on ATProto, maybe you run your own Relay just in case (or maybe you don't and reuse an existing one). Or if you're a collective of people, maybe you pool resources together to run your own independent Relay. It's not something you'd just run for yourself unless you're a huge enthusiast.
Bluesky's architecture was pretty much dictated by the premise that anyone needs to be able to see any post on the entire system, regardless of whether they have any connections with the author. That algorithmic entertainment-style feeds need to exist. You do need that firehose and other expensive infrastructure for that, there's no going around it.
The fediverse, on the other hand, entirely relies on people following each other. Each server only receives and stores data that is relevant to its users. ActivityPub works like an automated email list management system. You follow someone, they start sending you their updates and forwarding any updates from others that they consider relevant, like replies to their posts.
> Bluesky's architecture was pretty much dictated by the premise that anyone needs to be able to see any post on the entire system, regardless of whether they have any connections with the author. That algorithmic entertainment-style feeds need to exist. You do need that firehose and other expensive infrastructure for that, there's no going around it.
Exactly this (that people want it at least - I don't think that means it needs to exist). And I think there would be a lot less frustration in the discourse of ActivityPub vs. ATproto, if we could collectively agree that you can't get this in a decentralized system. In a dense network, the number of edges scales with the square of the number of nodes. It's just not feasible to have a network that is both dense and has a large number of nodes.
I think "I prioritize virality, recommendation engines and network density, thus accept giving control over the network to a centralized and profit-oriented entity" is an entirely reasonable tradeoff to make. I just don't understand why BlueSky users don't seem to accept that it's the tradeoff they are making.
absolutely. it’s even in the design paper, when they discuss the AppView the authors say it’s “less decentralized than alternatives” and yet you can’t say that without bsky fans getting mad.
I think the Twitter format sucks in both cases, but having central, algorithmically-curated feeds are just bad for people psychologically. They just created another Twitter clone with the same problems. The only difference is fewer "nazis".
> BlueSky (for the average user) is pretty much a drop in replacement for Twitter.
One reason Bluesky is so successful is because it doesn't shove decentralisation into the user's face like Mastodon does. The vast majority of people don't know what decentralisation is and don't care to.
I think that far too much effort is put into decentralisation and not enough into good moderation on these platforms.
I don't use Mastodon because it's too decentralized.
What I mean is I own my own domains but I can't use them on Mastodon without self hosting an entire Mastodon server for one user per domain. Yes there are other implementations of the protocol but none really solve this well in a cheap to run way.
Mastodon's missing feature is identity portability. A user with their own domain should be able to easily use a larger instance to host their identities and be able to migrate them to another instance.
There are also significant practical user experience differences.
Doing a search on Twitter searches Twitter, the whole thing. A search on Mastodon only knows about the servers you're connected to (unless you're searching for a specific user, then it'll micro-target their server to get their account info, but you have to know their name through some side-channel. Similarly, if you chance across a Mastodon post and want to follow that user, unless you happen to be on the same node as them you have to enter your own node data to get redirected to do the follow because of the domain-based nature of web security.
These aren't deal-breakers but we have the hard numbers from other web UX to know that every time you put a friction point like these in the flow, you immediately lose some x% of users. Relative to services that are centralized, these things will slow Mastodon adoption.
(This may not be the worst thing. There are other goals besides maximizing the adoption numbers.)
They pivoted into that when Mastodon blew up in Japan, German authorities got involved, and its benevolent dictator Eugen Rochko felt need to distance himself from Japanese for his own safety. German police, especially parts of its federal counter-terrorism swat units(?) seem to have odd fixations with anime and take great offense with those contents for some reason.
They can roll that back, or push moderation angle more, but they won't be able to do so without also come forward with the fact that East Asia is producing substantially more amount overall and on average higher quality content incompatible with Western moderation. Those realities won't be popular anyway.
https://roost.tools is working on open-source options for both social (fedi or not) and beyond social. Generally the idea is that we can fight the bad things better if we are working together instead of independently
ATProto's Stacked Moderation is an interesting approach to combine platform, community, and user level choices
I'm curious if you could expand on this observation? I've heard this from other Mastodon users but I haven't seen it myself; I wonder if it varies heavily from server to server or if I've just gotten lucky.
Moderation (the intent and success) varies to such a huge extent that it's practically silly to talk about moderation on Mastodon unless you mean moderation on a specific mastodon server (like mastodon.social). But moderation (the process) is intense and servers are usually community run on the change found in a spare couch (i.e. they're volunteers).
I think they do quite well considering the disparate resource levels, but some servers are effectively unmoderated while others are very comfortable; plenty are racist or other types of bigot friendly, but the infrastructure for server-level blocks is ad-hoc. Yet it still seems to work better than you'd guess.
Decentralization means whomever runs the server could be great, could just not be good at running a server, could be a religious fundamentalist, a literal cop, a literal communist, a literal nazi, etc etc. And all have different ideas of what needs moderating. There is no mechanism to enforce that "fediverse wide" other than ad-hoc efforts on top of the system.
Thank you for the clarification; that makes sense.
It is perhaps also worth noting that the Fediverse architecture does nothing to remove racists or bigots from the possibility of being found in the "fediverse" (here referring to the collection of all servers using the protocol and not the protocol itself), and... That's pretty much as-intended. Truth Social uses Mastodon as its backend; there is nothing the creators / maintainers of Mastodon could, or by design would, do to shut it off. The same architecture that makes it fundamentally impossible for Nazis to shut down a gay-friendly node makes it impossible for other people to shut down a Nazi node; there is merely the ability of each node to shield its users from the other.
That's a feature of the experiment, not a bug, and reasonable people have various opinions on that aspect of it.
What even is "moderation" at this point? I'm not sure this word is used as defined on paper dictionaries. It is a codeword for something else, like censorship or influencing or artificial control of public opinion?
Because, if it's purely about filtering out content not desired by users, it could be nearly trivially done at the edge, automatic and completely de-humanized, and the word as appearing lately doesn't read that way to me.
I get where you're coming from, and I have largely the same sentiment, but it's obvious that you've never had any experience running a platform, or using one with no/few rules. You need baseline moderation, even if it isn't super ideological. You've got to keep pedophiles and misanthropes out at the very least.
Sounds like I really should be building one with the AI moderation I have in mind. I kind of have been to random deep ends. Most of them can't be that hard to filter out or steer them away from undesired content, especially in this age of AI...
ATProto also has the downside of being supported by a corporation and investors with various backgrounds that will eventually want to earn something out of it all and there is no telling how this will happen.
There are lots of ways they could make a sustainable income without disrupting Bluesky's current status quo and be comfortably rich for the rest of their lives... but that's completely out of character for them and will never happen. I do think the geeks currently running Bluesky are sincere in keeping it decentralized, but the money people will someday probably force them out and squeeze the user base for a quick buck. A hardcore nerd minority will splinter off, though, and keep the decentralized version running, so whatever. History repeats. Frog swims, scorpion stings.
>There are lots of ways they could make a sustainable income without disrupting Bluesky's current status quo and be comfortably rich for the rest of their lives... but that's completely out of character for them and will never happen.
I meant "quick buck" like flooding the place with ads, tracking, dark patterns, closing the API/protocol, or doing some sort of crypto scam, with no regard for the platform's long-term health. It's been funded for a few years? That's not really that long for such a small team. But I have no idea how their investors think it might make "Facebook money", and isn't that always the goal?
If you have a sudden massive change in plans like this, it resets the timer. You were doing long term, but now you want a quick buck and you don't care much if the company survives.
If I set up a get rich quick scheme based on overhyping and selling land, it doesn't matter whether I buy the land today or it's land I had for decades for a completely different reason. Either way I'm going for a quick buck now.
But they didn't have this for completely different reasons. They invested money years ago, that they could've bought government bonds with and just earned interest, and instead it went into BlueSky. At some point they'd like a return that would substantially beat the government bond they could've invested in with zero risk.
Off the top of my head: Paid hosting/services on top of the protocol, reddit-gold style tipping and gamification, being a transactional middleman (there are a lot of artists selling things, famous people promoting things, and so on), promoted posts and ads (easily blockable, but some users wouldn't bother).
Bluesky is a small team of like ~30 people, if they keep running lean they have at least a chance of a decent profit margin. But none of that will make anyone a multi-billionaire, so never mind.
I think you are wildly overestimating the user's willingness to pay online, and underestimating the costs to run a large scale site. Even if you remove developer's salaries and server costs, the fines could be worth 10s of millions of dollar per country just for delay in removal of hate speech[1].
For consumers, plenty of ads and plenty of tracking. For businesses, heavily-restricted user-to-server APIs and features gated behind subscriptions, think custom domains with Bsky hosting, multi-user post approvals, integrating DMs with customer support systems etc.
You can do all of that while still being fair to and interoperable with the rest of the ecosystem. As long as you don't want the convenience, features and UI of Gmail, you can still communicate with Gmail users from any other provider, and the same could be true about Bsky.
This is true but it's worth noting that (1) the entire point of this node is to be globally agreed on since it's the root of the identity mechanism, (2) it is auditable (https://github.com/did-method-plc/did-method-plc?tab=readme-...) and operations themselves are self-certifying (https://github.com/did-method-plc/did-method-plc?tab=readme-...). There are some potential issues (like PLC could choose to deny some operations), and the plan is to upstream PLC into an independent entity so that it isn't tied to Bluesky the company.
Anything that is funded by venture capital WILL become worse. You can complain all you want about things that don't have infinite funding having issues, but they'll probably just stay at the same level or get slightly better over time. VC-backend companies only get worse after their early peak.
>I suspect that the cost of running AT proto servers/relays is prohibitive for smaller players compared to a Mastadon server selectively syndicating with a few peers, but I say this with only a vague understanding of the internals of both of these ecosystems.
This isn't quite right. ATProto has a completely different "shape" so it's hard to make apples-to-apples comparison.
Roughly speaking, you can think of Mastodon as a bunch of little independently hosted copies of Twitter that "email" (loosely speaking) each other to propagate information that isn't on your server. So it's cheap to run a server for a bunch of friends but it's cut off from what's happening in the world. Your identity is tied to your server (that's your webapp), and when you want to follow someone on another server, your server essentially asks that other server to send stuff to yours. This means that by default your view of the network is extremely fragmented — replies, threads, like counts are all desynchronized and partial[1] depending on which server you're looking from and which information is being forwarded to it.
ATProto, on the other hand, is designed with a goal of actually being competitive with centralized services. This means that it's partitioned differently – it's not "many Twitters talking to each other" which is Mastodon's model. Instead, in ATProto, there is a separation of concerns: you have swappable hosting (your hosting is the source of truth for your data like posts, likes, follows, etc) and you have applications (which aggregate data from the former). This might remind you of traditional web: it's like every social media user posts JSON to "their own website" (i.e. hosting) while apps aggregate all that data, similar to how Google Reader might aggregate RSS. As a result, in ATProto, the default behavior is that everyone operates with a shared view of the world — you always see all replies, all comments, all likes are counted, etc. It's not partial by default.
With this difference in mind, "decentralizing" ATProto is sort of multidimensional. In Mastodon, the only primitive is an "instance" — i.e. an entire Twitter-like webapp you can host for your users. But in ATProto, there are multiple decentralized primitives:
- PDS (personal data hosting) is application-agnostic data store. Bluesky's implementation is open source (it uses sqlite database per user). There are also alternative implementations for the same protocol. Bluesky the company does operate the largest ones. However, running a PDS for yourself is extremely cheap (like maybe $1/mo?). It's basically just a structured KV JSON storage organized as a Merkle tree. A bit like Git hosting.
- AppViews are actual "application backends". Bluesky operates the bsky.app appview, i.e. what people know as the Bluesky app. Importantly, in ATProto, there is no reason for everyone to run their own AppView. You can run one (and it costs about $300/mo to run a Bluesky AppView ingesting all data currently on the network in real time if you want to do that). Of course, if you were happy with tradeoffs chosen by Mastodon (partial view of the network, you only see what your servers' users follow), you could run that for a lot cheaper — so that's why I'm saying it's not apples-to-apples. ATProto makes it easy to have an actually cohesive experience on the network but the costs are usually being compared with fragmented experience of Mastodon. ATProto can scale down to Mastodon-like UX (with Mastodon-like costs) but it's just not very appealing when you can have the real thing.
- Relays are things "in between" PDS's and AppViews. Essentially a Relay is just an optimization to avoid many-to-many connections between AppViews and PDS's. A Relay just rebroadcasts updates from all PDS's as a single stream (that AppViews can subscribe to). Running a Relay used to be expensive but it got a lot cheaper since "Sync 1.1" (when a change in protocol allowed Relays to be non-archiving). Now it costs about $30/mo to run a Relay.
So all in all, running PDSs and Relays is cheap. Running full AppViews is more expensive but there's simply no equivalent to that in the Mastodon world because Mastodon is always fragmented[1]. And running a partial AppView (comparable to Mastodon behavior) should be much, much cheaper — but also not very appealing so I don't know anyone who's actually doing that. (It would also require adding a bit of code to filter out the stuff you don't care about.)
[1] Mastodon is adding a workaround for this with on-demand fetching, see https://news.ycombinator.com/item?id=45078133 for my questions about that; in any case, this is limited by what you can do on-demand in a pull-based decentralized system.
> You can run one (and it costs about $300/mo to run a Bluesky AppView ingesting all data currently on the network in real time if you want to do that).
A clarifying question: the blog post [0] I found about zeppelin.social which I think is a full AppView, the author said this:
"The cost to run this is about US $200/mo, primarily due to the 16 terabytes of storage it currrently uses"
Last I heard the amount of storage was just a couple of terabytes so the growth seems to be very fast.
If and when the primary cost is the storage, IMO the crucial question is: what's the expected future cost of running community AppViews?
Because unless storage cost drops as fast as the BlueSky data grows (unlikely?), to me this architecture looks like it will very soon kick out smaller players and leave only BlueSky with enough money to keep the AppView running.
I can’t speak to how fast it grows and what it was, but I mean — if what you want is to keep the entire data of the network (similar to having all tweets on Twitter) ready to be queried then you have to store them. That’s just unavoidable in any technological solution. Alternatively you could hydrate and query posts on-demand from their sources (PDS), and people have done that as an experiment, but you need at least some aggregation to happen somewhere (for reconstructing reply lists or like lists etc). If more collectively-run network caches are available, this becomes more feasible without storing everything yourself.
In any case, if you’re okay with a partial snapshot of the network (eg all posts during some window or even more partial) then you can arbitrarily narrow that down. In Mastodon, having a “full” archive is downright impossible which is why we’re not talking about the same with regards to Mastodon. Whereas ATProto makes it possible, with the cost being the floor of what you’d expect the cost for storing data to be. How could it be better?
> if what you want is to keep the entire data of the network (similar to having all tweets on Twitter) ready to be queried then you have to store them.
They need to be stored, but do they technically have to be stored by just one AppView? I get that it's a 100x easier to implement it like that, but I don't think a distributed search would've been technically impossible (although, granted, necessarily it would have had worse UX).
Choosing this feature and then implementing it like they did was a technical choice. Technical choices have consequences and this, I think, was the one which will prevent BlueSky from reaching any meaningful decentralization.
And saying "you can create an inferior UX with affordable costs" is not a real answer. Any meaningful decentralization IMO can only happen if it's affordable to create feature identical nodes. That can only happen if you refuse to implement features in ways that need centralization to scale.
I’m not sure what choice you’re referring to here. Yes, simply loading data from the database is the most straightforward solution, and that’s what Bluesky itself did for its AppView. That’s kind of the default model in general in web development — and has nothing to do with decentralization. If you were running a centralized Twitter, storing the amount that Twitter stores would cost you exactly the same.
On the contrary, ATProto adds flexibility here. There are community-run projects like https://constellation.microcosm.blue/ that let small application builders avoid that burden. Of course you don’t want to overwhelm those by building a massive app on top. But the point is that ATProto starts with equivalent baseline to what you’d pay running a centralized service, and then gives you room to play with distribution of costs, potentially going all the way down to directly querying PDS’s on-demand or something in between like community-maintained caches or even potential third-party app-agnostic aggregation services. Eg you could imagine AWS, Vercel or Cloudflare building “app platforms” in five years that let you cheaply query shared data.
As for creating “identical” nodes, I think you hit the nail on the head — that’s not what ATProto aims to do. The insight is that it’s not useful or feasible for everyone to run their own copy of Twitter. But that it’s possible for everyone with “proportional interest” to run a “proportionally complete” part, with some of the costs being amortizable and poolable across many users and apps (thanks to shared infrastructure) and always individually replaceable (to avoid lock-in). This is strictly better than centralized.
> [1] Mastodon is adding a workaround for this with on-demand fetching, see https://news.ycombinator.com/item?id=45078133 for my questions about that; in any case, this is limited by what you can do on-demand in a pull-based decentralized system.
I'm not super up-to-date on Mastodon's/ActivityPub's workings, but aren't replies to a post pushed to the original poster's server? So wouldn't followers then be able to pull from that server at any time to get an always-up-to-date view of replies, at least theoretically? (With maybe posts from the last few seconds missing if the network's slow.)
(Asking because I've seen you claim that the architecture is inherently limited to never be able to achieve the "cohesive" experience.)
This only works for direct reply chains, right? It doesn’t provide a realtime view into all existing conversations that are happening on the post.
Imagine if, when you refreshed this HN page, only comment chains you’re already in would refresh timely. Yes, this would “work” to some extent, but it would clearly be a regression.
Additionally, going viral can overload your server due to this architecture. In ATProto this never happpens for self-fosters (of PDS) because the cost is amortized by AppView. (Same as in centralized products where the cost is on the backend.)
Ah gotcha, yes, indirect replies would need to be forwarded or something.
(To be honest, I'm already surprised that Mastodon scaled as far as it did. I will say, if I had seen the state of the web's architecture 20 years ago today, I probably also would have claimed that it was inherently insecure and that there was no way to get it to be secure enough to scale to billions of users, so... I don't know, maybe people will keep finding duct tape solutions to make it work, worse-is-better-style.)
>in what way can smaller players federate with ATProto or how the structure allows federation.
Each of the pieces I've described (PDS, Relay, AppView) implement the protocol specified at https://atproto.com/. Anything that acts as an ATProto PDS can be used as an ATProto PDS, anything that acts as an ATProto Relay can be used as an ATProto Relay, and so on. I'm not sure I understand the question so pardon the tautology.
The structure allows federation by design — a Relay will index any PDS that asks to be indexed; an AppView can choose the Relay it wants to get the data from (or skip a Relay completely and index PDS's directly); anyone can make their own AppView for an existing or a new app. That's how there are multiple AppViews (both for Bluesky app and for other ATProto apps) ingesting data via multiple Relays from many PDS's. There aren't many independent operators of each piece (especially outside of PDS self-hosting) but nothing is privileging Bluesky's infra.
Additionally, Bluesky's reference implementations of each piece are open source. So people run them the same way you would usually run software -- by putting it on a computer and exposing it to the internet. To run a custom PDS, you can either use the Docker container provided by Bluesky (https://github.com/bluesky-social/pds) or implement your own (e.g. https://github.com/blacksky-algorithms/rsky). Ditto for other pieces.
>Reading through it, it just sounds like sharding/scaling for a centralized service that's meant to be owned and provided by a single entity.
You're right in that the goal is to make it on par with centralized services in terms of UX and performance/scaling. However, it is decentralized.
I think what they are asking is: if I run a my own BlueSky AppView, how do I integrate with the bluesky.app so that users signed in on my AppView can interact with users on the the main AppView and vice versa? This is how most of us think about federalisation.
That's already the default behavior. You don't need to do anything special for that to work, it's what ATProto is designed for. Everything is always operating in a shared space by design.
When people "post", their posts go to their PDS's, which means that every AppView ingests data generated by every other AppView by default. There is no way to tell who's using which AppView — in fact, you can log into any AppView and your profile will be there with all your posts.
An appview is really just a service for hydrating content in the skeleton of posts that feeds return back to give to the user.
The only things they do other than feed hydration are track notifications, (optionally) provide a search engine, (optionally) provide a CDN, and (temporarily until E2EE rolls out) handle DMs.
So you can actually do things like the Red Dwarf [1] project which is a bluesky client without an appview. It's slower, you visibly notice request loading/pop-in, there's no notifications, and no search but it works with any other bluesky appview (since appviews are basically a lens into atproto rather than an independent service).
--------
If you wanted to run your own infrastructure, instead you'd probably want to run your own PDS. Running an appview has its benefits of course but the main way you "self host" is to run a PDS. That's fairly trivial and people have run them on all kinds of constrained hardware (including a literal jailbroken microwave if I remember correctly).
The AppView doesn't do that only for Bluesky data. It does it for any Personal Data Stores (user accounts with all their user data) that it knows about.
When you "interact" with users elsewhere, all you do is generate new records on your own PDS. You generate a "like" entry, or a reply, on your own PDS. It's your pds, all your stuff goes there. The AppView sees that and indexes it, attaches that like or that reply in the AppView to the post you're reacting to.
Other people can run AppViews too (that operate over the same or different data). There are just less people doing that than hosting Mastodon instances partly because it's much more expensive to, because some of the benefits of hosting a Mastodon instance can be obtained much cheaper through running a PDS server, and because AppViews doesn't serve the same exact social role that Mastodon instances do. (Mastodon has every instance be a semi-isolated community, so Mastodon instances are often made for the social purpose of running a semi-isolated community. Bluesky users expect a global timeline that's not partitioned by server instances, so it doesn't get many people running AppViews specifically for fostering semi-isolated communities. People on Bluesky who want to foster semi-isolated communities tend to use features like custom timelines to do so instead.)
When you write a post, you save it to your PDS. Think of it like writing a blog. You're done, you hit submit, it shows up on a server somewhere. You can run your own server with your own data, or use someone else's. That's exactly how a PDS works; it is a storage server for your data.
The AppView is a way to index all the PDSes registered across the whole network. If your server is crawlable by the AppView, all your data shows up in the app. This is like if your blog is crawlable by Google, you show up in search results.
When you like a post, you commit a "like" record to your personal server. When the AppView displays likes, it looks at every indexed PDS and shows every like it can find for that post (simplifying a little for clarity). Each one of those likes might live on different servers, some of which is self-hosted.
Because you can run your own PDS, you can commit any data you want to it. You can even commit things that services may find distasteful. However, the AppView may refuse to serve this content to users; this is how content can be removed from the network and how users can be banned. The federation equivalent would be defederation, except it happens to singular accounts rather than entire instances.
If you disagree with the moderation policies run by Bluesky the company, that's when you can look into running an alternative AppView. This is similar to disagreeing with the admin of a particular Mastodon instance and moving to a different instance. Of course, as mentioned running an AppView is much more expensive, but that hasn't stopped folks from trying (I believe Blacksky is trying to run their own AppView that is fully independent of Bluesky).
To use an alternate AppView, you'd simply go to a different website. This website will index PDSes the same way that Bluesky does, but it may index them in a different way and include/exclude different content. The data is still there (nobody can reach into your PDS on your server and delete your data), but the AppView admins choose which content they wish to serve to people using their community, just as Mastodon admins choose who to federate with.
In this sense, it is indeed truly federated. The primitives are simply different; it's more granular than Mastodon.
You can write your own content to your own server and let it get indexed to any number of AppViews; you completely control your personal data and nobody can reach in and delete that data randomly as they don't own it - you do (at the cost of ~$1/month or a Raspberry Pi).
When you use the Bluesky service, you are seeing their view of the network and what they choose to index. You may disagree with this view, just as you may disagree with the admins of Mastodon.social etc. In that case, you can choose to use another AppView (such as deer.social or Blacksky) that adopts different policies. Since account information isn't stored on the AppView and it simply handles indexing and moderation, moving between AppViews is painless and no data needs to be transferred from one server to another - you simply use a different bookmark.
It could be that you disagree with all the current AppView admins. You can host your own, it's just expensive ($300/month, as mentioned). You can also tailor your AppView to index less content, which will of course limit the amount of data you consume and give you a partial view of the network, effectively defederating you from anything you do not wish to index.
> Despite the smaller total numbers in Mastadon, it's great to see that the ecosystem seems to be successfully avoiding centralization
But since essentially no one is using it doesn’t suggest much avoidance of centralization. These factors are not independent. It’s pretty easy to avoid anything when your total user count is a rounding error compared to the alternatives.
Bluesky user count is the same order of magnitude as Mastodon and is centralized. I think your argument is actually that if you are on a minority platform your wants and needs for how that platform operates are irrelevant. I suppose that's true if you aren't on the platform, but I don't think it's true if you are.
So we are not decentralized. Git was a good attempt, but it kind of got centralized around GitHub, GitLab, and other variants. BitTorrent was decentralized, except tracker sites were the natural centralization points. Bitcoin was also decentralized, but still had Coinbase and other sites. Even SMTP is de facto centralized due to the spam problem.
> Even SMTP is de facto centralized due to the spam problem.
It's important to note that this isn't "you have to be big in order to be able to filter spam". That's not true at all; decentralized anti-spam lists have been a thing for decades and the big sites don't have any significant advantage in filtering spam.
It's allegedly that big sites will mark small sites as spam even when they're not, which makes it hard to run a small mail server. And there is some of that -- they also have a perverse incentive to do it on purpose because it kills their smaller competitors.
But it's also somewhat overstated. If you have a reverse DNS entry pointing back at your mail server and have properly configured DKIM, it's not inherently the case that you're always going to be marked as spam. And it's not inherently the case that you won't just because you use one of the big services -- they have the same incentive to do that to each other, after all.
Sure, but how many email users have a reverse DNS entry or even know what that is? DKIM? It is, de facto, beyond the reach of 99.9 % of all email users.
What? Most people are either incapable or unwilling to run their own mail servers. People could hack together their own social media or messaging sites in PHP, that doesn't mean Facebook and Twitter aren't centralized. That's what de facto means.
Git is decentralized in exactly the way it was intended to be. I do all my development on my own host. I collaborate with a lot of different remotes. Even when a project insists on using Github, I contribute by forking to my own host, push patches to the forge of my choice, and invite the maintainer to pull from there if they like. A lot of maintainers just mirror to Github and/or Gitlab.
Sure, a lot of people pick one center and stare at it. But there are plenty of centers and that situation is getting better recently. Some even integrate git with ATProto or ActivityPub.
There are loads of different tracker sites. Many private. If one goes bad, others pop up to replace it. This is decentralised - there is not one player that strangles the ecosystem.
Not to mention the mainline DHT. Not impossible or even very resource hungry to run a scraper/crawler/listener and be able to search via it, like bitmagnet (https://bitmagnet.io/) that has some fun pipe-dreams like federation of indexers and something like an decentralized private tracker.
Anyone can construct a service like Coinbase, and in fact there are numerous such sites available; at this point, you can even use PayPal! You don't even have to continue using the same one you started with: you can buy Bitcoin with PayPal and then sell it with Coinbase. It seems like a very strange definition of centralized to say that this causes any kind of centralization on Bitcoin...
The link back to the real world is money in your bank account. While Coinbase is not the only market player who can provide that (put money in your bank in exchange for bitcoin), it's the biggest, and so there is (to a degree) de facto centralization. More so given that if Coinbase fell (due to government seizure or similar), it's likely sibling services would fall as well.
Ofc, your bitcoin would still be "safe" and still be "yours" on the chain assuming you owned your wallets directly, but those guarantees would now lack meaning or real world consequences. At least until another link to the real world could be established.
But, Coinbase is not, actually, the biggest... not by far? Binance is like, 20x larger. And it isn't even as if you need to get dollars for your Bitcoin, in case the United States government decides to go aggro, so you can find someone in another country to convert you out through another currency. If this is our definition of centralized, then it is difficult to believe that anything is decentralized. There are enough numerous legitimate reasons to be angry at Bitcoin -- hell: even numerous legitimate reasons to say it is centralized -- that we shouldn't start making some up.
I was using Coinbase as a placeholder -- I am not up on current market share status but most people I know in the US use Coinbase. The point stands.
> so you can find someone in another country to convert you out through another currency
This is not so easy for large amounts -- the whole reason to use a Coinbase is institutional trust -- and is certainly inconvenient. In practical terms, across the ecosystem of users, it would not be some small roadbump but a massive problem.
And in many ways it actually is remarkably meaningfully decentralized - or perhaps "effectively" decentralized - in terms of every node having a full working copy of entire repositories that can be trivially cloned to another provider or stood up on a self-hosted server.
I’d say the opposite. Git is defacto centralized. And I’d go further and say that attempting decentralization is the biggest problem with Git. It maybe makes sense for Linux. But for 99.999% of projects it makes everything so much worse.
We're more decentralized in fedi but we're also not really consistent either. Which I think is the number one gripe for users who manage to get into the fedi.
I don't mind, I still think it's a huge leap forward, but it's important to set realistic expectations.
Not who you're replying to, but one issue is that different users will sometimes see a different subset of replies to a post, depending on what the server they're using has copied from other servers.
Yes but it's off by default for a reason, it's not realistic to expect every node to fetch all messages.
This is a catch 22 because the reason fedi is more decentralized is because of the low barrier of entry to run a node, but at the same time that low barrier means it takes less resources because it does not fetch every single message and piece of media.
In ATProto, there is no need to do this on-demand because the data is already there in the AppView. When you want to serve a page of replies, you read them from the database and serve them. There is no distributed fetching involved, no need to hit someone else's servers, no need to coalesce them or worry about limiting fetches, etc. This is why it works fine for threads without thousands of replies and hundreds of nesting levels. It can also be paginated on the server.
If you don't have this information on your server, how can you gracefully fetch thousands of replies from different servers and present a cohesive picture during a single request? I'm sure this PR does an attempt at that but I'm not sure this is a direct comparison because Mastodon can't avoid doing this on-demand. If we're comparing, it would be good to list the tradeoffs of Mastodon's implementation (and how it scales to deep threads) more explicitly.
I mean from the user's perspective: when I open a thread, I expect to instantly see the entire discussion happening across the entire network, with the paginated data coming back in a single roundtrip. Moreover, I expect every actor participating in the said discussion (wherever their data is stored) to see the same discussion as I do, with the same level of being "filled in", and in real time (each reply should immediately appear for each participant). It should be indistinguishable from UX of a centralized service where things happen instantly and are presented deterministically and universally (setting aside that centralized services abandoned these ideals in favor of personalization).
With ATProto, this is clearly achieved (by reading already indexed information from the database). How can you achieve this expectation in an architecture where there's no single source of truth and you have to query different sources for different pieces on demand in a worker? (To clarify, I did read the linked PR. I'm asking you because it seems obviously unachievable to me, so I'm hoping you'll acknowledge this isn't a 1:1 comparison in terms of user experience.)
To give a concrete example: is this really saying that replies will only be refreshed once in fifteen minutes[1]? The user expectation from centralized services is at most a few seconds.
I'm not very interested in arguing over the ins and outs of "user expectations" and Mastodon vs. Bluesky, sorry. I would suggest you try it yourself and come to your own conclusion about whether this is a usable system :^)
I'm arguing that "not really consistent" from the grandparent post still applies, and therefore your "this isn't correct" isn't correct.
For realtime discussions (like this one), I don't think we can call it consistent if it takes multiple minutes for each back-and-forth reply to propagate across instances in the best case (and potentially longer through multiple hops?) because you'll see different things depending on where you're looking and at which point in time.
In practice, this is rarely an issue due to the nature of human attention. Beyond a couple dozen speakers in a conversation, it's noise.
At least to my observation; I haven't pulled apart the protocol to know why: if you're in a conversation in Mastodon it's real good about keeping you in it. The threading of posts seems to route them properly to the host servers the conversing accounts live on.
And yet I could have a realtime public threaded conversation on Twitter, and am having one on Bluesky (regardless of which PDSs or AppViews other people are using), but cannot in principle have on Mastodon (unless everyone I talk to shares my instance). Does this say anything about relative ability of ATProto vs ActivityPub to meaningfully compete with centralized services?
I hear your point that slower conversation can be better. That’s a product decision though. Would you intentionally slow down HN so that our comments don’t appear immediately? You could certainly justify it as a product decision but there’s a fine line between saying you should be able to make such decisions in your product, and your technology forcing you to make such decisions due to its inability to provide a distributed-but-global-and-realtime view of the network.
I'm not sure where you reached the conclusion that you can't have a realtime public threaded conversation on Mastodon; I do it frequently. The way it generally works is that clients will auto-at-tag people in the conversation, which makes sure the message is routed to all in the conversation within more-or-less milliseconds.
Auto-at-tagging doesn't scale to dozens and dozens of actively-engaged speakers, but neither does human attention, so that's not a problem that needs to be solved.
I realize that we might be arguing over definitions here, but to me part of the experience of Twitter-like conversation is seeing other replies appear in real time even when they’re not directed at me — same as how you’ve noticed this thread on HN.
Seeing the existing convo in real time lets me decide which points to engage with and which have been explored, and to navigate between branches as they evolve in real time (some of which my friends participate in). I do earnestly navigate hundreds of times within an active thread — maybe it’s not your usage pattern but some of us do enjoy a realtime conversation with dozens of people (or at least observing one). There’s also something to the fact that I know others will observe the same consistent conversation state at the time I’m observing it.
You might not consider such an experience important to a product you’re designing, but you’re clearly taking a technological limitation and inventing a product justification to it. If Mastodon didn’t already have this peculiarity, you wouldn’t be discussing it since replies appearing in realtime would just seem normal.
In either case, whether you see it as a problem to be solved or not, it is a meaningful difference in the experiences of Twitter, Bluesky, and Mastodon — with both Twitter and Bluesky delivering it.
Oh, that's supported (though the UX is not really ideal): if they're not on the same server as you, you can navigate to the post on its host server and you'll see all replies there. To join the conversation, you can hit reply on one of the posts and you'll get a UI popup to route you back to your own server to respond from there.
It's definitely not as clean as a centralized solution though.
I'd like to see Nostr added to this, since userbase concentration is always the thing they levy against the fedi model. It'd be a little weird to adapt because user identities don't live on single relays.
Decentralized has a problem. Its premise is that anyone can set up and run a node, cheaply.
If the decentralized network allows for some kind of targeted broadcasting, it becomes attractive for spamming (e.g: email).
If the decentralized network allows for concentration of responses on something, it becomes a potential tool for a DDoS attack (e.g.: DNS amplification).
So running a node should be somehow expensive, but the expense should be written off if the receivers of the message endorse it, by a one-time action, or automatically by subscribing. An initial credit would allow to establish an audience.
It looks like a perfect use case for a cryprocurrency of sorts %) But this means expensive coin generation, and distribution of the huge ledger across all nodes. That could be delegated to some specialized nodes, but here comes centralization again!
But this problem isn't fatal, and can be mitigated directly. The internet itself is extremely decentralized and while both of these things can be issues, it works in practice.
I disagree that building economics into the protocol is the way forward. There's so much power and creativity that can be unlocked when the substrate is free.
What are you talking about? Tons of people run personal blogs/websites, with an enormous variety of hosting structures.
I call that working in practice. The fact that any individual self-hosted site could not survive a DDOS does not negate the fact that, well, the internet actually does exist.
Absolutely false. Find me a non-trivial blog or website (>10k unique visitors per month) self-hosted by someone non-technical that isn't centralized by Cloudflare or a website host.
Like I said: if your site is read-only and you self-host, you're vulnerable to DDoS. You'll avoid it if you aren't very famous and aren't randomly targeted, but you're still vulernable.
And if your site has any kinds of comments, forms, or "write" ability, then you absolutely can't self-host. You will be blown away by spam and hacking attempts.
The "tons" of people you're talking about don't exist. They're mostly on WordPress, Ghost, Substack, or something similar with custom domains, and the ones who aren't are still mostly hiding behind Cloudflare.
I tend to agree. Having tried the Fediverse twice & each time had my server shut down, had a pretty jank sad partial migration forward path (my old replies kind of being cast into limbo), it just doesn't feel like the fediverse actually has "credible exit" at this point. Decentralized but still semi trapped.
Where-as with Bluesky/ at protocol, most folks are on Bluesky servers, yes. But there's a very strong credible exit case where you can leave the Bluesky servers & just do your own thing. And follow whomever you want to follow.
Bluesky / at proto creates a trust mechanism beyond DNS, creates an identity that can be moved around between hosts or replicated outwards in a verifiable way. I dig ActivityPub, and have been a long time http enjoyer, but it's not ideal imo for social media to need to be so coupled to such strongly DNS based client-server systems.
For smaller semi-private circles IRC especially with web front-ends that provide scroll-back are still great but in my experience when they get too big there is just too much politics and too many cultural differences and things start to fall apart much like agilob's example. IRC is still great for groups of like minded people that do not need to bring in the entire world into their tent. In the early internet more people were like or similar minded and so it worked well for the most part. Some would even argue it still works great for the general public but I am not so sure. Keeping web interfaces semi-private with simple-auth and disabling referrers reduces the risk of botters, agent provocateurs and other forms of riff raff trying to sow division among people, or third party AI bots snooping or arguing.
NNTP is also great but most people can not afford individually to mirror entire binary groups and most ISP's no longer perform this so most people just use commercial news feeds if they want binaries or one of the free NNTP / Usenet providers if they are just using text. People can certainly peer with some of the free providers [1] and probably should to reduce the risk of people being censored. Much like IRC people can create their own little private or semi-private linked NNTP servers to replicate a distributed thread based forum of sorts.
I don't disagree but I do wonder if a.) discoverability is really so intractable in a decentralized environment if you're willing to throw a lot of resources towards indexing and b.) if that middle ground isn't like balancing a pendulum upside down - a very fragile equilibrium. A bunch of decentralized units might join together, or a large centralized unit might fail, pushing the pendulum to either side.
You can think of the golden age of blogs and search as an example of both. Search engines formed a centralized hub with blogs, forums, etc. forming the spokes. For a while that worked well before it was degraded by spam and consolidation of disparate forums etc. into a handful of major platforms (fueled partly be acquisitions).
The fediverse folks are violently against any efforts for discoverability. They like the high bar for discovering and joining. Any attempt gets brigaded and shut down quickly
Given how toxic big tent communities like Twitter can get, I think that makes perfect sense for some communities. Some plants thrive in full sun, some plants thrive in the shade. Some social interactions happen in the town square and some happen at more intimate functions.
That's a good point. Thiel's "Zero to One" makes it.
In economics, a market needs several reasonably strong businesses to get price competition. An EU study indicated that the minimum number is about 4. Below 4, price competition seems to disappear and you have oligopoly, or, at 1, monopoly.
In areas where there's no inherent effect like distance to stop centralization,
markets tend towards oligopoly. Look at the number of browsers, the number of big banks, the number of cellular phone companies, and so forth. They're all between 2 and 4.
The stable state seems to be around 3 big players.
This probably applies to social networks. There's only so much attention available.
Fediverse makes the indexing question interesting because some people don't want it deeply indexed: they point to the practice of dredging up old opinions on Twitter as an anti-pattern that the tooling should not support. Indexing without permission is met with hostility / defederation over there, and both individuals and server owners have tools to switch fine-grained indexing on and off.
(It is, of course, fundamentally impossible to keep people from indexing a default-open network, but if one does it, one does not advertise doing it outside the service-supported mechanisms).
> In economics, values below 100 are considered "Highly Competitive", below 1500 is "Unconcentrated", and above 2500 is considered "Highly Concentrated".
Fediverse is almost straight left, and it's already 690. Straight up would be 5000. This is non-linear scale presented linearly.
Google search does a lot more complex processing (crawling, historical weighting) and it does it on unstructured pages. Discoveravility in a microblogging system doesn't have to be a lot more than indexing/collation of structured posts, and end-user clients can be designed to participate in that. "Retweets"/"boosts" are already a form of that.
Sure, but fediverse numbers are pitiful at this point. Reality is that 99.9% of users don't care about decentralization, so it ends up being a "this has to work as well as a centralized system" does.
“Too decentralized” critics should form a non-profit where public hosts can register and build an opt-in index for all the decentralized content. Then there is no discoverability issue.
I wouldn’t be surprised if Facebook tries to eventually capture that data with Threads.
One of the nice things about mastodon is that the total lack of centralization and the absence of the dreaded algorithm means you don't have reputation farmer accounts posting bloviating nonsense the whole time. Its really great there.
Mastodon is social like a quiet pub. Twitter and Bluesky are social like a crowd at a concert.
> Mastodon is social like a quiet pub. Twitter and Bluesky are social like a crowd at a concert.
Good analogy. When Twitter started, I took one look at people shouting "I had a delicious sandwich today" and "I just took an amazing dump" and wanted no part of it. When it later turned into a "clever" contest, I wanted even less.
My quiet little Mastodon community, plus some outsiders I have chosen, is the kind of "social" I want. If someone starts behaving like an influencer, they get muted.
HHI is a pretty interesting metric. It’s calculated by taking each firm’s market share, squaring it, and summing across all firms.
This gives the probability that two randomly chosen customers belong to the same firm.
In one micro models of oligopoly, Cournot competition, it lines up directly with the markup firms can sustain.
Outside of theory, it’s an intuitive way to average together the market power of all firms, with increases in market share for bigger players being weighted more heavily.
The universities need to get together and develop their own open-source search engine as part of an ongoing research project. It should be hosted in a distributed fashion from the universities themselves. They have the expertise and the resources these days to do it. And much of the high quality content on the public web originates from the universities anyway. It will be like the Library of Alexandria and not subject to censorship.
"Decentralization" isn't the end-goal so measuring it here isn't all that meaningful. Personally, I care about:
1. How hard is it to censor the network.
2. How hard would it be for some major player to enshittify the network.
Furthermore, while the fediverse has a single axis for decentralization, BlueSky has 3: number of "big index servers", number of PDSs, number of domain names (how many people own their handle):
1. Increasing the number of PDSs doesn't make it harder to censor the network when everyone still uses the same big index node.
2. BlueSky's primary defense against enshittification is user account portability. I'd love to see metrics on how many users have their own domain names. Having many PDSs is also a good defense here because it reduces the impact of BlueSky (the company) shutting off the firehose, but I still think account portability is the primary defense here.
it would be high in my list of desirability because decentralization means agency to move freely.
i like the fact that if i find the city or state i live in to be boring or economically terrible, i can move.
i like it that if i don’t like the food or atmosphere of a restaurant, i can go to a different restaurant.
i like that if i think billy is a constant asshole, me and my friends can move to the next table over and leave billy behind.
social networks are absolutely no different, no matter how hard certain people try to convince online is different, it isn’t.
we should be soooo incredibly leery of anyone who tells us it’s a good thing to have no agency to eat different food or go party at a different bar.
the hair on the back of our neck should stand up every time someone tries to convince us to go to only a couple of places with the same set of rulers and tries to convince us this is somehow good for us.
how many times have you heard “you want to avoid echo chambers” followed by “therefor everyone should all be on the exact same set of websites with the same set of rulers” followed by “anything less than everyone on the same site is a failure”
it’s double speak: if you are not trapped here, you have an echo chamber.
freedom of movement, freedom of association, etc… are incredibly important to the future health of the internet.
I made a Bluesky account. I posted some pretty boring replies to pretty boring posts, and still got banned. They didn't tell me why I was banned. I didn't bother trying to make my account immune from banning; I just quit since it was pretty boring there anyway. That's one data point against the migration hypothesis.
Bluesky isn't decentralized, anyway, because of the PLC directory.
This just doesn't seem to sink in with a lot of people.
The very second most people need to think about implementation details, like what instance is connected to what instance and what that means, they're done. It's not like they couldn't understand it if they tried: they don't want to try because they don't care. In fact, they don't want to care.
What they care about is interacting with their friends and family and celebrity personas that amuse them, and also get some news handed to them that fits their world view.
They don't want to have a little independent social network-- they want to connect with whoever they want to connect with and access whoever they want to access and any barrier to that makes it worse for them. The centralization is the selling point for a lot of those people. Being at the terminal point in a federated service, as they exist, makes all of that harder. It makes it harder for great reasons but they're reasons that most people don't even want to care about. They trade good, easy experiences with the things that are important to them for things they never wanted and have no interest in learning about. Nerds get a kick out of being on a decentralized social network. Most people absolutely do not care. It's not like they don't want to be: it just doesn't matter to them, so if they have to give literally anything up to achieve that, it's too high of a cost.
It's almost like trying to get people to switch from mobile phones to amateur radio.
SMTP, HTTP, DNS, routing protocols work pretty well despite decentralization/federation. Their "problem" is their greatest strength: they're stupidly simple.
E-mail is really ingenious. It doesn't even define how to send and receive messages in the same standard. One standard is just for delivering messages; you have to figure out how you're going to receive them separately.
Of course most people have an e-mail address hosted by one of a handful of large companies. But you don't have to. And if you buy your own domain, changing providers is easy. Delete your old mail on the old server, upload it to the new server, people can still contact you the same way they did before.
I'm not on social media, so I don't have any dog in this fight. But all the properties of a good decentralized/federated platform are already there in decades-old protocols.
I agree that many people do not care, but I don't think this is a tech problem.
In the real world, you can ask people if they would prefer to live in a town with all bespoke mom'n'pop businesses or just a few big box retailers and chain restaurants identical to the ones in the next town over. The intuitive expectation might be that most people would prefer the bespoke stuff because it offers a more personalized service, but it turns out that many people really do want to have the same experience as folks in the next town over. Even among folks who claim to be free thinkers or unique personalities, even among folks who have xenophobia or express a chavinistic sentiment, there is still an impulse to seek the exact same experiences that folks outside of their community are also having. Why is that?
I am sure there are various psychological and perhaps even physiological reasons why people are drawn to homogeneity, but the bigger problem is that bad actors can find ways to exploit these reasons to amass power. Once those actors have the power to shape society, then it becomes a feedback loop where perhaps in the abstract a person might not desire exactly those experiences that are provided by the central authority, but because the structures in society are now pointing toward that being the "best" option, then that's what people come to believe they want.
I suppose the philosophical question is if people come to want to be exploited, is it still okay to exploit them? Personally I think it's not okay. I think it's a worthy goal to present other options. In an ideal world, perhaps there would be structures in society that define open standards that allow people to find the homogeneous experiences they value while still ensuring that no central authority could take ownership over the delivery of those experiences. Perhaps there should be some assurance that those who deliver the experiences aren't also using other levers at their disposal to engineer the desire for those experiences in the first place.
Which is all to say that perhaps social media should be better regulated, and as nerds we might think that one way to do that is build it into the base technology as decentralization or federation. But one would hope that people outside of tech could at least understand the value, since the tech is just a model of real-world systems.
Users only care about content, how it's brought to them is inconsequential to 99.9% (likely higher) of users.
The chicken and egg problem is that users go where the content is, and content goes where users are.
In reality what this means is that the vast majority of both users and content tend towards a single solution, and that is where there is the least friction, aka the path of least reesistance.
Monetary incentives and various perks (features, first mover advantage, ...) can help but overall it seems to tend towards ease of use.
For users, TikTok is the king for a reason: EVERY SINGLE SWIPE (caps because I want to intentionally put a LOT of emphasis on this) is content that YOU, specifically YOU, are likely interested in. If not, the very next swipe is likely to be what your brain thinks is good, because the algorithm is so good it already knows what you want. Yeah, I know, that's because they spy on their users, whatever, sadly users do not care about that.
BlueSky? Even if you follow specific users, content discovery is so, so much harder. But the main problem is that the vast majority of users, especially new ones, will be subjected to subpar content compared to other platforms.
So why should a new user come back there instead of literally anywhere else? And if there are no users, why put the content there, and if there is no content, there are no users, and so on...
Notice how in all of this the underlying architecture has quite literally no relevance and is nothing but a technical detail.
Still no one cares. They just hop to the next centralized platform that hasn't enshittified yet. As we are seeing now with Bluesky.
Perhaps the idea of decentralization was incorrect to begin with, an NI hallucination - perhaps it should be all about centralization-hopping instead. I believe this is what Nostr aims for, though I've never used it.
Nostr is a bit different - you own a private key that signs any message (and action, but it's all JSON blobs) locally in your app and then you just broadcast these signed messages to servers ("relays") that cache and relay these to other relays or users. Other users can use your public key to cryptographically verify that the message is from you.
The benefit is that you fully own your data, you can later decide to rebroadcast it to any other set of relays. It's common to have e.g. 20 relays connected from your app.
There is a group of people that care and use it and it works well.
One argument could be made here that decentralization also means that there will be variety of different protocols and solutions and that's ok.
> They just don't know that decentralized platforms offer long-term solution.
The crux is that most "decentralized" platforms don't offer long-term solution either. The whole concept of Federation only works as long as everybody is nice to each other, once that stops happening or bus-factor kicks in, you are back to all the problems of centralization and lock-in, since everybody is a user on a server they don't control. It's really no different from early Twitter or Reddit days when everything was nice and open until it suddenly wasn't.
Platforms that are actually build for true decentralization, where the user owns everything and the server owns nothing (public key crypto + dumb relay servers), are still extremely rare. Nostr is one that seems to be on the right track, but that's about the only one I can think of.
> The whole concept of Federation only works as long as everybody is nice to each other
I don't see how it can be true. Is everybody nice to each other on the Internet? On Mastodon, disagreements lead to independent islands not federating with each other, which is fine, too.
> Is everybody nice to each other on the Internet?
For most part, yes. ISPs still carry traffic as is and don't just block random hosts because they don't like them. This is however slowly changing in Europe due to ever increasing censorship and age verification. The Great Firewall of China hasn't been nice either. And Claudflare has also become rather annoying with its constant never ending CAPTCHAs.
> On Mastodon, disagreements lead to independent islands not federating with each other, which is fine, too.
How is that different from Twitter, Facebook or any other centralized service? All of them are just independent island that don't federate with each other. If that's ok, what problem is federation solving exactly?
To me the goal of decentralization is "Get rid of the middle man between me and my audience". Federation ain't doing that, it puts far too much control in the hands of the server.
> How is that different from Twitter, Facebook or any other centralized service?
1. You can make your own server federating with anyone you want. This achieves your goal, doesn't it? And, like everything, it has its cost.
2. You can freely move between the islands. Keeping the essentials like followers, known structure of the system. This forces the servers to compete and prevents creation of walled gardens and enshittification like with Twitter and Facebook.
Same effects work in the Internet itself, which made it survive to a large degree free to this day. Facebook and Twitter, as you noticed are those similar islands. Mastodon achieves a similar, decentralized structure on a lower level, increasing the resilience further and making it easier to move between the islands and create your own one.
Decentralization obviously doesn't on its own protect anything from the governments, but it helps.
Running a server isn't practical for average people. It's also nothing new, people could do since the dawn of the Internet, they don't need a Fediverse for that.
> You can freely move between the islands.
I can freely move between Facebook and Twitter too. Again, not seeing what the Fediverse is doing here for me. The Fediverse does not prevent walled gardens, the federation is an optional server-provided feature that can be switched off any time they want. You can't even move your data from one server to the other unless both servers cooperate.
And Lemmy specifically isn't even GDPR compliant, there is no way to export my comments in the UI. There are also other huge issues such as message-ids being tied to the server, so you can't even resolve a URL from one server with another (something Usenet did better 40 years ago, which is why I can still find old post today).
> Mastodon achieves a similar
If Mastodon decides to run ads and enshittify, it's just like Twitter again. There is nothing to prevent that, outside of being small and unpopular.
> Decentralization obviously doesn't on its own protect anything from the governments, but it helps.
I am not worried about the government, I am worried about overzealous mods and server admins, who are already running rampant on the Fediverse and the Fediverse provides no infrastructure to help me here. That's an area where I much prefer Twitter and Co., they are pretty hands-off with moderation as long as you don't violate the law. On the Fediverse thought-policing is getting sold as a feature.
There is not entity "Mastodon" that could decide anything. It's like saying "if the Internet decides to show you ads". It's a meaningless phrase.
> there is no way to export my comments in the UI
It's just a technical, UI problem, which anybody can solve, as it's free software.
> Running a server isn't practical for average people.
This is not the point. Like with repairs, you don't have to know how to do it to benefit from the right to repair. You can pay anybody in the free market to do your repairs or set up a Mastodon (or web) server for you. This solves the monopoly problem even for ordinary people. This is why you need free software btw - and it's not the case with Facebook or Twitter. You can't freely move between them. Once you leave them, you loose all your followers and specific features.
> That's an area where I much prefer Twitter and Co., they are pretty hands-off with moderation as long as you don't violate the law
This is not even funny. Twitter promotes nazi content according to the latest investigations.
> There is not entity "Mastodon" that could decide anything.
mastodon.social is a server, if you have an account on there, they can delete it. If you don't have an account there, they can still block you by defederating whatever server you are on. This is no different from Twitter and Co. Simply put, look at this from an angle when it goes wrong, not when they go right.
> It's just a technical, UI problem, which anybody can solve, as it's free software.
No, that's a fundamental problem with how the data is organized and distributed. Without cryptographic signatures and unique message-ids, you are slave to the server, even if you get the data out of the server, there is no way to get it up on another. To see how broken the situation is just look at the URLs:
Can you tell that both are referring to the same post? Can you find the feddit.org post on lemmy.zip when feddit.org goes down? This is not a simple "we'll implement that later"-feature, but a fundamental oversight in how data and control gets handled in the Fediverse. That it violates European law, that explicitly exists to empower the user, ain't helping.
> This is why you need free software btw
Free Software is completely irrelevant here. This is about protocols, data ownership and control, areas that no Free Software license even touches on. It's somewhat ironic that GDPR got there first with actual law, while the Free Software world still completely fails to address those issues, despite them being around for 20 years.
> You can pay anybody in the free market to do your repairs or set up a Mastodon (or web) server for you.
Which is worthless, since the value is in the users and their connections, which are under the control of whoever is running the popular instances, not me.
> You can't freely move between them.
I can freely switch between facebook.com or x.com in my browser just fine.
> Once you leave them, you loose all your followers and specific features.
Yes, that's just the same on the Fediverse. When feddit.de went down, where did my data go? My feddit.de account doesn't work on other servers. feddit.org was recreated from scratch and everybody had to move over manually. Account migration requires two cooperating servers, which you don't have if one of them is down permanently.
> This is not even funny. Twitter promotes nazi content according to the latest investigations.
As said "On the Fediverse thought-policing is getting sold as a feature."
mastodon isn't mastodon.social, and you also want to be thought policed unless you want to view child porn every time you log in (there are mastodon servers for pedophiles to share child porn)
It's a common mistake of programmers to treat business as something long-term. Saying "don't do XYZ because it'll stop working in a year once they catch on and block you. Business leaders are stupid for doing XYZ." Yeah, so that means you still made a profit for a year, and business leaders are not stupid for doing it. A year later, there could be a different thing that will work for another year. Changing what you do every year or even more often is just normal business. You don't have to find one thing that works indefinitely.
I agree. Even though the privacy control is opt in to share their posts with the fediverse, I think it's fair for Threads to be counted as a server in the fediverse holding user data. It just has more advanced privacy than others.
Threads barely interchanges with the rest of the Fediverse, it's basically bridged. By this argument you could include Truth Social and Gab, which are directly based on Mastodon source.
> This page measures the concentration of the Fediverse and the Atmosphere according to the Herfindahl–Hirschman Index (HHI), an indicator from economics used to measure competition between firms in an industry. Mathematically, HHI is the sum of the squares of market shares of all servers.
I had not heard of this metric before - it’s neat and simple to understand. If you scaled it down to 0-100 (by dividing by 100), I think it would make the numbers more immediately understandable. I’d even consider inverting it (so 0 = centralized and 100 = decentralized), since the website title implies measuring progress ‘towards’ decentralization.
OTOH the reason why they didn't normalize to 100 may be to not give people an idea that the measure is linear; seeing a score of 2500 makes you ask 'what does it mean?' whereas if you were presented with 25/100 you probably wouldn't think that it is 'highly concentrated'.
It would be great to add nostr, but nostr doesn't really match this model. Nostr doesn't need a single server to hold your identity, your app connects to many "relays" at the same time.
We've had the protocols and tech for decentralized services for 20+ years. The problem isn't the tech, it's the users! Your average Joe simply doesn't have 'must be decentralized' in their requirements. I'm guessing this is due to lack of education on the matter.
Personal data detached from the rest is not measured, so I think it’s not realistic to try to determine whether everyone is decentralized. Use of a central decentralized app like Bluesky is not a good approximation imo.
Can someone explain how Fediverse instances or any decentralized platforms deals with most obvious issues of decentralization?
Like if I join some node then one day it's offline and all my data lost. I mean surely instances usually don't disappear without notice but it still a totally possible thing. Or what about those times when entire instances get involved in dramas and end up defederating? I don't want to lose my connection with potential friends from such instance just because of something like that.
I even remember some time ago when there were news about Threads being federated some people deliberately gathered "signs" across lots of instances to collectively defederate from Threads and it's just ridiculous to me that this even happened. What all this talk about fighting censorship while actively engaging in constant "self-censorship" making own echo-chamber as tight as possible?
In ATProto, this is solved by not having "instances". Your data is stored on a personal server (which can ofc go down). However, your identity isn't hard-tied to that server. If you have a backup (making those more easily available is being worked on by people in the ecosystem), you can restore it on another host and point your identity there instead. So there's one level of indirection which prevents the problem you're describing.
Additionally, since ATProto decouples hosting of data from hosting of applications, there is no such things as "instances" having beefs and defederating from each other. The data flows one way (from PDS to apps). Apps may choose to ban certain PDS's but generally PDS's themselves are treated as app-agnostic containers of data. So intra-network social beefs don't translate to technological cutoff or loss of mobility. Social groups and communities are decoupled from hosting.
> Like if I join some node then one day it's offline and all my data lost. I mean surely instances usually don't disappear without notice but it still a totally possible thing.
This happened to me with julialang.social which just stopped running after the guy hired to host it was poached by Google and he lost all interest in the Julia language community. Lost everything. Not going to look back at activitypub as ATProto is the future for me.
> Like if I join some node then one day it's offline and all my data lost
They just disappear. You're not appending to a long-term immutable blockchain-like archive. You're posting things to the internet and the nature of posting things to the internet (or anywhere for that matter) is that nobody guarantees they will be around forever.
> Or what about those times when entire instances get involved in dramas and end up defederating
Identical to "what about those times when Twitter bans someone whose tweets I want to read?"
> What all this talk about fighting censorship while actively engaging
mastodon is the equivalent of bsd code, but for user generated content.
Microsoft and apple would just reach for bsd tcp stack etc. today bluesky just "federate" to mastodon and instantly had millions of active users, until they don't need to federate anymore, when they will blame the other instances to not migrating to some crazy protocol or something, never they will just "shut the door".
I think this compares AT proto PDSes to Fediverse instances. In many ways this actually underplays just how grossly centralized AT proto currently is, since some of the components are 100% centralized still. (Whereas Fediverse instances, all downsides considered, are at least self-contained fully-independent instances.)
In case of Bluesky, there will also only ever be a single instance of the App View. As far as I am aware though in practice there's really only the official relay or indexing services either.
You can, it just won't be the Bluesky App View, so it's not really Bluesky. It's not like the fediverse where the instances own the URLs of the posts: they go through app views and there's a canonical URL to a Bluesky post and that's through the official app view.
Different AppViews would obviously be branded differently, but the whole point of ATProto is that there is a shared "picture" of the world. People are running alternative AppViews that consume Bluesky posts (and serve Bluesky threads).
Here's the same thread on three different AppViews:
These are three independent webapps indexing the same information and serving it independently. They're not different frontends for one API; these are all independent backends.
one important correction is that blacksky is not hosting their own appview, they host their own PDS for users to join and a soft-fork of the official client
So, it's the same underlying data structures (e.g. posts, threads, etc.), and the way they're exposed depends on the implementation? So there's one BlueSky, but BlueSky is just one interface (UI + API). Am I getting this right?
I just want to know if I can run my own node in my own hardware.
Each user has a "website" with JSON of their own content (e.g. all my posts, all my likes, all my follows, actually live in a sqlite database hosted somewhere). It's not really a website but more like a git repo — one per user.
And then, there's a protocol for how to aggregate information from all such "websites" in the network into a stream of changes. Apps subscribe to that stream of changes and update their local databases (which act as app-specific caches) in response to those events.
When I make a Bluesky post, I'm really writing JSON into my sqlite file. This change gets broadcasted to all interested apps which update their own databases (which may or may not care about specific content type like "Bluesky post"). Obviously forks of Bluesky backend do index Bluesky posts (and then return them in the same UI), but you could imagine other backends that only care about other content types, or that record Bluesky posts but in a different database structure, and ofc can present a different UI for it.
Yes, you can run your own node — multiple types of nodes. You run your own PDS (https://github.com/bluesky-social/pds) to store own data (that's the "website" in my analogy), or you could run a Relay (https://whtwnd.com/bnewbold.net/3lo7a2a4qxg2l) that collects all PDS changes into a stream, or you could run an AppView (any backend that listens to Relay or PDS, basically your own app).
OK, to be honest, I'm surprised anyone runs a third-party Bluesky AppView even just as a curiosity. I genuinely can't understand why anyone would run one of these except as a raw curiosity.
If 99% of the people are using the default AppView, the default relay, the default indexers, the default PDSes, etc, etc... that just means that everything that almost the entire userbase sees is completely controlled by one entity. It's technically possible for people to use alternative services, but the community would have to wrestle the majority control of the network away from Bluesky Social PBC for it to really matter. Running an alternate PDS or even AppView seems like mostly a symbolic gesture since whether anyone can actually see your posts is still up to the whims of one entity, just like Twitter, and that's partly because there's no way to really "own" the URLs of your posts or profile. The canonical URLs are one domain owned by one company. The others are just alternatives.
But:
> the whole point of ATProto is that there is a shared "picture" of the world
I think everyone does understand that ATProto "solves" some of the problems with decentralization that you can observe from the Fediverse, but when you look at the practical reality of ATProto, it's hard to figure out exactly what aspect of decentralization users are supposed to be able to still benefit from. The whole thing could be re-centralized and literally 99% of all users wouldn't notice anything different. If you get censored by the entity running the primary AppView, or even deeper, you could theoretically run all of your own components... but then you'd just be talking to pretty much yourself. Even if you did succeed and somehow wrestled away a substantial portion of users, (which would be extremely expensive and impractical), now you just have the same split world that exists in the Fediverse, but with AppViews/moderation services. It kinda seems like the "shared picture of the world" concept is actually somewhat incompatible with having an actual decentralized network where users meaningfully have control.
P.S.: I know that mentioning censorship is automatically polarizing, but with Bluesky I really feel like I have good reason. I tried Bluesky briefly a long while back just out of raw curiosity, and I actually managed to get my account taken down with zero posts. I literally was just following some artists, mostly Japanese, and I assume one of them got banned for something NSFW. I'm not even sure I liked any posts that were NSFW. Needless to say once I got unbanned I just deleted my account and gave up on it. I wasn't really planning on using it for anything, so it's not like I am horribly offended by this, but it definitely gave me an idea of how Bluesky Social PBC moderates. No thanks.
Having multiple implementations available is an important step towards decentralization, even if most people don’t use them yet. It shows that it’s technically feasible and will help shake out any bugs.
Getting people to actually switch will be harder, and presumably it would involve both promoting the alternatives and adding features that some users will find attractive.
The issue is that Bluesky did their big public launch long before anyone could even run their own PDSes. Instead, they spent a bunch of time working on shit like integrating Namecheap for DIDs. And if you use Bluesky to go and create a DID and set up a domain for it... it will be a centralized DID managed by plc.directory, which is also ran by Bluesky Social PBC, and you can't run your own equivalent of plc.directory, and the alternative DID method that is still supported is used by basically nobody.
Technically people can run their own components for most things, but everyone just knows bsky.app. What's the point? You're never beating them in Google Search. You're never gaining critical mass. People are just going to be really confused at why there are multiple domains that have the same content, and I imagine search indexes will be confused by that, too, probably massively deranking any of the alternatives.
This all makes running your own Bluesky components pretty self-defeating. You can go through all of the effort to have parallel infrastructure for Bluesky, only for an AppView that is doomed to be irrelevant. 99.99% of everyone you interact with is on Bluesky Social PBC's centralized infrastructure anyways and there's basically no chance of that changing. And unlike Bluesky, you don't have shit loads of investor money to spend, certainly not the $15 million that Blockchain Capital invested in Bluesky Social PBC last year.
I think Bluesky Social PBC was well aware of all of this and chose to launch this way anyways, because they absolutely did not have decentralization as a priority. And yes, I know that users on Hacker News are screaming at the top of their lungs, "Users shouldn't care! Users shouldn't care!" But guess what, Users actually cared. People were pissed off about Twitter and wanted a durable alternative that wasn't plagued by the fact that someone could just buy it and take control over the whole platform. Bluesky Social PBC sold Bluesky as a better decentralized alternative to Twitter.
For all of this performative effort though, it's all worthless. Someone could buy Bluesky and immediately close all of the doors; stop allowing new external PDSes and start closing off access to relays/etc. from anyone else. There's not really any reason to actually do that right now, since decentralization is not even a threat to Bluesky Social PBC's control over the network, and unless someone shows up with millions of dollars to blow on a network they don't even have the benefit of being the public face of, they really never have to worry about it anyways.
I criticized a lot of aspects of the Fediverse for a long time, but at least the Fediverse actually delivered on one thing: it actually really is practically decentralized, with all of the ups and downs that that comes with. Users are distributed across instances, so there is no central gatekeeper that would stop me from talking with them. You can almost always avoid any instance-related drama by just running your own instance and interacting from there, if you want. Bluesky will never have that. For Bluesky, users that Bluesky Social PBC doesn't like will be invisible to the vast majority of the rest of the network.
And I'm sorry, but that's not what a decentralized network looks like.
> [...] It's technically possible for people to use alternative services, but the community would have to wrestle the majority control of the network away from Bluesky Social PBC for it to really matter. [...]
> [...] now you just have the same split world that exists in the Fediverse, but with AppViews/moderation services. It kinda seems like the "shared picture of the world" concept is actually somewhat incompatible with having an actual decentralized network where users meaningfully have control.
I think an illustrative example of how a "community split" can happen is Blacksky[1]. It used to only be a custom feed but now have their own client app, their own moderation services, their own relay for their internal services, their own PDS for hosting their accounts, and to the best of my knowledge they want to set up their own Bluesky AppView at some point. With their own AppView, whenever a user is logged in to their client app they'd be using Blacksky's AppView, and anytime they're logged in to bsky.app they're using Bluesky's AppView. A user doesn't need to configure anything, they just download an app and log in with their existing account, and they can be logged into both apps at the same time. Compared to moving your account, to a new home server for Mastodon or even to a new PDS with atproto, it is very simple for your average user to use another AppView.
The "control" users have here isn't that they can control everything that happens within one app, it's that they're not limited to one app or one backend, and that communities of users can meaningfully run their own services if they're not being properly served by the existing alternatives, all while they still seamlessly get a fully global view of every Bluesky user and post.
And hell, atproto is very modular. People have made clients[2] that connect directly to users' PDSs and some "backlink" service like Constellation[3] (to get all likes, replies, etc.), which is much cheaper to run, skipping a Bluesky-compatible AppView entirely. There's also AppViewLite[4] which is a partial Bluesky AppView that's tailor-made for self-hosting.
Having all users, all posts, all data just be available globally to everyone means that you can create very novel and experimental decentralized services and apps. That is personally what excites me the most about atproto and how I see "user choice" be best served. How about a censorship-resistant client app more reminiscent of nostr that connects to multiple Bluesky Appviews and combines the resulting data? Or how about some ActivityPub-like AppView where small communities run their own homes and ping each other whenever there is new activity, eschewing a relay altogether. Everything is possible with atproto, and all of these services would create data existing globally for every other service and user, that can be interoperably viewed and created by any other atproto app that wants to do so.
> I literally was just following some artists, mostly Japanese, and I assume one of them got banned for something NSFW.
I'm personally one of the largest critics of how Bluesky Social PBC treat Japanese anime-style illustrators, so I share your frustration here. Though it's worth noting that large Mastodon instances do the same kind of moderation. Trying to follow illustrators on misskey.io from mastodon.social is very much a toin coss if they're censored or not.
One of my hopes is that we will eventually get the Bluesky AppView equivalent to Pawoo/Misskey. Ideally that one would create records compatible both with Bluesky and some new Pixiv-style atproto app. Then users could set up *booru sites too which work on the same underlying data as what the artists upload, i.e. the artist would keep control over the data. That kind of interoperability makes for a much more interesting web!
> I'm personally one of the largest critics of how Bluesky Social PBC treat Japanese anime-style illustrators, so I share your frustration here. Though it's worth noting that large Mastodon instances do the same kind of moderation. Trying to follow illustrators on misskey.io from mastodon.social is very much a toin coss if they're censored or not.
I can't stress this enough: I don't find it acceptable to ban people if they like posts or follow someone who gets banned. That sort of guilt-by-association is insane. It's one thing to be more censorial than Twitter, which is a choice you can make if you want to, but Bluesky went many steps way too far in how they enforce the rules. I still can't even fathom what actually got me banned, and the cowards there would never admit it (because they know it was wrong.) The only way I'd ever consider going back is if they announced that they fired everyone who thought that was a good idea.
If they're willing to do insane shit like that, I would absolutely not trust any of the other aspects of the components ran by Bluesky Social PBC, so it's far more than an AppView that is needed for sure.
Then there's the fact that Bluesky Social PBC constantly advertised itself as a decentralized alternative to Twitter back before it had launched, well, any decentralized components. Before you could run your own PDS, and certainly before they stopped requiring whitelisting. People make a lot of hooplah about how users shouldn't care about decentralization. Well, a lot of people leaving Twitter at the time did care about decentralization, because they were tired of what was happening to their Internet and wanted a durable alternative. To this day, Bluesky doesn't really actually practically have any of the properties of decentralization that anyone would care about. They know it damn well.
I hate that everybody is just going to let this happen, and I hate that Bluesky proponents jump in and try their hardest to make it seem like there's hope for things to not be controlled by one entity. There isn't. It's a complete load of shit.
> I can't stress this enough: I don't find it acceptable to ban people if they like posts or follow someone who gets banned.
To the best of my knowledge, that kind of banning has only happened once[1] (I was one of the handful caught up in it lol). They reversed that ban when I complained. Unless you were banned at that exact time, what likely happened to you is that some kind of anti-spam filter thought you were a suspicious new account, agnostic of the content of the posts/accounts.
> I hate that everybody is just going to let this happen, and I hate that Bluesky proponents jump in and try their hardest to make it seem like there's hope for things to not be controlled by one entity. There isn't. It's a complete load of shit.
There already are other apps working independently from all of Bluesky's infrastructure (save for plc.directory). I think the big thing holding the protocol back is that they have not implemented private data yet (and it's probably a couple years off). Lots of apps need that, so many apps would not want to use the protocol yet.
I'm hopeful about the future of the protocol, because it does provide the aspect of decentralization I value most: your account is a signed repo and a private key (or several), and the network is necessarily fully open for any app to make use of however they want. Even client-side single-page web apps are feasible with generic backlink services (Constellation), which I find super cool. All that is needed now is time and app development.
> To the best of my knowledge, that kind of banning has only happened once[1] (I was one of the handful caught up in it lol). They reversed that ban when I complained. Unless you were banned at that exact time, what likely happened to you is that some kind of anti-spam filter thought you were a suspicious new account, agnostic of the content of the posts/accounts.
It was definitely around the time of that post. Here's the message I got around 10 months ago:
> Recently, we removed a Bluesky account you control for violations of our guidelines. After a thorough review, we have determined that the takedown action applied to your account was incorrect.
What struck me about this series of posts is how they still never acknowledged exactly what they did (which is, took down accounts using guilt-by-association) nor did they claim they wouldn't do it again, only that they made mistakes while doing it, and they didn't even bother to properly apologize for banning people incorrectly at any point. It reads as if they felt it was all fine and justified and that they will do it again, just, correctly this time, as if there is a right way to do that.
Even if they did stop this practice (again I truly doubt it), there are things you can do that, while they may feel reasonable and justifiable given the circumstances, are a permanent way to lose people's trust. For me this is one of them. I don't think anyone should feel safe hitting like on a post on Bluesky, unless you're absolutely sure it could never be found in violation of any rules. That's insane. Why would I want to be on any network controlled by Bluesky Social PDS when that's how they run it?
> There already are other apps working independently from all of Bluesky's infrastructure (save for plc.directory). I think the big thing holding the protocol back is that they have not implemented private data yet (and it's probably a couple years off). Lots of apps need that, so many apps would not want to use the protocol yet.
> I'm hopeful about the future of the protocol, because it does provide the aspect of decentralization I value most: your account is a signed repo and a private key (or several), and the network is necessarily fully open for any app to make use of however they want. Even client-side single-page web apps are feasible with generic backlink services (Constellation), which I find super cool. All that is needed now is time and app development.
I'm beyond bummed out because I was actually pretty excited for Bluesky early on, but I think they had a window that opened and closed for properly decentralizing. Bluesky today is a heavily curated and heavily moderated network that resembles absolutely nothing of what you would expect from a supposedly "decentralized" network, which is a load of shit for something whose entire draw was that in the first place. What they've created today is so centralized that they can feasibly close it off tomorrow without any impact on 99.9% of users. It's one thing to extol the virtues of its architecture, but that architecture hasn't really been proven to work well in a truly decentralized environment, which is not good when it has already been scaled to these heights. I don't just mean in terms of continuing to function and scale well, I mean in terms of how the network handles abuse and bad actors, and how Bluesky Social PBC will handle parts of the network that don't agree with their moderation policies. (i.e. Was it really wrong to spend so much time highlighting the issues with inconsistency in the Fediverse if ATProto winds up with the exact same issues where the world appears very different depending on what AppView you're on?)
While I admire Dan Abramov's work on React, his attempts to show that Bluesky decentralization is actually happening were to list two alternative AppViews, except apparently, one of them was actually not a full AppView instance. So actually, there is basically one known alternative AppView to Bluesky's AppView. Bluesky has something north of 38 million users, and approaching-100% of them are going to be using Bluesky's AppView. Given the utter lack of incentives to really run an alternative AppView, and the fact that nobody except complete and utter nerds will ever even find them, is there really any good reason to suspect that there will be any alternative AppViews in the long run, or if they exist, that any more than a tiny unimportant fraction of users will ever use them?
The Fediverse has had instances that have done dumb things, but the thing is, you can currently today actually choose any instance you want. A future where you can use Bluesky without the direct influence or control from Bluesky Social PDS in either your personal affairs or even just almost every single interaction you'll ever have is very distant. If we were to extrapolate, it doesn't seem likely the situation will have meaningfully changed in several years. I'd be willing to place bets that in 10 years at least 99% of users will still be on Bluesky Social PBC's main AppView. (To be honest, I wonder if anyone would actually be willing to place money on this bet. I kinda suspect even Bluesky proponents would admit that this is pretty likely.)
This is factually wrong, and disproven by the fact there are now fully independent federated instances such as BlackSky and soon to be NorthSky. Furthermore, they have independent codebases which are fully compatible. Compare to ActivityPub where most instances are just running Mastodon or some close fork or risk breaking compatibility. What's the point of federation if you are stuck with a monoculture of implementations?
The main BlueSky services are still by far the most popular, which is why we see centralization on the network.
Mastodon is definitely not the only fediverse setup that is popular, Misskey, Pleroma and forks of those integrate perfectly well. Given that the main Misskey instance is one of the largest fediverse instances (certainly by activity) it seems a bit unfair to criticize the fediverse on this. I mean, how many completely independent microblogging implementations does a network actually need? (Not even including things like Lemmy or Peertube which are also ActivityPub instances.)
On the other hand I really think you're underselling how much more popular Bluesky services are than any existing alternatives. I don't think we can actually see the distribution of network traffic, but I would be willing to bet decent money that the sum of all alternatives to the Bluesky AppView wouldn't even crack 0.01% the traffic of the main Bluesky AppView. And, honestly, I would probably bet even more money they'll never even come close to cracking 1% ever for the entire lifetime of the protocol, unless Bluesky Social PBC literally goes out of business.
- W. Brian Arthur, "Increasing Returns and Lock-In" (1989): small early advantages + network effects => path-dependent monopolies: https://www.jstor.org/stable/2234208
W. Ross Ashby, "Law of Requisite Variety" (1956): controllers need at least as much "variety" as the environment and it often pushes toward central coordinating mechanisms (or many distributed ones with enough capacity) http://pcp.vub.ac.be/books/AshbyReqVar.pdf
Gilbert & Lynch, proof of the CAP theorem (2002): in distributed computing you can’t have perfect consistency + availability under network partitions and real systems centralize/compromise to cope: https://groups.csail.mit.edu/tds/papers/Gilbert/Brewer2.pdf
== State power, legibility & infrastructure (why governments centralize)
James C. Scott, Seeing Like a State (1998): states seek legibility and large projects favor central plans and standardized populations/landscapes https://en.wikipedia.org/wiki/Seeing_Like_a_State (literally anything by Jim Scott -RIP- will be useful)
Elinor Ostrom, Governing the Commons (1990): shows conditions (clear rules, monitoring, graduated sanctions, polycentric governance) under which decentralized, federated management of shared resources succeed https://www.cambridge.org/core/books/governing-the-commons/A...
----
the literature making a counterpoint is abundant / overwhelming but that feels bleak considering when reading these works, systems thinking )the basis for "la technique") favors centralization
> The Internet itself is decentralized, which made it extremely resilient. So is democracy.
extremely? i wouldn't bet on that.
how do you even measure that? books have been around for over a millenium, that's quite resilient. the internet is barely 50 years old. empires have lasted for thousands of years, modern democracies are a bit over a couple of centuries ... young. how do you determine their resilience? i see quite concerning signs of degradation lately, and they might have something to do with that iron law of oligarchy.
> The article cites a few notable counterexamples like Wikipedia.
no, it doesn't? it has a section titled "examples and exceptions", but it doesn't include any real exception (that has been resilient to this day), let alone a 'counterexample'.
> Your post looks like learned helplessness.
yours looks like wishful thinking (and difficulty in parsing the wikipedia)
TIL about the Herfindahl–Hirschman Index and I wanted to test it with a weird corner-case that I remember.
At one point in the late 1980's Microsoft had a GREATER than 100% market share of the Macintosh spreadsheet market.
How is this possible?
Market share (for a given period) is the participant's sales in the market divided by total sales. It just so happened that Lotus had more returns than sales of their failed spreadsheet, Lotus Jazz. So Lotus, had a negative market share and Microsoft had more sales of Excel than total sales in the market, resulting in a greater than 100% market share.
I don't remember the exact numbers and I believe there was at least one other competitor in the study. But let's just say the numbers were:
Microsoft: 102% Lotus: -2%
In that case the Herfindahl–Hirschman Index would be 102^2 + (-2)^2 = 10404 + 4 = 10408.
So, in this pathological case it is possible for the HHI to exceed 10,000.
Edited: Added (for a given period) above, for clarity.
I have diligently searched for this article online and have been unable to find it. (It might be on microfiche somewhere...)
I did however, find this humorous anecdote:
> A Lotus executive later joked, "The first month we shipped 62,000 copies, and the following month we got 64,000 copies back. It was such a failure they sent us the bootlegged copies back."
https://www.forbes.com/2003/12/16/cx_el_macslide.html
> Market share (for a given period)
That's not a thing. Market share has no time period. It's an instantaneous measure of the state of things right now. How many of your company's units are out in the wild right now being used, vs. how many total units (sold by any company) are out there in the wild right now being used.
That number can and will be different at different points of time, as people buy and return your products, and buy and return your competitors' products[0]. You can certainly say that your market share increased by 300% or by -40% over a given period of time, but your actual market share is always a number between 0% and 100%.
> Market share (for a given period) is the participant's sales in the market divided by total sales.
No, that's a company's share of sales as compared to the industry/product category as a whole. Not market share.
[0] You also should take into account people who throw your product in the trash (or for software, delete it) without returning it. Depending on context, you might even want to take into account people who put your product in a box in their basement and never use it again. Assuming you could actually divine those numbers, which of course you likely can't.
The wikipedia definition is here:
https://en.wikipedia.org/wiki/Market_share
There are multiple methods of measuring multiple (related) things. What you are describing sounds more like the share of the installed base, which only works for certain types of products. (i.e. it doesn't work for consumables like apples or electricity)
HHI is a super useful metric -- glad you like it!
The squared sum of normalized shares proves to be very useful in a lot of contexts -- not just market share. Voting is one great example.
Sounds depressing (i.e. ~5000 in a typical US election)
It gets really interesting when you look at the precinct and county level in the US, and similar types of views in European countries where they do real representative government.
It's ironic that national level politics mirrors the kind that the founding fathers did not ever want happening, while local politics has the kind of representation that they actually had in mind (in most places).
I'm not sure that is ironic.
No it's definitely ironic, in the rain on your wedding day kind of way.
Which is to say, the ultimate irony of Ms. Morisette's song is that there is no irony named.
Neat! I'm not surprised at the findings here. BlueSky (for the average user) is pretty much a drop in replacement for Twitter.
Despite the smaller total numbers in Mastadon, it's great to see that the ecosystem seems to be successfully avoiding centralization like we've seen in the AT-Proto ecosystem.
I suspect that the cost of running AT proto servers/relays is prohibitive for smaller players compared to a Mastadon server selectively syndicating with a few peers, but I say this with only a vague understanding of the internals of both of these ecosystems.
Running a PDS server for yourself and a few friends is not very expensive afaik, but there's also not much benefit to doing so, because the point of the PDS is to have a clean separation between your own data and the rest of the network.
The expensive things in ATProto are the Relay (crawls/listens to PDSs to produce the firehose) and the AppView (keeps a DB of all posts/likes/etc to serve users' requests). Expensive at scale anyway; if you want your own small network for hosting non-Bluesky posts (like WhiteWind's longer character limit), the event volume will be manageable.
For a lot of stuff though ATProto is built in a way that you shouldn't have to host your own; you can implement your own algorithmic feed that reads from the Bluesky Relay's firehose, or your own frontend that still gets data from the Bluesky AppView.
> For a lot of stuff though ATProto is built in a way that you shouldn't have to host your own; you can implement your own algorithmic feed that reads from the Bluesky Relay's firehose, or your own frontend that still gets data from the Bluesky AppView.
ATProto isn't "built this way".
Twitter was also built in a way where you could implement your own stuff - and then Twitter took that away.
With Mastodon, there is one large instance (controlled by the non-profit Mastodon gGmbH). If they tried closing themselves off, their users would be losing access to the majority of people in the network. Plus, while non-profits aren't perfect, they don't have VC investors to answer to.
Bluesky could decide to stop publishing the firehose or restrict its APIs - just as Twitter did. Given that they control 99.55% of the network, they can close it off without worrying about their users losing access to anything. And Bluesky is a for-profit company that has raised around $30M in VC.
What you talk about isn't a feature of ATProto. It's a feature of being centralized and having a company willing to let you use their servers for free (at least for now). This was the case with Twitter for a long time. You could read the Twitter firehose and build your own apps and frontends getting data from the Twitter APIs - just as you can do from Bluesky today.
But unless there's a reason why shutting off the firehose/APIs would be bad for Bluesky, they can do that at anytime. It might anger some users (as Reddit and Twitter both did), but they control the network and network effects are powerful. For most Bluesky users, they'd continue using it because they aren't there for some open protocol. They're on Bluesky because Twitter became a nazi bar. Until we see real decentralization with ATProto, it's just a centralized network like Twitter or Reddit which hasn't shut off its firehose and public API yet. Hopefully that won't happen, but it certainly could.
> ATProto isn't "built this way".
ATProto is built this way. "Closing off bluesky" would be an extraordinarily non-trivial process and would break basically everything. This is in large part why private data isn't a thing yet. The architecture is diametrically opposed to it.
> Bluesky could decide to stop publishing the firehose or restrict its APIs - just as Twitter did.
They could "technically" completely rearchitect their application frontend and backend to do this but any effort to do so would be visible from miles away given the architecture and warning claxons would start ringing immediately.
> And Bluesky is a for-profit company that has raised around $30M in VC.
Bluesky PBLLC is a for-profit "public benefit corporation" for what it's worth and the way they are structured would open them up to legal consequences if they were to move diametrically opposed to the mission they were founded on. Not just because they are a PBLLC but because their initial investment funding was drawn up under an explicit contract that views moves against "the development of decentralised social media" as a violation of the terms of that contract.
No I think ATProto is "built this way". The firehose is just the output of the Relay. If Bluesky wanted to shut off the firehose, they would have to make changes to ATProto or stop conforming to ATProto.
I understand that Bluesky's conformance to ATProto is just a promise, but it's a better promise than you get from most websites. Also in the meantime, if you migrate to a self-hosted PDS, you can ensure that even if Bluesky restricts access to their Relay's firehose, 3rd party Relay servers can still pick up your posts and publish their own unrestricted firehose.
What do you think would happen if the Bluesky company suddenly blocked everyone but https://bsky.app/ servers from using their relays?
And what if, before they did that, they updated the PDS code so it blocked all relays except for their one?
I'm not asking what you would do. I'm asking what would happen because of what everyone does. I think the name "Bluesky" would refer to the fully centralized bsky.app, and 99.9% of users would never notice a difference. Users who had other PDSes would either quit (nobody noticing their departure) or sign up to bsky.app like everyone else. The events of Twitter show it's probably the latter - people bent over backwards to comply with Musk to keep their accounts.
> What do you think would happen if the Bluesky company suddenly blocked everyone but https://bsky.app/ servers from using their relays?
That's not how it works. Appviews pick the relay they use, not the client/user. The relay is used for gossip into the appview (and other things).
More importantly, appviews never see the client/user directly. Appviews only talk to the PDS. Really most things other than the client ever only talk to the PDS or listen to the relay. The only thing that ever directly talks to the client is the PDS.
The way atproto services generally work is the client configures a series of XRPC requests with HTTP headers to determine what appview, labelers, etc to use and it issues that request to the PDS. The PDS then proxies that request to the appview or wherever and they respond back to the PDS which routes the response back to you.
So in a real sense your PDS is not just a data host, but also operates akin to an IRC bouncer.
-----
> And what if, before they did that, they updated the PDS code so it blocked all relays except for their one?
PDS relay routing, etc is mostly all handled manually via config files,etc so this isn't really a concern. And PDS code is probably the "easiest" part of the ecosystem to hack on which is why there are like 6 different implementations with the majority (like 4) that maintain near feature parity with the "bluesky PDS" software.
And importantly, the bluesky PDS is literally a sqlite DB, an OAUTH implementation, some go IPLD data structure manipulation code, and a go XRPC router. It's fairly trivial to hack on as needed.
------
> I'm not asking what you would do. I'm asking what would happen because of what everyone does. I think the name "Bluesky" would refer to the fully centralized bsky.app [...]
Migration currently isn't perfect but within ~6 months it should be ironed out by the community at which point migrating off a PDS to another is just a matter of:
1. click button on new PDS to transfer/"create new account".
2. set your new email, password, and list your old/current handle.
3. get auth code via email (one from the new PDS and one from your DID provider)
4. input codes into migrator interface (for whichever migrator you are using)
5. log into your apps again.
There are multiple large PDS operators working really really hard to spin up operations (proper backups, failover, HA, etc) so they can run reliably and avoid the "my mastodon instance imploded guess everything is gone" issue. Open federation is only about ~ a year old (plus change) so the community is only just now really reaching the "mature third parties" stage.
So, you're making stuff up that obviously has no basis in reality here.
Migration would be impossible because the bsky.app PDS wouldn't allow anyone to access the data except for the bsky.app relay.
other appviews wouldn't display bsky.app data because both the PDS and relay would block them.
First of all, Bluesky the company would have to implement auth on the communication between relay and AppView, cut off everyone from using their relay, and specifically stop ingesting content from non-Bluesky PDSs. There would be time when we realize that's happening to get another AppView up and running. There are arguably enough resources in either the ATproto dev community or other funding sources that another AppView could pop up within a week or two, and be maintained by the community for months without issue. And Bluesky wouldn't likely stop existing altogether, so people would log into Bluesky, see the news (or hear it elsewhere), and see people talking about how to get access to your account.
Secondly, while you're right that most people don't have copies of their repos, some copies of the entire network exist in the community, as well as copies of the PLC Directory. Within a couple weeks we would have community run versions of the AppView, PDSs, Relays, and PLC, and some seriously pissed off community members who would now want to do everything they can to take up the mantle temporarily. Soon Bluesky the app, as well as Instagram and Twitter, would be flooded with tutorials of how to recover your accounts and migrate to another PDS.
If your point is that we'd lose at least half of the users of Bluesky, then yea probably. But ATproto would be just fine, and if people want to get their data back they likely can, as long as they can stomach a little work. And that process is getting easier all the time.
Who would use the new network? It would just be Mastodon Vs Twitter again. All the people you want to read the tweets of would (still) be on Blue Sky, not Black Sky or Red Sky or President Zelen Sky or whatever.
"Convince a HN user that a corporation with the ability to cut you off from your feed sources for more profit won't do exactly that and just because they use something decentralised-ish today doesn't mean they have to keep using that thing if they don't want to" challenge (difficulty: impossible)
> "Convince a HN user that a corporation with the ability to cut you off from your feed sources for more profit won't do exactly that
It's not just a technical restriction though. It's also a legal restriction. Bluesky PBLLC is a public benefit corporation and they are at least in moderate part beholden to their charter.
More importantly, their initial investment contract requires them to further the decentralisation of social media and exposes them to legal consequences should they deviate from that mission.
Those combined make it effectively impossible for them to lock in bluesky. Doing so would require technical changes that would be under no uncertain terms against the charter of the company and against the terms of the investment contracts that initially funded the company. It's a poison pill that would kill the company and destroy any "shareholder value" the moment they try to lock down the service or lock in the users.
You aren't going to see them try this type of brazen lock-in because it'd be explicitly harmful to every investor/VC and saddle the company in legal hell until it smoulders into ash.
OpenAI managed to escape its nonprofit status, becoming incredibly closed and self-serving. There's no reason to expect any other VC-funded nonprofit won't do the same.
Sure they may. And the moment they try to it'll signal to the entire ecosystem what is coming, giving us time to migrate people off to third parties and batten down the hatches. A change like that never happens overnight.
Why didn't everyone abandon Twitter for Mastodon when Elon bought it? Why didn't they even abandon it for Blue Sky until years later? Why is Twitter still as busy as it was when Elon took it over?
Because it requires a new account. Migrating PDS on bluesky does not require a new account, is invisible/transparent to your followers and following, and the end goal is that migration will be easy enough that you can do it in less than 5 minutes with no technical skill.
Bluesky/atproto is still very early/very young but the general theme is to focus on the UX and ergonomics to make decentralisation viable without forcing the user to be technical enough to care about it.
i.e. The end goal is that people should be able to say "fuck bluesky", click a button, wait for a loading bar to finish, and continue using bluesky without using bluesky PBLLC stuff.
To be clear we are not at this point yet and bluesky PBLLC is not suddenly hostile yet either. Triage is in order of priorities so some more important UX aspects are being handled first.
My personal prediction is that this should be a solved problem within less than a year but of course we'll see.
No. That's just not remotely close to true or feasible.
> So, you're making stuff up that obviously has no basis in reality here.
I cannot understand why you are claiming this. I'm basing off the actual architecture and the way the parts interact. The design is just not feasible for locking down. Doing so completely breaks the model and it still leaks like a sieve if you try to.
----------
> Migration would be impossible because the bsky.app PDS wouldn't allow anyone to access the data except for the bsky.app relay.
Nope. Migration is still fully possible. Migration doesn't happen via the relay or any PDS->PDS mechanism. Migration is done via the client. The client/user runs operations on the source PDS, the destination PDS, and the DID registry. All the data is transported between by the client.
Specifically the way it works is you export/backup your information from your current PDS (in the form of a CAR file + blobs). Technically this step is optional. Even if the PDS goes offline or becomes hostile you can actually largely reconstruct this data from the network. Then you "create a new account" on the new PDS and upload your data that you backup up/recovered onto the new PDS. Then you update your DID to point to the new PDS. And finally you deactivate the account on the original PDS (basically saying I no longer store stuff here anymore).
This is part of the reason why migration tooling is a bit bumpy. Your JS script or app has to do the entire process by itself rather than letting the backends handle it. However it does make them extraordinarily resistant to data loss and/or takeover.
----------
> other appviews wouldn't display bsky.app data because both the PDS and relay would block them.
Relays work via gossip. If you can see the relay at any point, you can gossip 100% of their contents to another relay.
In the event bluesky PBLLC locked down their appview and PDS, they'd still have to make the relay open or everything breaks. Feed providers need access to the firehose. Labelers/Moderation Services need access to the firehose. And so on.
Everything is built with an assumption of a public firehose and if you lock down the firehose, all you need is one person to listen to the locked down firehose to 100% replicate it and gossip onto any other relay.
there are already independent relays running. a full relay (which is open source software) costs around 30 USD per month to operate
Running a relay is not expensive anymore (it used to be), with recent changes it's about $30/mo. Running an AppView that ingests all ongoing Bluesky traffic (and puts it into database) is more expensive ($300/mo currently) but if you were happy with a partial view of the network, you could get it down by a lot.
> Running a relay is not expensive anymore [...]
$30/mo is $360/yr, which for most people is a prohibitively large sum of money. That would make Bluesky access more expensive than even the most expensive Netflix subscription; closer to the cost of a cellular plan.
For comparison: for my Mastodon account I pay $5/mo or $60/yr to a dedicated hosting provider. This puts it in the same ballpark as paying for a private email host or a VPN subscription.
This makes sense, but a Relay isn't something you'd expect a normal user to run.
It doesn't meaningfully make you "more independent" because all Relays are trivial (they're just dumb re-broadcasters of a stream) and it makes sense to use one run by somebody else — a company or a community that's pooling resources.
Aren't the entities who manage relays the ones who broker access to the network? E.g. if you subscribe to a relay, you must also subscribe to their moderation decisions.
Say if Bluesky (the company) bans someone, that person could still have the keys to their data, but their feeds will no longer be "re-broadcast" by that company's servers - right?
Relays aren't really user-facing, so most relay operators would probably only censor a user on the relay if there is some legal or network reason to do so, say content illegal in their jurisdiction or excessive spam.
If an app is concerned that a relay is censoring some user that they care about, the easiest solution is just to host their own relay. It's probably cheaper to operate than their app is. But if they really wanted to, they could listen to multiple relays to "cover the gap" or just manually listen to the event stream from specific users' PDSs directly whenever they notice censorship (effectively operating a partial relay in addition to listening to a full but censored one). But, again, in reality they'd just host their own relay and not bother complicating things.
The hardest problem of relays censoring content is to notice it happening, but once you notice you can easily verify it and switch to a different relay.
The PDS is closer to the Mastodon account and will run you the same amount of money. The relay or appview is what takes the load when one of your posts goes viral, whereas in mastadon your $5 VPs has to handle that spike in traffic. Been several a story about how AP has DDoS'd a small server because there is no equivalent to the relay
There's no real reason to set up a relay for just one person, though.
It's less like a cellular plan and more like building your own private cell tower just because you can.
I thought only the way to avoiding the full firehose was connecting to Bluesky's centralized Jetstream instances, and that if anyone else wanted to host Jetstream without depending on Bluesky infra other than the PDS, they would still need to pay the full price for the firehose bandwidth and storage.
I'd be happy to be wrong here though.
Yes and no.
If you want to avoid the entire bandwidth of the firehose, you need something like jetstream (at least until something like sharded relays come around).
However the relay gossip protocol is not as taxing as it used to be. Relay Sync 1.1 massively decreased overhead and it allows relays to run "thin", i.e. running with only a certain backlog of history and not carrying the full history of the network. So you can make a relay that only keeps 24 hours of history and it'll perpetually stay under like 100gb of storage (I don't remember the exact storage amount but storage size is pretty linear with backlog history).
I'm admittedly not versed in the AT protocol, but $30/month is high for me. Something like $10/month is quite fair, and i would expect should be more than enough for a VPS to host my and 2 other members of my family for any social network service...This $10/month is overkill for other servers on the ActivityPub via say gotosocial, pleroma, etc. Not that ActivityPub is perfect or anything like that, i just mean that $30/month is not yet what i would call a sweet spot for self-hosting something...but of course, that is absolutely leagues better than any cost that the bluesky team or other bigger players would naturally have to pay for ongoing infra., etc.
Then again, i will not deny that there's also the possibility that i am simply cheap! :-)
Right, but a Relay is literally a network-wide optimization. That's why in my other comment I'm mentioning that it's hard to do apples-to-apples comparison. With Mastodon, you only have one possible role: "hosting an instance" (which is like hosting a mini-Twitter with almost no data). ATProto aims higher in terms of UX (shared world by default) so there are different distributable pieces with different incentives to run. Anyone can self-host a PDS for super cheap (which will store only your data). But running a Relay is useful as an optimization for whoever's running the actual backends. So if you're a company building on ATProto, maybe you run your own Relay just in case (or maybe you don't and reuse an existing one). Or if you're a collective of people, maybe you pool resources together to run your own independent Relay. It's not something you'd just run for yourself unless you're a huge enthusiast.
Gotcha, thanks for that context!
An important note here is the $30/mo is for the relay which is _not_ something the average user will ever need to run
Instead, you're looking for hosting a PDS which you absolutely can do for $10/mo (or less)
I run a PDS on a OVH Cloud VPS for $5/mo for myself, some alts, and some bots
Aaah, ok, thanks for the clarification!
This is due to different design goals.
Bluesky's architecture was pretty much dictated by the premise that anyone needs to be able to see any post on the entire system, regardless of whether they have any connections with the author. That algorithmic entertainment-style feeds need to exist. You do need that firehose and other expensive infrastructure for that, there's no going around it.
The fediverse, on the other hand, entirely relies on people following each other. Each server only receives and stores data that is relevant to its users. ActivityPub works like an automated email list management system. You follow someone, they start sending you their updates and forwarding any updates from others that they consider relevant, like replies to their posts.
> Bluesky's architecture was pretty much dictated by the premise that anyone needs to be able to see any post on the entire system, regardless of whether they have any connections with the author. That algorithmic entertainment-style feeds need to exist. You do need that firehose and other expensive infrastructure for that, there's no going around it.
Exactly this (that people want it at least - I don't think that means it needs to exist). And I think there would be a lot less frustration in the discourse of ActivityPub vs. ATproto, if we could collectively agree that you can't get this in a decentralized system. In a dense network, the number of edges scales with the square of the number of nodes. It's just not feasible to have a network that is both dense and has a large number of nodes.
I think "I prioritize virality, recommendation engines and network density, thus accept giving control over the network to a centralized and profit-oriented entity" is an entirely reasonable tradeoff to make. I just don't understand why BlueSky users don't seem to accept that it's the tradeoff they are making.
absolutely. it’s even in the design paper, when they discuss the AppView the authors say it’s “less decentralized than alternatives” and yet you can’t say that without bsky fans getting mad.
I think the Twitter format sucks in both cases, but having central, algorithmically-curated feeds are just bad for people psychologically. They just created another Twitter clone with the same problems. The only difference is fewer "nazis".
> BlueSky (for the average user) is pretty much a drop in replacement for Twitter.
One reason Bluesky is so successful is because it doesn't shove decentralisation into the user's face like Mastodon does. The vast majority of people don't know what decentralisation is and don't care to.
I think that far too much effort is put into decentralisation and not enough into good moderation on these platforms.
I don't use Mastodon because it's too decentralized.
What I mean is I own my own domains but I can't use them on Mastodon without self hosting an entire Mastodon server for one user per domain. Yes there are other implementations of the protocol but none really solve this well in a cheap to run way.
Mastodon's missing feature is identity portability. A user with their own domain should be able to easily use a larger instance to host their identities and be able to migrate them to another instance.
There are also significant practical user experience differences.
Doing a search on Twitter searches Twitter, the whole thing. A search on Mastodon only knows about the servers you're connected to (unless you're searching for a specific user, then it'll micro-target their server to get their account info, but you have to know their name through some side-channel. Similarly, if you chance across a Mastodon post and want to follow that user, unless you happen to be on the same node as them you have to enter your own node data to get redirected to do the follow because of the domain-based nature of web security.
These aren't deal-breakers but we have the hard numbers from other web UX to know that every time you put a friction point like these in the flow, you immediately lose some x% of users. Relative to services that are centralized, these things will slow Mastodon adoption.
(This may not be the worst thing. There are other goals besides maximizing the adoption numbers.)
They pivoted into that when Mastodon blew up in Japan, German authorities got involved, and its benevolent dictator Eugen Rochko felt need to distance himself from Japanese for his own safety. German police, especially parts of its federal counter-terrorism swat units(?) seem to have odd fixations with anime and take great offense with those contents for some reason.
They can roll that back, or push moderation angle more, but they won't be able to do so without also come forward with the fact that East Asia is producing substantially more amount overall and on average higher quality content incompatible with Western moderation. Those realities won't be popular anyway.
Moderation is definitely Fediverse’s weakness.
https://roost.tools is working on open-source options for both social (fedi or not) and beyond social. Generally the idea is that we can fight the bad things better if we are working together instead of independently
ATProto's Stacked Moderation is an interesting approach to combine platform, community, and user level choices
https://bsky.social/about/blog/03-12-2024-stackable-moderati...
I'm curious if you could expand on this observation? I've heard this from other Mastodon users but I haven't seen it myself; I wonder if it varies heavily from server to server or if I've just gotten lucky.
Moderation (the intent and success) varies to such a huge extent that it's practically silly to talk about moderation on Mastodon unless you mean moderation on a specific mastodon server (like mastodon.social). But moderation (the process) is intense and servers are usually community run on the change found in a spare couch (i.e. they're volunteers).
I think they do quite well considering the disparate resource levels, but some servers are effectively unmoderated while others are very comfortable; plenty are racist or other types of bigot friendly, but the infrastructure for server-level blocks is ad-hoc. Yet it still seems to work better than you'd guess.
Decentralization means whomever runs the server could be great, could just not be good at running a server, could be a religious fundamentalist, a literal cop, a literal communist, a literal nazi, etc etc. And all have different ideas of what needs moderating. There is no mechanism to enforce that "fediverse wide" other than ad-hoc efforts on top of the system.
Thank you for the clarification; that makes sense.
It is perhaps also worth noting that the Fediverse architecture does nothing to remove racists or bigots from the possibility of being found in the "fediverse" (here referring to the collection of all servers using the protocol and not the protocol itself), and... That's pretty much as-intended. Truth Social uses Mastodon as its backend; there is nothing the creators / maintainers of Mastodon could, or by design would, do to shut it off. The same architecture that makes it fundamentally impossible for Nazis to shut down a gay-friendly node makes it impossible for other people to shut down a Nazi node; there is merely the ability of each node to shield its users from the other.
That's a feature of the experiment, not a bug, and reasonable people have various opinions on that aspect of it.
What even is "moderation" at this point? I'm not sure this word is used as defined on paper dictionaries. It is a codeword for something else, like censorship or influencing or artificial control of public opinion?
Because, if it's purely about filtering out content not desired by users, it could be nearly trivially done at the edge, automatic and completely de-humanized, and the word as appearing lately doesn't read that way to me.
I get where you're coming from, and I have largely the same sentiment, but it's obvious that you've never had any experience running a platform, or using one with no/few rules. You need baseline moderation, even if it isn't super ideological. You've got to keep pedophiles and misanthropes out at the very least.
Sounds like I really should be building one with the AI moderation I have in mind. I kind of have been to random deep ends. Most of them can't be that hard to filter out or steer them away from undesired content, especially in this age of AI...
ATProto also has the downside of being supported by a corporation and investors with various backgrounds that will eventually want to earn something out of it all and there is no telling how this will happen.
There are lots of ways they could make a sustainable income without disrupting Bluesky's current status quo and be comfortably rich for the rest of their lives... but that's completely out of character for them and will never happen. I do think the geeks currently running Bluesky are sincere in keeping it decentralized, but the money people will someday probably force them out and squeeze the user base for a quick buck. A hardcore nerd minority will splinter off, though, and keep the decentralized version running, so whatever. History repeats. Frog swims, scorpion stings.
>There are lots of ways they could make a sustainable income without disrupting Bluesky's current status quo and be comfortably rich for the rest of their lives... but that's completely out of character for them and will never happen.
Sounds like reddit 15 years ago
Is it a quick buck? How long has bluesky been funded for with no return?
I meant "quick buck" like flooding the place with ads, tracking, dark patterns, closing the API/protocol, or doing some sort of crypto scam, with no regard for the platform's long-term health. It's been funded for a few years? That's not really that long for such a small team. But I have no idea how their investors think it might make "Facebook money", and isn't that always the goal?
Quick meaning it's short term from when it starts. The time before it starts doesn't factor in.
A quick buck would be the time from when you put your money in to when you get back your money and a profit.
If you have a sudden massive change in plans like this, it resets the timer. You were doing long term, but now you want a quick buck and you don't care much if the company survives.
If I set up a get rich quick scheme based on overhyping and selling land, it doesn't matter whether I buy the land today or it's land I had for decades for a completely different reason. Either way I'm going for a quick buck now.
But they didn't have this for completely different reasons. They invested money years ago, that they could've bought government bonds with and just earned interest, and instead it went into BlueSky. At some point they'd like a return that would substantially beat the government bond they could've invested in with zero risk.
They invested for the long term. If they suddenly want the company to go all-in on short term profit extraction that is a big change in plan.
> There are lots of ways they could make a sustainable income without disrupting Bluesky's current status quo
Like what?
Off the top of my head: Paid hosting/services on top of the protocol, reddit-gold style tipping and gamification, being a transactional middleman (there are a lot of artists selling things, famous people promoting things, and so on), promoted posts and ads (easily blockable, but some users wouldn't bother).
Bluesky is a small team of like ~30 people, if they keep running lean they have at least a chance of a decent profit margin. But none of that will make anyone a multi-billionaire, so never mind.
I think you are wildly overestimating the user's willingness to pay online, and underestimating the costs to run a large scale site. Even if you remove developer's salaries and server costs, the fines could be worth 10s of millions of dollar per country just for delay in removal of hate speech[1].
[1]: https://en.wikipedia.org/wiki/Network_Enforcement_Act
They could also follow the Gmail playbook.
For consumers, plenty of ads and plenty of tracking. For businesses, heavily-restricted user-to-server APIs and features gated behind subscriptions, think custom domains with Bsky hosting, multi-user post approvals, integrating DMs with customer support systems etc.
You can do all of that while still being fair to and interoperable with the rest of the ecosystem. As long as you don't want the convenience, features and UI of Gmail, you can still communicate with Gmail users from any other provider, and the same could be true about Bsky.
ATProto also currently effectively relies on https://web.plc.directory which is a centralized service, making the protocol effectively centralized.
This is true but it's worth noting that (1) the entire point of this node is to be globally agreed on since it's the root of the identity mechanism, (2) it is auditable (https://github.com/did-method-plc/did-method-plc?tab=readme-...) and operations themselves are self-certifying (https://github.com/did-method-plc/did-method-plc?tab=readme-...). There are some potential issues (like PLC could choose to deny some operations), and the plan is to upstream PLC into an independent entity so that it isn't tied to Bluesky the company.
Anything that is funded by venture capital WILL become worse. You can complain all you want about things that don't have infinite funding having issues, but they'll probably just stay at the same level or get slightly better over time. VC-backend companies only get worse after their early peak.
How does Meta's adoption of ActivityPub play into the corporation and investors supporting / dominating a protocol in the long run?
>I suspect that the cost of running AT proto servers/relays is prohibitive for smaller players compared to a Mastadon server selectively syndicating with a few peers, but I say this with only a vague understanding of the internals of both of these ecosystems.
This isn't quite right. ATProto has a completely different "shape" so it's hard to make apples-to-apples comparison.
Roughly speaking, you can think of Mastodon as a bunch of little independently hosted copies of Twitter that "email" (loosely speaking) each other to propagate information that isn't on your server. So it's cheap to run a server for a bunch of friends but it's cut off from what's happening in the world. Your identity is tied to your server (that's your webapp), and when you want to follow someone on another server, your server essentially asks that other server to send stuff to yours. This means that by default your view of the network is extremely fragmented — replies, threads, like counts are all desynchronized and partial[1] depending on which server you're looking from and which information is being forwarded to it.
ATProto, on the other hand, is designed with a goal of actually being competitive with centralized services. This means that it's partitioned differently – it's not "many Twitters talking to each other" which is Mastodon's model. Instead, in ATProto, there is a separation of concerns: you have swappable hosting (your hosting is the source of truth for your data like posts, likes, follows, etc) and you have applications (which aggregate data from the former). This might remind you of traditional web: it's like every social media user posts JSON to "their own website" (i.e. hosting) while apps aggregate all that data, similar to how Google Reader might aggregate RSS. As a result, in ATProto, the default behavior is that everyone operates with a shared view of the world — you always see all replies, all comments, all likes are counted, etc. It's not partial by default.
With this difference in mind, "decentralizing" ATProto is sort of multidimensional. In Mastodon, the only primitive is an "instance" — i.e. an entire Twitter-like webapp you can host for your users. But in ATProto, there are multiple decentralized primitives:
- PDS (personal data hosting) is application-agnostic data store. Bluesky's implementation is open source (it uses sqlite database per user). There are also alternative implementations for the same protocol. Bluesky the company does operate the largest ones. However, running a PDS for yourself is extremely cheap (like maybe $1/mo?). It's basically just a structured KV JSON storage organized as a Merkle tree. A bit like Git hosting.
- AppViews are actual "application backends". Bluesky operates the bsky.app appview, i.e. what people know as the Bluesky app. Importantly, in ATProto, there is no reason for everyone to run their own AppView. You can run one (and it costs about $300/mo to run a Bluesky AppView ingesting all data currently on the network in real time if you want to do that). Of course, if you were happy with tradeoffs chosen by Mastodon (partial view of the network, you only see what your servers' users follow), you could run that for a lot cheaper — so that's why I'm saying it's not apples-to-apples. ATProto makes it easy to have an actually cohesive experience on the network but the costs are usually being compared with fragmented experience of Mastodon. ATProto can scale down to Mastodon-like UX (with Mastodon-like costs) but it's just not very appealing when you can have the real thing.
- Relays are things "in between" PDS's and AppViews. Essentially a Relay is just an optimization to avoid many-to-many connections between AppViews and PDS's. A Relay just rebroadcasts updates from all PDS's as a single stream (that AppViews can subscribe to). Running a Relay used to be expensive but it got a lot cheaper since "Sync 1.1" (when a change in protocol allowed Relays to be non-archiving). Now it costs about $30/mo to run a Relay.
So all in all, running PDSs and Relays is cheap. Running full AppViews is more expensive but there's simply no equivalent to that in the Mastodon world because Mastodon is always fragmented[1]. And running a partial AppView (comparable to Mastodon behavior) should be much, much cheaper — but also not very appealing so I don't know anyone who's actually doing that. (It would also require adding a bit of code to filter out the stuff you don't care about.)
[1] Mastodon is adding a workaround for this with on-demand fetching, see https://news.ycombinator.com/item?id=45078133 for my questions about that; in any case, this is limited by what you can do on-demand in a pull-based decentralized system.
> You can run one (and it costs about $300/mo to run a Bluesky AppView ingesting all data currently on the network in real time if you want to do that).
A clarifying question: the blog post [0] I found about zeppelin.social which I think is a full AppView, the author said this:
"The cost to run this is about US $200/mo, primarily due to the 16 terabytes of storage it currrently uses"
Last I heard the amount of storage was just a couple of terabytes so the growth seems to be very fast.
If and when the primary cost is the storage, IMO the crucial question is: what's the expected future cost of running community AppViews?
Because unless storage cost drops as fast as the BlueSky data grows (unlikely?), to me this architecture looks like it will very soon kick out smaller players and leave only BlueSky with enough money to keep the AppView running.
[0] https://whtwnd.com/futur.blue/3ls7sbvpsqc2w
I can’t speak to how fast it grows and what it was, but I mean — if what you want is to keep the entire data of the network (similar to having all tweets on Twitter) ready to be queried then you have to store them. That’s just unavoidable in any technological solution. Alternatively you could hydrate and query posts on-demand from their sources (PDS), and people have done that as an experiment, but you need at least some aggregation to happen somewhere (for reconstructing reply lists or like lists etc). If more collectively-run network caches are available, this becomes more feasible without storing everything yourself.
In any case, if you’re okay with a partial snapshot of the network (eg all posts during some window or even more partial) then you can arbitrarily narrow that down. In Mastodon, having a “full” archive is downright impossible which is why we’re not talking about the same with regards to Mastodon. Whereas ATProto makes it possible, with the cost being the floor of what you’d expect the cost for storing data to be. How could it be better?
> if what you want is to keep the entire data of the network (similar to having all tweets on Twitter) ready to be queried then you have to store them.
They need to be stored, but do they technically have to be stored by just one AppView? I get that it's a 100x easier to implement it like that, but I don't think a distributed search would've been technically impossible (although, granted, necessarily it would have had worse UX).
Choosing this feature and then implementing it like they did was a technical choice. Technical choices have consequences and this, I think, was the one which will prevent BlueSky from reaching any meaningful decentralization.
And saying "you can create an inferior UX with affordable costs" is not a real answer. Any meaningful decentralization IMO can only happen if it's affordable to create feature identical nodes. That can only happen if you refuse to implement features in ways that need centralization to scale.
I’m not sure what choice you’re referring to here. Yes, simply loading data from the database is the most straightforward solution, and that’s what Bluesky itself did for its AppView. That’s kind of the default model in general in web development — and has nothing to do with decentralization. If you were running a centralized Twitter, storing the amount that Twitter stores would cost you exactly the same.
On the contrary, ATProto adds flexibility here. There are community-run projects like https://constellation.microcosm.blue/ that let small application builders avoid that burden. Of course you don’t want to overwhelm those by building a massive app on top. But the point is that ATProto starts with equivalent baseline to what you’d pay running a centralized service, and then gives you room to play with distribution of costs, potentially going all the way down to directly querying PDS’s on-demand or something in between like community-maintained caches or even potential third-party app-agnostic aggregation services. Eg you could imagine AWS, Vercel or Cloudflare building “app platforms” in five years that let you cheaply query shared data.
As for creating “identical” nodes, I think you hit the nail on the head — that’s not what ATProto aims to do. The insight is that it’s not useful or feasible for everyone to run their own copy of Twitter. But that it’s possible for everyone with “proportional interest” to run a “proportionally complete” part, with some of the costs being amortizable and poolable across many users and apps (thanks to shared infrastructure) and always individually replaceable (to avoid lock-in). This is strictly better than centralized.
> [1] Mastodon is adding a workaround for this with on-demand fetching, see https://news.ycombinator.com/item?id=45078133 for my questions about that; in any case, this is limited by what you can do on-demand in a pull-based decentralized system.
I'm not super up-to-date on Mastodon's/ActivityPub's workings, but aren't replies to a post pushed to the original poster's server? So wouldn't followers then be able to pull from that server at any time to get an always-up-to-date view of replies, at least theoretically? (With maybe posts from the last few seconds missing if the network's slow.)
(Asking because I've seen you claim that the architecture is inherently limited to never be able to achieve the "cohesive" experience.)
This only works for direct reply chains, right? It doesn’t provide a realtime view into all existing conversations that are happening on the post.
Imagine if, when you refreshed this HN page, only comment chains you’re already in would refresh timely. Yes, this would “work” to some extent, but it would clearly be a regression.
Additionally, going viral can overload your server due to this architecture. In ATProto this never happpens for self-fosters (of PDS) because the cost is amortized by AppView. (Same as in centralized products where the cost is on the backend.)
Ah gotcha, yes, indirect replies would need to be forwarded or something.
(To be honest, I'm already surprised that Mastodon scaled as far as it did. I will say, if I had seen the state of the web's architecture 20 years ago today, I probably also would have claimed that it was inherently insecure and that there was no way to get it to be secure enough to scale to billions of users, so... I don't know, maybe people will keep finding duct tape solutions to make it work, worse-is-better-style.)
That's a big post that doesn't really explain in what way can smaller players federate with ATProto or how the structure allows federation.
Reading through it, it just sounds like sharding/scaling for a centralized service that's meant to be owned and provided by a single entity.
>in what way can smaller players federate with ATProto or how the structure allows federation.
Each of the pieces I've described (PDS, Relay, AppView) implement the protocol specified at https://atproto.com/. Anything that acts as an ATProto PDS can be used as an ATProto PDS, anything that acts as an ATProto Relay can be used as an ATProto Relay, and so on. I'm not sure I understand the question so pardon the tautology.
The structure allows federation by design — a Relay will index any PDS that asks to be indexed; an AppView can choose the Relay it wants to get the data from (or skip a Relay completely and index PDS's directly); anyone can make their own AppView for an existing or a new app. That's how there are multiple AppViews (both for Bluesky app and for other ATProto apps) ingesting data via multiple Relays from many PDS's. There aren't many independent operators of each piece (especially outside of PDS self-hosting) but nothing is privileging Bluesky's infra.
Additionally, Bluesky's reference implementations of each piece are open source. So people run them the same way you would usually run software -- by putting it on a computer and exposing it to the internet. To run a custom PDS, you can either use the Docker container provided by Bluesky (https://github.com/bluesky-social/pds) or implement your own (e.g. https://github.com/blacksky-algorithms/rsky). Ditto for other pieces.
>Reading through it, it just sounds like sharding/scaling for a centralized service that's meant to be owned and provided by a single entity.
You're right in that the goal is to make it on par with centralized services in terms of UX and performance/scaling. However, it is decentralized.
The picture at the end of this article might help: https://atproto.com/articles/atproto-for-distsys-engineers
I think what they are asking is: if I run a my own BlueSky AppView, how do I integrate with the bluesky.app so that users signed in on my AppView can interact with users on the the main AppView and vice versa? This is how most of us think about federalisation.
That's already the default behavior. You don't need to do anything special for that to work, it's what ATProto is designed for. Everything is always operating in a shared space by design.
When people "post", their posts go to their PDS's, which means that every AppView ingests data generated by every other AppView by default. There is no way to tell who's using which AppView — in fact, you can log into any AppView and your profile will be there with all your posts.
An appview is really just a service for hydrating content in the skeleton of posts that feeds return back to give to the user.
The only things they do other than feed hydration are track notifications, (optionally) provide a search engine, (optionally) provide a CDN, and (temporarily until E2EE rolls out) handle DMs.
So you can actually do things like the Red Dwarf [1] project which is a bluesky client without an appview. It's slower, you visibly notice request loading/pop-in, there's no notifications, and no search but it works with any other bluesky appview (since appviews are basically a lens into atproto rather than an independent service).
--------
If you wanted to run your own infrastructure, instead you'd probably want to run your own PDS. Running an appview has its benefits of course but the main way you "self host" is to run a PDS. That's fairly trivial and people have run them on all kinds of constrained hardware (including a literal jailbroken microwave if I remember correctly).
1. https://tangled.sh/@whey.party/red-dwarf
AppViews do things like track likes, or replies.
The AppView doesn't do that only for Bluesky data. It does it for any Personal Data Stores (user accounts with all their user data) that it knows about.
When you "interact" with users elsewhere, all you do is generate new records on your own PDS. You generate a "like" entry, or a reply, on your own PDS. It's your pds, all your stuff goes there. The AppView sees that and indexes it, attaches that like or that reply in the AppView to the post you're reacting to.
Other people can run AppViews too (that operate over the same or different data). There are just less people doing that than hosting Mastodon instances partly because it's much more expensive to, because some of the benefits of hosting a Mastodon instance can be obtained much cheaper through running a PDS server, and because AppViews doesn't serve the same exact social role that Mastodon instances do. (Mastodon has every instance be a semi-isolated community, so Mastodon instances are often made for the social purpose of running a semi-isolated community. Bluesky users expect a global timeline that's not partitioned by server instances, so it doesn't get many people running AppViews specifically for fostering semi-isolated communities. People on Bluesky who want to foster semi-isolated communities tend to use features like custom timelines to do so instead.)
I think it can be explained a little better.
When you write a post, you save it to your PDS. Think of it like writing a blog. You're done, you hit submit, it shows up on a server somewhere. You can run your own server with your own data, or use someone else's. That's exactly how a PDS works; it is a storage server for your data.
The AppView is a way to index all the PDSes registered across the whole network. If your server is crawlable by the AppView, all your data shows up in the app. This is like if your blog is crawlable by Google, you show up in search results.
When you like a post, you commit a "like" record to your personal server. When the AppView displays likes, it looks at every indexed PDS and shows every like it can find for that post (simplifying a little for clarity). Each one of those likes might live on different servers, some of which is self-hosted.
Because you can run your own PDS, you can commit any data you want to it. You can even commit things that services may find distasteful. However, the AppView may refuse to serve this content to users; this is how content can be removed from the network and how users can be banned. The federation equivalent would be defederation, except it happens to singular accounts rather than entire instances.
If you disagree with the moderation policies run by Bluesky the company, that's when you can look into running an alternative AppView. This is similar to disagreeing with the admin of a particular Mastodon instance and moving to a different instance. Of course, as mentioned running an AppView is much more expensive, but that hasn't stopped folks from trying (I believe Blacksky is trying to run their own AppView that is fully independent of Bluesky).
To use an alternate AppView, you'd simply go to a different website. This website will index PDSes the same way that Bluesky does, but it may index them in a different way and include/exclude different content. The data is still there (nobody can reach into your PDS on your server and delete your data), but the AppView admins choose which content they wish to serve to people using their community, just as Mastodon admins choose who to federate with.
In this sense, it is indeed truly federated. The primitives are simply different; it's more granular than Mastodon.
You can write your own content to your own server and let it get indexed to any number of AppViews; you completely control your personal data and nobody can reach in and delete that data randomly as they don't own it - you do (at the cost of ~$1/month or a Raspberry Pi).
When you use the Bluesky service, you are seeing their view of the network and what they choose to index. You may disagree with this view, just as you may disagree with the admins of Mastodon.social etc. In that case, you can choose to use another AppView (such as deer.social or Blacksky) that adopts different policies. Since account information isn't stored on the AppView and it simply handles indexing and moderation, moving between AppViews is painless and no data needs to be transferred from one server to another - you simply use a different bookmark.
It could be that you disagree with all the current AppView admins. You can host your own, it's just expensive ($300/month, as mentioned). You can also tailor your AppView to index less content, which will of course limit the amount of data you consume and give you a partial view of the network, effectively defederating you from anything you do not wish to index.
But there's nothing stopping you from doing so!
> Despite the smaller total numbers in Mastadon, it's great to see that the ecosystem seems to be successfully avoiding centralization
But since essentially no one is using it doesn’t suggest much avoidance of centralization. These factors are not independent. It’s pretty easy to avoid anything when your total user count is a rounding error compared to the alternatives.
Bluesky user count is the same order of magnitude as Mastodon and is centralized. I think your argument is actually that if you are on a minority platform your wants and needs for how that platform operates are irrelevant. I suppose that's true if you aren't on the platform, but I don't think it's true if you are.
So we are not decentralized. Git was a good attempt, but it kind of got centralized around GitHub, GitLab, and other variants. BitTorrent was decentralized, except tracker sites were the natural centralization points. Bitcoin was also decentralized, but still had Coinbase and other sites. Even SMTP is de facto centralized due to the spam problem.
> Even SMTP is de facto centralized due to the spam problem.
It's important to note that this isn't "you have to be big in order to be able to filter spam". That's not true at all; decentralized anti-spam lists have been a thing for decades and the big sites don't have any significant advantage in filtering spam.
It's allegedly that big sites will mark small sites as spam even when they're not, which makes it hard to run a small mail server. And there is some of that -- they also have a perverse incentive to do it on purpose because it kills their smaller competitors.
But it's also somewhat overstated. If you have a reverse DNS entry pointing back at your mail server and have properly configured DKIM, it's not inherently the case that you're always going to be marked as spam. And it's not inherently the case that you won't just because you use one of the big services -- they have the same incentive to do that to each other, after all.
Sure, but how many email users have a reverse DNS entry or even know what that is? DKIM? It is, de facto, beyond the reach of 99.9 % of all email users.
Right but if you are going to run and operate server infrastructure for yourself you need to know about that stuff.
You saying the average admin is gonna have no issue setting up their MX records but “won’t even know” what a reverse DNS entry is?
What? Most people are either incapable or unwilling to run their own mail servers. People could hack together their own social media or messaging sites in PHP, that doesn't mean Facebook and Twitter aren't centralized. That's what de facto means.
Git is decentralized in exactly the way it was intended to be. I do all my development on my own host. I collaborate with a lot of different remotes. Even when a project insists on using Github, I contribute by forking to my own host, push patches to the forge of my choice, and invite the maintainer to pull from there if they like. A lot of maintainers just mirror to Github and/or Gitlab.
Sure, a lot of people pick one center and stare at it. But there are plenty of centers and that situation is getting better recently. Some even integrate git with ATProto or ActivityPub.
> except tracker sites
There are loads of different tracker sites. Many private. If one goes bad, others pop up to replace it. This is decentralised - there is not one player that strangles the ecosystem.
> There are loads of different tracker sites
Not to mention the mainline DHT. Not impossible or even very resource hungry to run a scraper/crawler/listener and be able to search via it, like bitmagnet (https://bitmagnet.io/) that has some fun pipe-dreams like federation of indexers and something like an decentralized private tracker.
Anyone can construct a service like Coinbase, and in fact there are numerous such sites available; at this point, you can even use PayPal! You don't even have to continue using the same one you started with: you can buy Bitcoin with PayPal and then sell it with Coinbase. It seems like a very strange definition of centralized to say that this causes any kind of centralization on Bitcoin...
The link back to the real world is money in your bank account. While Coinbase is not the only market player who can provide that (put money in your bank in exchange for bitcoin), it's the biggest, and so there is (to a degree) de facto centralization. More so given that if Coinbase fell (due to government seizure or similar), it's likely sibling services would fall as well.
Ofc, your bitcoin would still be "safe" and still be "yours" on the chain assuming you owned your wallets directly, but those guarantees would now lack meaning or real world consequences. At least until another link to the real world could be established.
But, Coinbase is not, actually, the biggest... not by far? Binance is like, 20x larger. And it isn't even as if you need to get dollars for your Bitcoin, in case the United States government decides to go aggro, so you can find someone in another country to convert you out through another currency. If this is our definition of centralized, then it is difficult to believe that anything is decentralized. There are enough numerous legitimate reasons to be angry at Bitcoin -- hell: even numerous legitimate reasons to say it is centralized -- that we shouldn't start making some up.
I was using Coinbase as a placeholder -- I am not up on current market share status but most people I know in the US use Coinbase. The point stands.
> so you can find someone in another country to convert you out through another currency
This is not so easy for large amounts -- the whole reason to use a Coinbase is institutional trust -- and is certainly inconvenient. In practical terms, across the ecosystem of users, it would not be some small roadbump but a massive problem.
Well git was not really an attempt at decentralization so there is that.
And in many ways it actually is remarkably meaningfully decentralized - or perhaps "effectively" decentralized - in terms of every node having a full working copy of entire repositories that can be trivially cloned to another provider or stood up on a self-hosted server.
I’d say the opposite. Git is defacto centralized. And I’d go further and say that attempting decentralization is the biggest problem with Git. It maybe makes sense for Linux. But for 99.999% of projects it makes everything so much worse.
I think git is a successful attempt despite existing centralized hubs. git over ssh just works. Decentralized does not mean federated
Everything you listed IS centralized, though.
We're more decentralized in fedi but we're also not really consistent either. Which I think is the number one gripe for users who manage to get into the fedi.
I don't mind, I still think it's a huge leap forward, but it's important to set realistic expectations.
What do you mean by consistent?
(Never used the fediverse, so zero context here).
Not who you're replying to, but one issue is that different users will sometimes see a different subset of replies to a post, depending on what the server they're using has copied from other servers.
This isn't correct. Mastodon merged fetch-all-replies in March. https://github.com/mastodon/mastodon/pull/32615
The only difference in visible replies is in the moderation choices of the server the post is viewed from.
Yes but it's off by default for a reason, it's not realistic to expect every node to fetch all messages.
This is a catch 22 because the reason fedi is more decentralized is because of the low barrier of entry to run a node, but at the same time that low barrier means it takes less resources because it does not fetch every single message and piece of media.
It's currently on on the flagship instance and will be on by default in the upcoming 4.5 release.
How does it work?
In ATProto, there is no need to do this on-demand because the data is already there in the AppView. When you want to serve a page of replies, you read them from the database and serve them. There is no distributed fetching involved, no need to hit someone else's servers, no need to coalesce them or worry about limiting fetches, etc. This is why it works fine for threads without thousands of replies and hundreds of nesting levels. It can also be paginated on the server.
If you don't have this information on your server, how can you gracefully fetch thousands of replies from different servers and present a cohesive picture during a single request? I'm sure this PR does an attempt at that but I'm not sure this is a direct comparison because Mastodon can't avoid doing this on-demand. If we're comparing, it would be good to list the tradeoffs of Mastodon's implementation (and how it scales to deep threads) more explicitly.
There is a detailed explanation available at the link I posted. Second header, "Approach".
What do you expect the performance characteristics to be compared to querying a database?
I expect them to be unimportant. This has been merged upstream and running on the flagship Mastodon instance for a little while now.
There is also a section related to performance available at the link I posted. Third header, "Likely Concerns", second subheader, "DoS/Amplification".
What do you mean by unimportant?
I mean from the user's perspective: when I open a thread, I expect to instantly see the entire discussion happening across the entire network, with the paginated data coming back in a single roundtrip. Moreover, I expect every actor participating in the said discussion (wherever their data is stored) to see the same discussion as I do, with the same level of being "filled in", and in real time (each reply should immediately appear for each participant). It should be indistinguishable from UX of a centralized service where things happen instantly and are presented deterministically and universally (setting aside that centralized services abandoned these ideals in favor of personalization).
With ATProto, this is clearly achieved (by reading already indexed information from the database). How can you achieve this expectation in an architecture where there's no single source of truth and you have to query different sources for different pieces on demand in a worker? (To clarify, I did read the linked PR. I'm asking you because it seems obviously unachievable to me, so I'm hoping you'll acknowledge this isn't a 1:1 comparison in terms of user experience.)
To give a concrete example: is this really saying that replies will only be refreshed once in fifteen minutes[1]? The user expectation from centralized services is at most a few seconds.
[1]: https://github.com/mastodon/mastodon/pull/32615/files#diff-6...
I'm not very interested in arguing over the ins and outs of "user expectations" and Mastodon vs. Bluesky, sorry. I would suggest you try it yourself and come to your own conclusion about whether this is a usable system :^)
I'm arguing that "not really consistent" from the grandparent post still applies, and therefore your "this isn't correct" isn't correct.
For realtime discussions (like this one), I don't think we can call it consistent if it takes multiple minutes for each back-and-forth reply to propagate across instances in the best case (and potentially longer through multiple hops?) because you'll see different things depending on where you're looking and at which point in time.
In practice, this is rarely an issue due to the nature of human attention. Beyond a couple dozen speakers in a conversation, it's noise.
At least to my observation; I haven't pulled apart the protocol to know why: if you're in a conversation in Mastodon it's real good about keeping you in it. The threading of posts seems to route them properly to the host servers the conversing accounts live on.
And yet I could have a realtime public threaded conversation on Twitter, and am having one on Bluesky (regardless of which PDSs or AppViews other people are using), but cannot in principle have on Mastodon (unless everyone I talk to shares my instance). Does this say anything about relative ability of ATProto vs ActivityPub to meaningfully compete with centralized services?
I hear your point that slower conversation can be better. That’s a product decision though. Would you intentionally slow down HN so that our comments don’t appear immediately? You could certainly justify it as a product decision but there’s a fine line between saying you should be able to make such decisions in your product, and your technology forcing you to make such decisions due to its inability to provide a distributed-but-global-and-realtime view of the network.
I'm not sure where you reached the conclusion that you can't have a realtime public threaded conversation on Mastodon; I do it frequently. The way it generally works is that clients will auto-at-tag people in the conversation, which makes sure the message is routed to all in the conversation within more-or-less milliseconds.
Auto-at-tagging doesn't scale to dozens and dozens of actively-engaged speakers, but neither does human attention, so that's not a problem that needs to be solved.
I realize that we might be arguing over definitions here, but to me part of the experience of Twitter-like conversation is seeing other replies appear in real time even when they’re not directed at me — same as how you’ve noticed this thread on HN.
Seeing the existing convo in real time lets me decide which points to engage with and which have been explored, and to navigate between branches as they evolve in real time (some of which my friends participate in). I do earnestly navigate hundreds of times within an active thread — maybe it’s not your usage pattern but some of us do enjoy a realtime conversation with dozens of people (or at least observing one). There’s also something to the fact that I know others will observe the same consistent conversation state at the time I’m observing it.
You might not consider such an experience important to a product you’re designing, but you’re clearly taking a technological limitation and inventing a product justification to it. If Mastodon didn’t already have this peculiarity, you wouldn’t be discussing it since replies appearing in realtime would just seem normal.
In either case, whether you see it as a problem to be solved or not, it is a meaningful difference in the experiences of Twitter, Bluesky, and Mastodon — with both Twitter and Bluesky delivering it.
Oh, that's supported (though the UX is not really ideal): if they're not on the same server as you, you can navigate to the post on its host server and you'll see all replies there. To join the conversation, you can hit reply on one of the posts and you'll get a UI popup to route you back to your own server to respond from there.
It's definitely not as clean as a centralized solution though.
This kind of UX is the main reason I personally dont use Mastodon. It's just not intuitive
Good to know. Thanks for the update!
I'd like to see Nostr added to this, since userbase concentration is always the thing they levy against the fedi model. It'd be a little weird to adapt because user identities don't live on single relays.
It would be weirdly represented since most clients push to multiple relays while the account so to speak is a public key pair on the user's device.
Decentralized has a problem. Its premise is that anyone can set up and run a node, cheaply.
If the decentralized network allows for some kind of targeted broadcasting, it becomes attractive for spamming (e.g: email).
If the decentralized network allows for concentration of responses on something, it becomes a potential tool for a DDoS attack (e.g.: DNS amplification).
So running a node should be somehow expensive, but the expense should be written off if the receivers of the message endorse it, by a one-time action, or automatically by subscribing. An initial credit would allow to establish an audience.
It looks like a perfect use case for a cryprocurrency of sorts %) But this means expensive coin generation, and distribution of the huge ledger across all nodes. That could be delegated to some specialized nodes, but here comes centralization again!
But this problem isn't fatal, and can be mitigated directly. The internet itself is extremely decentralized and while both of these things can be issues, it works in practice.
I disagree that building economics into the protocol is the way forward. There's so much power and creativity that can be unlocked when the substrate is free.
It absolutely doesn't "work in practice" for the web.
Read-only sites, like personal blogs, are easy to self-host but vulnerable to DDoS attacks if targeted.
Writeable sites, like anything with a form or message board, are now too expensive to run because of spammers and hacking bots.
We're now all paying rent to Cloudflare or Substack or whatever because you can't just be an isolated island on the open web anymore.
What are you talking about? Tons of people run personal blogs/websites, with an enormous variety of hosting structures.
I call that working in practice. The fact that any individual self-hosted site could not survive a DDOS does not negate the fact that, well, the internet actually does exist.
Absolutely false. Find me a non-trivial blog or website (>10k unique visitors per month) self-hosted by someone non-technical that isn't centralized by Cloudflare or a website host.
Like I said: if your site is read-only and you self-host, you're vulnerable to DDoS. You'll avoid it if you aren't very famous and aren't randomly targeted, but you're still vulernable.
And if your site has any kinds of comments, forms, or "write" ability, then you absolutely can't self-host. You will be blown away by spam and hacking attempts.
The "tons" of people you're talking about don't exist. They're mostly on WordPress, Ghost, Substack, or something similar with custom domains, and the ones who aren't are still mostly hiding behind Cloudflare.
How would one measure old school federated contexts like IRC and NNTP in this way? I wonder would they would fare.
Remember how freenode changed owner and pretty much everyone moved away from it in less than 1 week? It was easy and possible.
Perhaps "frictionless migration" is the real metric to optimize for, rather than decentralization at any given point in time.
I tend to agree. Having tried the Fediverse twice & each time had my server shut down, had a pretty jank sad partial migration forward path (my old replies kind of being cast into limbo), it just doesn't feel like the fediverse actually has "credible exit" at this point. Decentralized but still semi trapped.
Where-as with Bluesky/ at protocol, most folks are on Bluesky servers, yes. But there's a very strong credible exit case where you can leave the Bluesky servers & just do your own thing. And follow whomever you want to follow.
Bluesky / at proto creates a trust mechanism beyond DNS, creates an identity that can be moved around between hosts or replicated outwards in a verifiable way. I dig ActivityPub, and have been a long time http enjoyer, but it's not ideal imo for social media to need to be so coupled to such strongly DNS based client-server systems.
It was a pretty huge disruption, though, even though the damage wasn't fatal.
For smaller semi-private circles IRC especially with web front-ends that provide scroll-back are still great but in my experience when they get too big there is just too much politics and too many cultural differences and things start to fall apart much like agilob's example. IRC is still great for groups of like minded people that do not need to bring in the entire world into their tent. In the early internet more people were like or similar minded and so it worked well for the most part. Some would even argue it still works great for the general public but I am not so sure. Keeping web interfaces semi-private with simple-auth and disabling referrers reduces the risk of botters, agent provocateurs and other forms of riff raff trying to sow division among people, or third party AI bots snooping or arguing.
NNTP is also great but most people can not afford individually to mirror entire binary groups and most ISP's no longer perform this so most people just use commercial news feeds if they want binaries or one of the free NNTP / Usenet providers if they are just using text. People can certainly peer with some of the free providers [1] and probably should to reduce the risk of people being censored. Much like IRC people can create their own little private or semi-private linked NNTP servers to replicate a distributed thread based forum of sorts.
[1] - https://www.eternal-september.org/index.php?showpage=peering
Should be easy enough to do the math: https://netsplit.de/networks/
Keep the needle pointing north. Towards the center of that dial.
Too decentralized, and you can't find anything. Nobody uses it.
Too centralized, and censorship takes over. Nobody can speak freely.
I don't disagree but I do wonder if a.) discoverability is really so intractable in a decentralized environment if you're willing to throw a lot of resources towards indexing and b.) if that middle ground isn't like balancing a pendulum upside down - a very fragile equilibrium. A bunch of decentralized units might join together, or a large centralized unit might fail, pushing the pendulum to either side.
You can think of the golden age of blogs and search as an example of both. Search engines formed a centralized hub with blogs, forums, etc. forming the spokes. For a while that worked well before it was degraded by spam and consolidation of disparate forums etc. into a handful of major platforms (fueled partly be acquisitions).
The fediverse folks are violently against any efforts for discoverability. They like the high bar for discovering and joining. Any attempt gets brigaded and shut down quickly
Some are. That doesn't mean they can do anything about it.
Remember, "the fediverse" is a bit like saying "the internet". "Internet folks are against centralization." Are they?
They're against opt-out discovery, not discovery in general.
Given how toxic big tent communities like Twitter can get, I think that makes perfect sense for some communities. Some plants thrive in full sun, some plants thrive in the shade. Some social interactions happen in the town square and some happen at more intimate functions.
That's a good point. Thiel's "Zero to One" makes it.
In economics, a market needs several reasonably strong businesses to get price competition. An EU study indicated that the minimum number is about 4. Below 4, price competition seems to disappear and you have oligopoly, or, at 1, monopoly.
In areas where there's no inherent effect like distance to stop centralization, markets tend towards oligopoly. Look at the number of browsers, the number of big banks, the number of cellular phone companies, and so forth. They're all between 2 and 4. The stable state seems to be around 3 big players.
This probably applies to social networks. There's only so much attention available.
Fediverse makes the indexing question interesting because some people don't want it deeply indexed: they point to the practice of dredging up old opinions on Twitter as an anti-pattern that the tooling should not support. Indexing without permission is met with hostility / defederation over there, and both individuals and server owners have tools to switch fine-grained indexing on and off.
(It is, of course, fundamentally impossible to keep people from indexing a default-open network, but if one does it, one does not advertise doing it outside the service-supported mechanisms).
> In economics, values below 100 are considered "Highly Competitive", below 1500 is "Unconcentrated", and above 2500 is considered "Highly Concentrated".
Fediverse is almost straight left, and it's already 690. Straight up would be 5000. This is non-linear scale presented linearly.
You're presupposing that discoverability requires some degree of centralization.
We haven't seen a distributed Google yet.
It's not impossible, but each distributed component would have to be at least a small data center.
Google search does a lot more complex processing (crawling, historical weighting) and it does it on unstructured pages. Discoveravility in a microblogging system doesn't have to be a lot more than indexing/collation of structured posts, and end-user clients can be designed to participate in that. "Retweets"/"boosts" are already a form of that.
Sure, but fediverse numbers are pitiful at this point. Reality is that 99.9% of users don't care about decentralization, so it ends up being a "this has to work as well as a centralized system" does.
> We haven't seen a distributed Google
https://yacy.net
You can index your own stuff and propagate that index to others. This is what people would have thought good when Gopher was a thing.
“Too decentralized” critics should form a non-profit where public hosts can register and build an opt-in index for all the decentralized content. Then there is no discoverability issue.
I wouldn’t be surprised if Facebook tries to eventually capture that data with Threads.
Mastodon (the company) is building one: https://www.fediscovery.org/
Yes, I think that would be smart of them.
Informed Voluntary choice is what I want to see. Give me the option to pick, centralized, decentralized or hybrid balanced.
One of the nice things about mastodon is that the total lack of centralization and the absence of the dreaded algorithm means you don't have reputation farmer accounts posting bloviating nonsense the whole time. Its really great there.
Mastodon is social like a quiet pub. Twitter and Bluesky are social like a crowd at a concert.
> Mastodon is social like a quiet pub. Twitter and Bluesky are social like a crowd at a concert.
Good analogy. When Twitter started, I took one look at people shouting "I had a delicious sandwich today" and "I just took an amazing dump" and wanted no part of it. When it later turned into a "clever" contest, I wanted even less.
My quiet little Mastodon community, plus some outsiders I have chosen, is the kind of "social" I want. If someone starts behaving like an influencer, they get muted.
HHI is a pretty interesting metric. It’s calculated by taking each firm’s market share, squaring it, and summing across all firms.
This gives the probability that two randomly chosen customers belong to the same firm.
In one micro models of oligopoly, Cournot competition, it lines up directly with the markup firms can sustain.
Outside of theory, it’s an intuitive way to average together the market power of all firms, with increases in market share for bigger players being weighted more heavily.
The universities need to get together and develop their own open-source search engine as part of an ongoing research project. It should be hosted in a distributed fashion from the universities themselves. They have the expertise and the resources these days to do it. And much of the high quality content on the public web originates from the universities anyway. It will be like the Library of Alexandria and not subject to censorship.
It's so funny watching Bluesky fans defend their almost entirely centralized platform as decentralized just because it has a spec
"Decentralization" isn't the end-goal so measuring it here isn't all that meaningful. Personally, I care about:
1. How hard is it to censor the network.
2. How hard would it be for some major player to enshittify the network.
Furthermore, while the fediverse has a single axis for decentralization, BlueSky has 3: number of "big index servers", number of PDSs, number of domain names (how many people own their handle):
1. Increasing the number of PDSs doesn't make it harder to censor the network when everyone still uses the same big index node.
2. BlueSky's primary defense against enshittification is user account portability. I'd love to see metrics on how many users have their own domain names. Having many PDSs is also a good defense here because it reduces the impact of BlueSky (the company) shutting off the firehose, but I still think account portability is the primary defense here.
> “ Decentralization" isn't the end-goal…
it would be high in my list of desirability because decentralization means agency to move freely.
i like the fact that if i find the city or state i live in to be boring or economically terrible, i can move.
i like it that if i don’t like the food or atmosphere of a restaurant, i can go to a different restaurant.
i like that if i think billy is a constant asshole, me and my friends can move to the next table over and leave billy behind.
social networks are absolutely no different, no matter how hard certain people try to convince online is different, it isn’t.
we should be soooo incredibly leery of anyone who tells us it’s a good thing to have no agency to eat different food or go party at a different bar.
the hair on the back of our neck should stand up every time someone tries to convince us to go to only a couple of places with the same set of rulers and tries to convince us this is somehow good for us.
how many times have you heard “you want to avoid echo chambers” followed by “therefor everyone should all be on the exact same set of websites with the same set of rulers” followed by “anything less than everyone on the same site is a failure”
it’s double speak: if you are not trapped here, you have an echo chamber.
freedom of movement, freedom of association, etc… are incredibly important to the future health of the internet.
BlueSky's primary defense against enshittification is user account portability.
I wonder if people would actually migrate or if they'd just get boiled.
I made a Bluesky account. I posted some pretty boring replies to pretty boring posts, and still got banned. They didn't tell me why I was banned. I didn't bother trying to make my account immune from banning; I just quit since it was pretty boring there anyway. That's one data point against the migration hypothesis.
Bluesky isn't decentralized, anyway, because of the PLC directory.
Depends on if they had something compelling to migrate to.
The honest truth is that:
Nobody outside tech cares about decentralization or federation.
At some point, everything converges to centralization.
No amount of Mastodon servers or any fediverse self hosted instances spun up will change that.
There is a reason that mastodon.social is the biggest instance and that they couldn't close registrations to promote decentralization.
Hell, I would even say that threads is the biggest mastodon instance.
This just doesn't seem to sink in with a lot of people.
The very second most people need to think about implementation details, like what instance is connected to what instance and what that means, they're done. It's not like they couldn't understand it if they tried: they don't want to try because they don't care. In fact, they don't want to care.
What they care about is interacting with their friends and family and celebrity personas that amuse them, and also get some news handed to them that fits their world view. They don't want to have a little independent social network-- they want to connect with whoever they want to connect with and access whoever they want to access and any barrier to that makes it worse for them. The centralization is the selling point for a lot of those people. Being at the terminal point in a federated service, as they exist, makes all of that harder. It makes it harder for great reasons but they're reasons that most people don't even want to care about. They trade good, easy experiences with the things that are important to them for things they never wanted and have no interest in learning about. Nerds get a kick out of being on a decentralized social network. Most people absolutely do not care. It's not like they don't want to be: it just doesn't matter to them, so if they have to give literally anything up to achieve that, it's too high of a cost.
It's almost like trying to get people to switch from mobile phones to amateur radio.
spot on, same reason irc never spread to the masses
That’s a solid comparison
SMTP, HTTP, DNS, routing protocols work pretty well despite decentralization/federation. Their "problem" is their greatest strength: they're stupidly simple.
E-mail is really ingenious. It doesn't even define how to send and receive messages in the same standard. One standard is just for delivering messages; you have to figure out how you're going to receive them separately.
Of course most people have an e-mail address hosted by one of a handful of large companies. But you don't have to. And if you buy your own domain, changing providers is easy. Delete your old mail on the old server, upload it to the new server, people can still contact you the same way they did before.
I'm not on social media, so I don't have any dog in this fight. But all the properties of a good decentralized/federated platform are already there in decades-old protocols.
I agree that many people do not care, but I don't think this is a tech problem.
In the real world, you can ask people if they would prefer to live in a town with all bespoke mom'n'pop businesses or just a few big box retailers and chain restaurants identical to the ones in the next town over. The intuitive expectation might be that most people would prefer the bespoke stuff because it offers a more personalized service, but it turns out that many people really do want to have the same experience as folks in the next town over. Even among folks who claim to be free thinkers or unique personalities, even among folks who have xenophobia or express a chavinistic sentiment, there is still an impulse to seek the exact same experiences that folks outside of their community are also having. Why is that?
I am sure there are various psychological and perhaps even physiological reasons why people are drawn to homogeneity, but the bigger problem is that bad actors can find ways to exploit these reasons to amass power. Once those actors have the power to shape society, then it becomes a feedback loop where perhaps in the abstract a person might not desire exactly those experiences that are provided by the central authority, but because the structures in society are now pointing toward that being the "best" option, then that's what people come to believe they want.
I suppose the philosophical question is if people come to want to be exploited, is it still okay to exploit them? Personally I think it's not okay. I think it's a worthy goal to present other options. In an ideal world, perhaps there would be structures in society that define open standards that allow people to find the homogeneous experiences they value while still ensuring that no central authority could take ownership over the delivery of those experiences. Perhaps there should be some assurance that those who deliver the experiences aren't also using other levers at their disposal to engineer the desire for those experiences in the first place.
Which is all to say that perhaps social media should be better regulated, and as nerds we might think that one way to do that is build it into the base technology as decentralization or federation. But one would hope that people outside of tech could at least understand the value, since the tech is just a model of real-world systems.
Users only care about content, how it's brought to them is inconsequential to 99.9% (likely higher) of users.
The chicken and egg problem is that users go where the content is, and content goes where users are.
In reality what this means is that the vast majority of both users and content tend towards a single solution, and that is where there is the least friction, aka the path of least reesistance.
Monetary incentives and various perks (features, first mover advantage, ...) can help but overall it seems to tend towards ease of use.
For users, TikTok is the king for a reason: EVERY SINGLE SWIPE (caps because I want to intentionally put a LOT of emphasis on this) is content that YOU, specifically YOU, are likely interested in. If not, the very next swipe is likely to be what your brain thinks is good, because the algorithm is so good it already knows what you want. Yeah, I know, that's because they spy on their users, whatever, sadly users do not care about that.
BlueSky? Even if you follow specific users, content discovery is so, so much harder. But the main problem is that the vast majority of users, especially new ones, will be subjected to subpar content compared to other platforms.
So why should a new user come back there instead of literally anywhere else? And if there are no users, why put the content there, and if there is no content, there are no users, and so on...
Notice how in all of this the underlying architecture has quite literally no relevance and is nothing but a technical detail.
This is true, but also the reason why it can get pretty cozy. Find the right corner - it will be sleepy - no need to check it constantly.
> Hell, I would even say that threads is the biggest mastodon instance.
So is Truth Social. But they are not federated with the rest.
> Nobody outside tech cares about decentralization or federation.
People outside tech very much do care about the effects of centralization, though. They complain about it constantly, in oblique terms.
All the waxing poetic about "social media"? They aren't mad that people talk to each other. They're mad at platforms.
They just don't recognize the root cause of their pain points until they're sufficiently technical.
> Nobody outside tech cares about decentralization or federation.
Until the platform enshittifies like Reddit and Twitter did.
Still no one cares. They just hop to the next centralized platform that hasn't enshittified yet. As we are seeing now with Bluesky.
Perhaps the idea of decentralization was incorrect to begin with, an NI hallucination - perhaps it should be all about centralization-hopping instead. I believe this is what Nostr aims for, though I've never used it.
Nostr is a bit different - you own a private key that signs any message (and action, but it's all JSON blobs) locally in your app and then you just broadcast these signed messages to servers ("relays") that cache and relay these to other relays or users. Other users can use your public key to cryptographically verify that the message is from you. The benefit is that you fully own your data, you can later decide to rebroadcast it to any other set of relays. It's common to have e.g. 20 relays connected from your app.
There is a group of people that care and use it and it works well.
One argument could be made here that decentralization also means that there will be variety of different protocols and solutions and that's ok.
> Still no one cares. They just hop to the next centralized platform
It's a wrong interpretation. Since they leave, they obviously care. They just don't know that decentralized platforms offer long-term solution.
> They just don't know that decentralized platforms offer long-term solution.
The crux is that most "decentralized" platforms don't offer long-term solution either. The whole concept of Federation only works as long as everybody is nice to each other, once that stops happening or bus-factor kicks in, you are back to all the problems of centralization and lock-in, since everybody is a user on a server they don't control. It's really no different from early Twitter or Reddit days when everything was nice and open until it suddenly wasn't.
Platforms that are actually build for true decentralization, where the user owns everything and the server owns nothing (public key crypto + dumb relay servers), are still extremely rare. Nostr is one that seems to be on the right track, but that's about the only one I can think of.
> The whole concept of Federation only works as long as everybody is nice to each other
I don't see how it can be true. Is everybody nice to each other on the Internet? On Mastodon, disagreements lead to independent islands not federating with each other, which is fine, too.
> Is everybody nice to each other on the Internet?
For most part, yes. ISPs still carry traffic as is and don't just block random hosts because they don't like them. This is however slowly changing in Europe due to ever increasing censorship and age verification. The Great Firewall of China hasn't been nice either. And Claudflare has also become rather annoying with its constant never ending CAPTCHAs.
> On Mastodon, disagreements lead to independent islands not federating with each other, which is fine, too.
How is that different from Twitter, Facebook or any other centralized service? All of them are just independent island that don't federate with each other. If that's ok, what problem is federation solving exactly?
To me the goal of decentralization is "Get rid of the middle man between me and my audience". Federation ain't doing that, it puts far too much control in the hands of the server.
> How is that different from Twitter, Facebook or any other centralized service?
1. You can make your own server federating with anyone you want. This achieves your goal, doesn't it? And, like everything, it has its cost.
2. You can freely move between the islands. Keeping the essentials like followers, known structure of the system. This forces the servers to compete and prevents creation of walled gardens and enshittification like with Twitter and Facebook.
Same effects work in the Internet itself, which made it survive to a large degree free to this day. Facebook and Twitter, as you noticed are those similar islands. Mastodon achieves a similar, decentralized structure on a lower level, increasing the resilience further and making it easier to move between the islands and create your own one.
Decentralization obviously doesn't on its own protect anything from the governments, but it helps.
> This achieves your goal, doesn't it?
Running a server isn't practical for average people. It's also nothing new, people could do since the dawn of the Internet, they don't need a Fediverse for that.
> You can freely move between the islands.
I can freely move between Facebook and Twitter too. Again, not seeing what the Fediverse is doing here for me. The Fediverse does not prevent walled gardens, the federation is an optional server-provided feature that can be switched off any time they want. You can't even move your data from one server to the other unless both servers cooperate.
And Lemmy specifically isn't even GDPR compliant, there is no way to export my comments in the UI. There are also other huge issues such as message-ids being tied to the server, so you can't even resolve a URL from one server with another (something Usenet did better 40 years ago, which is why I can still find old post today).
> Mastodon achieves a similar
If Mastodon decides to run ads and enshittify, it's just like Twitter again. There is nothing to prevent that, outside of being small and unpopular.
> Decentralization obviously doesn't on its own protect anything from the governments, but it helps.
I am not worried about the government, I am worried about overzealous mods and server admins, who are already running rampant on the Fediverse and the Fediverse provides no infrastructure to help me here. That's an area where I much prefer Twitter and Co., they are pretty hands-off with moderation as long as you don't violate the law. On the Fediverse thought-policing is getting sold as a feature.
> If Mastodon decides
There is not entity "Mastodon" that could decide anything. It's like saying "if the Internet decides to show you ads". It's a meaningless phrase.
> there is no way to export my comments in the UI
It's just a technical, UI problem, which anybody can solve, as it's free software.
> Running a server isn't practical for average people.
This is not the point. Like with repairs, you don't have to know how to do it to benefit from the right to repair. You can pay anybody in the free market to do your repairs or set up a Mastodon (or web) server for you. This solves the monopoly problem even for ordinary people. This is why you need free software btw - and it's not the case with Facebook or Twitter. You can't freely move between them. Once you leave them, you loose all your followers and specific features.
> That's an area where I much prefer Twitter and Co., they are pretty hands-off with moderation as long as you don't violate the law
This is not even funny. Twitter promotes nazi content according to the latest investigations.
> There is not entity "Mastodon" that could decide anything.
mastodon.social is a server, if you have an account on there, they can delete it. If you don't have an account there, they can still block you by defederating whatever server you are on. This is no different from Twitter and Co. Simply put, look at this from an angle when it goes wrong, not when they go right.
> It's just a technical, UI problem, which anybody can solve, as it's free software.
No, that's a fundamental problem with how the data is organized and distributed. Without cryptographic signatures and unique message-ids, you are slave to the server, even if you get the data out of the server, there is no way to get it up on another. To see how broken the situation is just look at the URLs:
- https://feddit.org/post/18147843 - https://lemmy.zip/post/47572103
Can you tell that both are referring to the same post? Can you find the feddit.org post on lemmy.zip when feddit.org goes down? This is not a simple "we'll implement that later"-feature, but a fundamental oversight in how data and control gets handled in the Fediverse. That it violates European law, that explicitly exists to empower the user, ain't helping.
> This is why you need free software btw
Free Software is completely irrelevant here. This is about protocols, data ownership and control, areas that no Free Software license even touches on. It's somewhat ironic that GDPR got there first with actual law, while the Free Software world still completely fails to address those issues, despite them being around for 20 years.
> You can pay anybody in the free market to do your repairs or set up a Mastodon (or web) server for you.
Which is worthless, since the value is in the users and their connections, which are under the control of whoever is running the popular instances, not me.
> You can't freely move between them.
I can freely switch between facebook.com or x.com in my browser just fine.
> Once you leave them, you loose all your followers and specific features.
Yes, that's just the same on the Fediverse. When feddit.de went down, where did my data go? My feddit.de account doesn't work on other servers. feddit.org was recreated from scratch and everybody had to move over manually. Account migration requires two cooperating servers, which you don't have if one of them is down permanently.
> This is not even funny. Twitter promotes nazi content according to the latest investigations.
As said "On the Fediverse thought-policing is getting sold as a feature."
mastodon isn't mastodon.social, and you also want to be thought policed unless you want to view child porn every time you log in (there are mastodon servers for pedophiles to share child porn)
It's a common mistake of programmers to treat business as something long-term. Saying "don't do XYZ because it'll stop working in a year once they catch on and block you. Business leaders are stupid for doing XYZ." Yeah, so that means you still made a profit for a year, and business leaders are not stupid for doing it. A year later, there could be a different thing that will work for another year. Changing what you do every year or even more often is just normal business. You don't have to find one thing that works indefinitely.
Maybe social media is like business.
Including Threads with Fediverse might have an interesting impact.
I agree. Even though the privacy control is opt in to share their posts with the fediverse, I think it's fair for Threads to be counted as a server in the fediverse holding user data. It just has more advanced privacy than others.
Threads barely interchanges with the rest of the Fediverse, it's basically bridged. By this argument you could include Truth Social and Gab, which are directly based on Mastodon source.
adding Threads's 400M users changes the ActivityPub fediverse centralized market share to 99.72%, beyond that of BlueSky's share of 99.55%.
> This page measures the concentration of the Fediverse and the Atmosphere according to the Herfindahl–Hirschman Index (HHI), an indicator from economics used to measure competition between firms in an industry. Mathematically, HHI is the sum of the squares of market shares of all servers.
I had not heard of this metric before - it’s neat and simple to understand. If you scaled it down to 0-100 (by dividing by 100), I think it would make the numbers more immediately understandable. I’d even consider inverting it (so 0 = centralized and 100 = decentralized), since the website title implies measuring progress ‘towards’ decentralization.
OTOH the reason why they didn't normalize to 100 may be to not give people an idea that the measure is linear; seeing a score of 2500 makes you ask 'what does it mean?' whereas if you were presented with 25/100 you probably wouldn't think that it is 'highly concentrated'.
Mastodon has been great so far
It would be great to add nostr, but nostr doesn't really match this model. Nostr doesn't need a single server to hold your identity, your app connects to many "relays" at the same time.
https://atproto.wiki/en/working-groups/indiesky/stack
multiple different levels of independence to be had in the atmosphere, so it's not directly comparable (doesn't help atmosphere's case though)
i personally am more excited about ATproto as a protocol, and hope https://freeourfeeds.com/ et al can pull it off
So why not just wordpress and rss?
We've had the protocols and tech for decentralized services for 20+ years. The problem isn't the tech, it's the users! Your average Joe simply doesn't have 'must be decentralized' in their requirements. I'm guessing this is due to lack of education on the matter.
But, yes I agree with you :)
ActivityPub is basically just less simple RSS.
and track follows.
Wonder how one could calculate email concentration.
Personal data detached from the rest is not measured, so I think it’s not realistic to try to determine whether everyone is decentralized. Use of a central decentralized app like Bluesky is not a good approximation imo.
Matrix needs to also be included in this.
Matrix is fancier than mastodon, but more decentralized than AT Proto.
Yeah but it is NOT VC funded! So it doesn't get as much coverage.
Can someone explain how Fediverse instances or any decentralized platforms deals with most obvious issues of decentralization? Like if I join some node then one day it's offline and all my data lost. I mean surely instances usually don't disappear without notice but it still a totally possible thing. Or what about those times when entire instances get involved in dramas and end up defederating? I don't want to lose my connection with potential friends from such instance just because of something like that. I even remember some time ago when there were news about Threads being federated some people deliberately gathered "signs" across lots of instances to collectively defederate from Threads and it's just ridiculous to me that this even happened. What all this talk about fighting censorship while actively engaging in constant "self-censorship" making own echo-chamber as tight as possible?
In ATProto, this is solved by not having "instances". Your data is stored on a personal server (which can ofc go down). However, your identity isn't hard-tied to that server. If you have a backup (making those more easily available is being worked on by people in the ecosystem), you can restore it on another host and point your identity there instead. So there's one level of indirection which prevents the problem you're describing.
Additionally, since ATProto decouples hosting of data from hosting of applications, there is no such things as "instances" having beefs and defederating from each other. The data flows one way (from PDS to apps). Apps may choose to ban certain PDS's but generally PDS's themselves are treated as app-agnostic containers of data. So intra-network social beefs don't translate to technological cutoff or loss of mobility. Social groups and communities are decoupled from hosting.
> Like if I join some node then one day it's offline and all my data lost. I mean surely instances usually don't disappear without notice but it still a totally possible thing.
This happened to me with julialang.social which just stopped running after the guy hired to host it was poached by Google and he lost all interest in the Julia language community. Lost everything. Not going to look back at activitypub as ATProto is the future for me.
> Like if I join some node then one day it's offline and all my data lost
They just disappear. You're not appending to a long-term immutable blockchain-like archive. You're posting things to the internet and the nature of posting things to the internet (or anywhere for that matter) is that nobody guarantees they will be around forever.
> Or what about those times when entire instances get involved in dramas and end up defederating
Identical to "what about those times when Twitter bans someone whose tweets I want to read?"
> What all this talk about fighting censorship while actively engaging
Censorship and moderation are the same word
would be awesome if they added nostr to the list, too.
mastodon is the equivalent of bsd code, but for user generated content.
Microsoft and apple would just reach for bsd tcp stack etc. today bluesky just "federate" to mastodon and instantly had millions of active users, until they don't need to federate anymore, when they will blame the other instances to not migrating to some crazy protocol or something, never they will just "shut the door".
I think this compares AT proto PDSes to Fediverse instances. In many ways this actually underplays just how grossly centralized AT proto currently is, since some of the components are 100% centralized still. (Whereas Fediverse instances, all downsides considered, are at least self-contained fully-independent instances.)
Which components are you referring to?
In case of Bluesky, there will also only ever be a single instance of the App View. As far as I am aware though in practice there's really only the official relay or indexing services either.
Why can't someone run another App View?
You can, it just won't be the Bluesky App View, so it's not really Bluesky. It's not like the fediverse where the instances own the URLs of the posts: they go through app views and there's a canonical URL to a Bluesky post and that's through the official app view.
This seems misleading.
Different AppViews would obviously be branded differently, but the whole point of ATProto is that there is a shared "picture" of the world. People are running alternative AppViews that consume Bluesky posts (and serve Bluesky threads).
Here's the same thread on three different AppViews:
- https://zeppelin.social/profile/did:plc:iyz5zf463ic52vqbonyu...
- https://blacksky.community/profile/did:plc:iyz5zf463ic52vqbo...
- https://bsky.app/profile/did:plc:iyz5zf463ic52vqbonyu2ebu/po...
These are three independent webapps indexing the same information and serving it independently. They're not different frontends for one API; these are all independent backends.
one important correction is that blacksky is not hosting their own appview, they host their own PDS for users to join and a soft-fork of the official client
Ah, apologies, thanks! Lemme edit.
Actually it doesn't look like I'm able to edit anymore, so I'll upvote your comment.
So, it's the same underlying data structures (e.g. posts, threads, etc.), and the way they're exposed depends on the implementation? So there's one BlueSky, but BlueSky is just one interface (UI + API). Am I getting this right?
I just want to know if I can run my own node in my own hardware.
You can think of ATProto like this.
Each user has a "website" with JSON of their own content (e.g. all my posts, all my likes, all my follows, actually live in a sqlite database hosted somewhere). It's not really a website but more like a git repo — one per user.
And then, there's a protocol for how to aggregate information from all such "websites" in the network into a stream of changes. Apps subscribe to that stream of changes and update their local databases (which act as app-specific caches) in response to those events.
When I make a Bluesky post, I'm really writing JSON into my sqlite file. This change gets broadcasted to all interested apps which update their own databases (which may or may not care about specific content type like "Bluesky post"). Obviously forks of Bluesky backend do index Bluesky posts (and then return them in the same UI), but you could imagine other backends that only care about other content types, or that record Bluesky posts but in a different database structure, and ofc can present a different UI for it.
Yes, you can run your own node — multiple types of nodes. You run your own PDS (https://github.com/bluesky-social/pds) to store own data (that's the "website" in my analogy), or you could run a Relay (https://whtwnd.com/bnewbold.net/3lo7a2a4qxg2l) that collects all PDS changes into a stream, or you could run an AppView (any backend that listens to Relay or PDS, basically your own app).
What is zeppelin.social? Who runs it? They don’t seem to have an about page.
https://whtwnd.com/futur.blue/3ls7sbvpsqc2w
Edit: I think the author’s server may be busted or something. The link should be correct though. I’ll ping them. The announcement is at https://bsky.app/profile/futur.blue/post/3lsc2tzfsys2f
OK, to be honest, I'm surprised anyone runs a third-party Bluesky AppView even just as a curiosity. I genuinely can't understand why anyone would run one of these except as a raw curiosity.
If 99% of the people are using the default AppView, the default relay, the default indexers, the default PDSes, etc, etc... that just means that everything that almost the entire userbase sees is completely controlled by one entity. It's technically possible for people to use alternative services, but the community would have to wrestle the majority control of the network away from Bluesky Social PBC for it to really matter. Running an alternate PDS or even AppView seems like mostly a symbolic gesture since whether anyone can actually see your posts is still up to the whims of one entity, just like Twitter, and that's partly because there's no way to really "own" the URLs of your posts or profile. The canonical URLs are one domain owned by one company. The others are just alternatives.
But:
> the whole point of ATProto is that there is a shared "picture" of the world
I think everyone does understand that ATProto "solves" some of the problems with decentralization that you can observe from the Fediverse, but when you look at the practical reality of ATProto, it's hard to figure out exactly what aspect of decentralization users are supposed to be able to still benefit from. The whole thing could be re-centralized and literally 99% of all users wouldn't notice anything different. If you get censored by the entity running the primary AppView, or even deeper, you could theoretically run all of your own components... but then you'd just be talking to pretty much yourself. Even if you did succeed and somehow wrestled away a substantial portion of users, (which would be extremely expensive and impractical), now you just have the same split world that exists in the Fediverse, but with AppViews/moderation services. It kinda seems like the "shared picture of the world" concept is actually somewhat incompatible with having an actual decentralized network where users meaningfully have control.
P.S.: I know that mentioning censorship is automatically polarizing, but with Bluesky I really feel like I have good reason. I tried Bluesky briefly a long while back just out of raw curiosity, and I actually managed to get my account taken down with zero posts. I literally was just following some artists, mostly Japanese, and I assume one of them got banned for something NSFW. I'm not even sure I liked any posts that were NSFW. Needless to say once I got unbanned I just deleted my account and gave up on it. I wasn't really planning on using it for anything, so it's not like I am horribly offended by this, but it definitely gave me an idea of how Bluesky Social PBC moderates. No thanks.
Having multiple implementations available is an important step towards decentralization, even if most people don’t use them yet. It shows that it’s technically feasible and will help shake out any bugs.
Getting people to actually switch will be harder, and presumably it would involve both promoting the alternatives and adding features that some users will find attractive.
The issue is that Bluesky did their big public launch long before anyone could even run their own PDSes. Instead, they spent a bunch of time working on shit like integrating Namecheap for DIDs. And if you use Bluesky to go and create a DID and set up a domain for it... it will be a centralized DID managed by plc.directory, which is also ran by Bluesky Social PBC, and you can't run your own equivalent of plc.directory, and the alternative DID method that is still supported is used by basically nobody.
Technically people can run their own components for most things, but everyone just knows bsky.app. What's the point? You're never beating them in Google Search. You're never gaining critical mass. People are just going to be really confused at why there are multiple domains that have the same content, and I imagine search indexes will be confused by that, too, probably massively deranking any of the alternatives.
This all makes running your own Bluesky components pretty self-defeating. You can go through all of the effort to have parallel infrastructure for Bluesky, only for an AppView that is doomed to be irrelevant. 99.99% of everyone you interact with is on Bluesky Social PBC's centralized infrastructure anyways and there's basically no chance of that changing. And unlike Bluesky, you don't have shit loads of investor money to spend, certainly not the $15 million that Blockchain Capital invested in Bluesky Social PBC last year.
I think Bluesky Social PBC was well aware of all of this and chose to launch this way anyways, because they absolutely did not have decentralization as a priority. And yes, I know that users on Hacker News are screaming at the top of their lungs, "Users shouldn't care! Users shouldn't care!" But guess what, Users actually cared. People were pissed off about Twitter and wanted a durable alternative that wasn't plagued by the fact that someone could just buy it and take control over the whole platform. Bluesky Social PBC sold Bluesky as a better decentralized alternative to Twitter.
For all of this performative effort though, it's all worthless. Someone could buy Bluesky and immediately close all of the doors; stop allowing new external PDSes and start closing off access to relays/etc. from anyone else. There's not really any reason to actually do that right now, since decentralization is not even a threat to Bluesky Social PBC's control over the network, and unless someone shows up with millions of dollars to blow on a network they don't even have the benefit of being the public face of, they really never have to worry about it anyways.
I criticized a lot of aspects of the Fediverse for a long time, but at least the Fediverse actually delivered on one thing: it actually really is practically decentralized, with all of the ups and downs that that comes with. Users are distributed across instances, so there is no central gatekeeper that would stop me from talking with them. You can almost always avoid any instance-related drama by just running your own instance and interacting from there, if you want. Bluesky will never have that. For Bluesky, users that Bluesky Social PBC doesn't like will be invisible to the vast majority of the rest of the network.
And I'm sorry, but that's not what a decentralized network looks like.
> [...] It's technically possible for people to use alternative services, but the community would have to wrestle the majority control of the network away from Bluesky Social PBC for it to really matter. [...]
> [...] now you just have the same split world that exists in the Fediverse, but with AppViews/moderation services. It kinda seems like the "shared picture of the world" concept is actually somewhat incompatible with having an actual decentralized network where users meaningfully have control.
I think an illustrative example of how a "community split" can happen is Blacksky[1]. It used to only be a custom feed but now have their own client app, their own moderation services, their own relay for their internal services, their own PDS for hosting their accounts, and to the best of my knowledge they want to set up their own Bluesky AppView at some point. With their own AppView, whenever a user is logged in to their client app they'd be using Blacksky's AppView, and anytime they're logged in to bsky.app they're using Bluesky's AppView. A user doesn't need to configure anything, they just download an app and log in with their existing account, and they can be logged into both apps at the same time. Compared to moving your account, to a new home server for Mastodon or even to a new PDS with atproto, it is very simple for your average user to use another AppView.
The "control" users have here isn't that they can control everything that happens within one app, it's that they're not limited to one app or one backend, and that communities of users can meaningfully run their own services if they're not being properly served by the existing alternatives, all while they still seamlessly get a fully global view of every Bluesky user and post.
And hell, atproto is very modular. People have made clients[2] that connect directly to users' PDSs and some "backlink" service like Constellation[3] (to get all likes, replies, etc.), which is much cheaper to run, skipping a Bluesky-compatible AppView entirely. There's also AppViewLite[4] which is a partial Bluesky AppView that's tailor-made for self-hosting.
Having all users, all posts, all data just be available globally to everyone means that you can create very novel and experimental decentralized services and apps. That is personally what excites me the most about atproto and how I see "user choice" be best served. How about a censorship-resistant client app more reminiscent of nostr that connects to multiple Bluesky Appviews and combines the resulting data? Or how about some ActivityPub-like AppView where small communities run their own homes and ping each other whenever there is new activity, eschewing a relay altogether. Everything is possible with atproto, and all of these services would create data existing globally for every other service and user, that can be interoperably viewed and created by any other atproto app that wants to do so.
> I literally was just following some artists, mostly Japanese, and I assume one of them got banned for something NSFW.
I'm personally one of the largest critics of how Bluesky Social PBC treat Japanese anime-style illustrators, so I share your frustration here. Though it's worth noting that large Mastodon instances do the same kind of moderation. Trying to follow illustrators on misskey.io from mastodon.social is very much a toin coss if they're censored or not.
One of my hopes is that we will eventually get the Bluesky AppView equivalent to Pawoo/Misskey. Ideally that one would create records compatible both with Bluesky and some new Pixiv-style atproto app. Then users could set up *booru sites too which work on the same underlying data as what the artists upload, i.e. the artist would keep control over the data. That kind of interoperability makes for a much more interesting web!
[1] https://blackskyweb.xyz/ [2] https://reddwarf.whey.party/ [3] https://www.microcosm.blue/ [4] https://github.com/alnkesq/AppViewLite
> I'm personally one of the largest critics of how Bluesky Social PBC treat Japanese anime-style illustrators, so I share your frustration here. Though it's worth noting that large Mastodon instances do the same kind of moderation. Trying to follow illustrators on misskey.io from mastodon.social is very much a toin coss if they're censored or not.
I can't stress this enough: I don't find it acceptable to ban people if they like posts or follow someone who gets banned. That sort of guilt-by-association is insane. It's one thing to be more censorial than Twitter, which is a choice you can make if you want to, but Bluesky went many steps way too far in how they enforce the rules. I still can't even fathom what actually got me banned, and the cowards there would never admit it (because they know it was wrong.) The only way I'd ever consider going back is if they announced that they fired everyone who thought that was a good idea.
If they're willing to do insane shit like that, I would absolutely not trust any of the other aspects of the components ran by Bluesky Social PBC, so it's far more than an AppView that is needed for sure.
Then there's the fact that Bluesky Social PBC constantly advertised itself as a decentralized alternative to Twitter back before it had launched, well, any decentralized components. Before you could run your own PDS, and certainly before they stopped requiring whitelisting. People make a lot of hooplah about how users shouldn't care about decentralization. Well, a lot of people leaving Twitter at the time did care about decentralization, because they were tired of what was happening to their Internet and wanted a durable alternative. To this day, Bluesky doesn't really actually practically have any of the properties of decentralization that anyone would care about. They know it damn well.
I hate that everybody is just going to let this happen, and I hate that Bluesky proponents jump in and try their hardest to make it seem like there's hope for things to not be controlled by one entity. There isn't. It's a complete load of shit.
> I can't stress this enough: I don't find it acceptable to ban people if they like posts or follow someone who gets banned.
To the best of my knowledge, that kind of banning has only happened once[1] (I was one of the handful caught up in it lol). They reversed that ban when I complained. Unless you were banned at that exact time, what likely happened to you is that some kind of anti-spam filter thought you were a suspicious new account, agnostic of the content of the posts/accounts.
> I hate that everybody is just going to let this happen, and I hate that Bluesky proponents jump in and try their hardest to make it seem like there's hope for things to not be controlled by one entity. There isn't. It's a complete load of shit.
There already are other apps working independently from all of Bluesky's infrastructure (save for plc.directory). I think the big thing holding the protocol back is that they have not implemented private data yet (and it's probably a couple years off). Lots of apps need that, so many apps would not want to use the protocol yet.
I'm hopeful about the future of the protocol, because it does provide the aspect of decentralization I value most: your account is a signed repo and a private key (or several), and the network is necessarily fully open for any app to make use of however they want. Even client-side single-page web apps are feasible with generic backlink services (Constellation), which I find super cool. All that is needed now is time and app development.
[1] https://bsky.app/profile/safety.bsky.app/post/3lbsqm7kfns23
> To the best of my knowledge, that kind of banning has only happened once[1] (I was one of the handful caught up in it lol). They reversed that ban when I complained. Unless you were banned at that exact time, what likely happened to you is that some kind of anti-spam filter thought you were a suspicious new account, agnostic of the content of the posts/accounts.
It was definitely around the time of that post. Here's the message I got around 10 months ago:
> Recently, we removed a Bluesky account you control for violations of our guidelines. After a thorough review, we have determined that the takedown action applied to your account was incorrect.
What struck me about this series of posts is how they still never acknowledged exactly what they did (which is, took down accounts using guilt-by-association) nor did they claim they wouldn't do it again, only that they made mistakes while doing it, and they didn't even bother to properly apologize for banning people incorrectly at any point. It reads as if they felt it was all fine and justified and that they will do it again, just, correctly this time, as if there is a right way to do that.
Even if they did stop this practice (again I truly doubt it), there are things you can do that, while they may feel reasonable and justifiable given the circumstances, are a permanent way to lose people's trust. For me this is one of them. I don't think anyone should feel safe hitting like on a post on Bluesky, unless you're absolutely sure it could never be found in violation of any rules. That's insane. Why would I want to be on any network controlled by Bluesky Social PDS when that's how they run it?
> There already are other apps working independently from all of Bluesky's infrastructure (save for plc.directory). I think the big thing holding the protocol back is that they have not implemented private data yet (and it's probably a couple years off). Lots of apps need that, so many apps would not want to use the protocol yet.
> I'm hopeful about the future of the protocol, because it does provide the aspect of decentralization I value most: your account is a signed repo and a private key (or several), and the network is necessarily fully open for any app to make use of however they want. Even client-side single-page web apps are feasible with generic backlink services (Constellation), which I find super cool. All that is needed now is time and app development.
I'm beyond bummed out because I was actually pretty excited for Bluesky early on, but I think they had a window that opened and closed for properly decentralizing. Bluesky today is a heavily curated and heavily moderated network that resembles absolutely nothing of what you would expect from a supposedly "decentralized" network, which is a load of shit for something whose entire draw was that in the first place. What they've created today is so centralized that they can feasibly close it off tomorrow without any impact on 99.9% of users. It's one thing to extol the virtues of its architecture, but that architecture hasn't really been proven to work well in a truly decentralized environment, which is not good when it has already been scaled to these heights. I don't just mean in terms of continuing to function and scale well, I mean in terms of how the network handles abuse and bad actors, and how Bluesky Social PBC will handle parts of the network that don't agree with their moderation policies. (i.e. Was it really wrong to spend so much time highlighting the issues with inconsistency in the Fediverse if ATProto winds up with the exact same issues where the world appears very different depending on what AppView you're on?)
While I admire Dan Abramov's work on React, his attempts to show that Bluesky decentralization is actually happening were to list two alternative AppViews, except apparently, one of them was actually not a full AppView instance. So actually, there is basically one known alternative AppView to Bluesky's AppView. Bluesky has something north of 38 million users, and approaching-100% of them are going to be using Bluesky's AppView. Given the utter lack of incentives to really run an alternative AppView, and the fact that nobody except complete and utter nerds will ever even find them, is there really any good reason to suspect that there will be any alternative AppViews in the long run, or if they exist, that any more than a tiny unimportant fraction of users will ever use them?
The Fediverse has had instances that have done dumb things, but the thing is, you can currently today actually choose any instance you want. A future where you can use Bluesky without the direct influence or control from Bluesky Social PDS in either your personal affairs or even just almost every single interaction you'll ever have is very distant. If we were to extrapolate, it doesn't seem likely the situation will have meaningfully changed in several years. I'd be willing to place bets that in 10 years at least 99% of users will still be on Bluesky Social PBC's main AppView. (To be honest, I wonder if anyone would actually be willing to place money on this bet. I kinda suspect even Bluesky proponents would admit that this is pretty likely.)
there is https://deer.social
This one isn't an AppView (it's a frontend for Bluesky's). However, https://blacksky.community/ and https://zeppelin.social/ are full AppViews.
Correction: Only https://zeppelin.social is. Blacksky runs a PDS and a Relay but not an AppView. My apologies.
>Mastodon, Pixelfed, etc.
I would like to know the contents of the "etc." list.
See https://fedidb.com/
Is the working? Some of stats are off by digits.
1: https://fedidb.com/servers/misskey.io
2: https://misskey.io/notes/a8y6w6zwbd950e9h
Isn't this always a problem of Marketing + UX?
How do these metrics compare with usenet circa ~1989
I thought Bluesky was federalized? How is it not?
The federal part doesn't actually work in practice. It's just a marketing gimmick.
This is factually wrong, and disproven by the fact there are now fully independent federated instances such as BlackSky and soon to be NorthSky. Furthermore, they have independent codebases which are fully compatible. Compare to ActivityPub where most instances are just running Mastodon or some close fork or risk breaking compatibility. What's the point of federation if you are stuck with a monoculture of implementations?
The main BlueSky services are still by far the most popular, which is why we see centralization on the network.
Mastodon is definitely not the only fediverse setup that is popular, Misskey, Pleroma and forks of those integrate perfectly well. Given that the main Misskey instance is one of the largest fediverse instances (certainly by activity) it seems a bit unfair to criticize the fediverse on this. I mean, how many completely independent microblogging implementations does a network actually need? (Not even including things like Lemmy or Peertube which are also ActivityPub instances.)
On the other hand I really think you're underselling how much more popular Bluesky services are than any existing alternatives. I don't think we can actually see the distribution of network traffic, but I would be willing to bet decent money that the sum of all alternatives to the Bluesky AppView wouldn't even crack 0.01% the traffic of the main Bluesky AppView. And, honestly, I would probably bet even more money they'll never even come close to cracking 1% ever for the entire lifetime of the protocol, unless Bluesky Social PBC literally goes out of business.
It is, but most people use the central server
Depressing
Sadly, and fortunately, there is no such thing as "avoiding centralization", the evidence is overwhelming:
== Politics & Sociology (power concentrates in organizations)
- Robert Michels, Political Parties (1911) origin of the "iron law of oligarchy": even democratic groups tend to end up run by a few: https://en.wikipedia.org/wiki/Iron_law_of_oligarchy
- Jo Freeman, "The Tyranny of Structurelessness" (1970/72): leaderless groups develop informal, unaccountable elites unless they make structure explicit: https://en.wikipedia.org/wiki/The_Tyranny_of_Structurelessne...
- Max Weber, bureaucracy & rational-legal authority: why modern societies gravitate to rule-bound, hierarchical administration: https://en.wikipedia.org/wiki/Rational-legal_authority
- James G. March & Herbert A. Simon, Organizations (1958): classics on bounded rationality and why attention/decision bottlenecks yield hierarchy: https://www.amazon.se/-/en/James-G-March/dp/0471567930
== Economics & Political Economy (why markets/platforms centralize)
- Ronald Coase, "The Nature of the Firm" (1937): firms exist (and grow) when internal coordination is cheaper than market exchange: https://onlinelibrary.wiley.com/doi/10.1111/j.1468-0335.1937...
- Oliver Williamson, Markets and Hierarchies (1975): transaction-cost economics: asset specificity & opportunism push activity into hierarchies: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=1496220
- W. Brian Arthur, "Increasing Returns and Lock-In" (1989): small early advantages + network effects => path-dependent monopolies: https://www.jstor.org/stable/2234208
- Katz & Shapiro, network effects (1985/1994): compatibility and standards help explain winner-take-most dynamics: https://faculty.haas.berkeley.edu/shapiro/systems.pdf
- Thomas Piketty, Capital in the Twenty-First Century (2014): when r > g, wealth concentrates; proposes progressive wealth taxation https://en.wikipedia.org/wiki/Capital_in_the_Twenty-First_Ce...
== Networks, Complexity & Information (why hubs and hierarchies emerge)
Albert-László Barabási, Linked (2002): preferential attachment makes networks develop hubs (central nodes) http://networksciencebook.com/chapter/5
Herbert A. Simon, "The Architecture of Complexity" (1962): complex systems often become hierarchical because modular hierarchies are easier to evolve and manage https://faculty.sites.iastate.edu/tesfatsi/archive/tesfatsi/...
W. Ross Ashby, "Law of Requisite Variety" (1956): controllers need at least as much "variety" as the environment and it often pushes toward central coordinating mechanisms (or many distributed ones with enough capacity) http://pcp.vub.ac.be/books/AshbyReqVar.pdf
Gilbert & Lynch, proof of the CAP theorem (2002): in distributed computing you can’t have perfect consistency + availability under network partitions and real systems centralize/compromise to cope: https://groups.csail.mit.edu/tds/papers/Gilbert/Brewer2.pdf
Robert K. Merton, "The Matthew Effect" (1968): cumulative advantage: success attracts more success, reinforcing centralization of recognition/resources https://garfield.library.upenn.edu/merton/matthew1.pdf
== State power, legibility & infrastructure (why governments centralize)
James C. Scott, Seeing Like a State (1998): states seek legibility and large projects favor central plans and standardized populations/landscapes https://en.wikipedia.org/wiki/Seeing_Like_a_State (literally anything by Jim Scott -RIP- will be useful)
Tim Wu, The Master Switch (2010): communications industries cycle from openness to centralized "information empires" https://www.amazon.com/Master-Switch-Rise-Information-Empire...
== Technology & platforms (contemporary centralization)
Nick Srnicek, Platform Capitalism (2017): explains how platform business models + data/network effects produce concentration https://www.wiley.com/en-us/Platform+Capitalism-p-9781509504...
== When decentralization can work
Elinor Ostrom, Governing the Commons (1990): shows conditions (clear rules, monitoring, graduated sanctions, polycentric governance) under which decentralized, federated management of shared resources succeed https://www.cambridge.org/core/books/governing-the-commons/A...
----
the literature making a counterpoint is abundant / overwhelming but that feels bleak considering when reading these works, systems thinking )the basis for "la technique") favors centralization
The Internet itself is decentralized, which made it extremely resilient. So is democracy.
> https://en.wikipedia.org/wiki/Iron_law_of_oligarchy
The article cites a few notable counterexamples like Wikipedia. Your post looks like learned helplessness.
> The Internet itself is decentralized, which made it extremely resilient. So is democracy.
extremely? i wouldn't bet on that.
how do you even measure that? books have been around for over a millenium, that's quite resilient. the internet is barely 50 years old. empires have lasted for thousands of years, modern democracies are a bit over a couple of centuries ... young. how do you determine their resilience? i see quite concerning signs of degradation lately, and they might have something to do with that iron law of oligarchy.
> The article cites a few notable counterexamples like Wikipedia.
no, it doesn't? it has a section titled "examples and exceptions", but it doesn't include any real exception (that has been resilient to this day), let alone a 'counterexample'.
> Your post looks like learned helplessness.
yours looks like wishful thinking (and difficulty in parsing the wikipedia)