Posted by danabramov 5 days ago
Atproto apps are not like an RSS reader that runs on the users' computers and connects directly to the sources of content.
Atproto apps are servers that control, filter and shape the content they serve to readers.
Atproto apps can censor, shadowban, show ads, algorithmize the feed into anything it wants. The user is powerless and the creator is a victim that can't do anything besides crying.
The fact that any person can host their data anywhere is completely meaningless since they have no way of distributing that data.
The difference is that it’s competitive. New apps can rise up that provide alternative lenses over the network. In the crudest case, literally showing everything. Which is what you wanted. Maybe that won’t get into an App Store but it definitely works if there’s demand for that.
Another way to look at it: the Twitter-brained perspective is that it's a good thing to build a system where everyone has access to everyone else all of the time - that the global firehose is a primary goal.
That notion is not universally agreed upon as desirable. Some folks and groups of folks value membranes with varying degrees of permeability.
With Mastodon, each instance is a self-contained community server with the option to link up with peers of similar shape. That this arrangement makes a whole-world view difficult is seen as a feature-not-bug by many users.
Also, since each instance is a self-contained complete unit of microblogging-shaped community, that means a relatively small technical team can host & maintain that unit for a decent-sized group of folks with relatively cheap cost.
Put a bunch of those together in federation, and you have a chance at a pretty well-distributed spread of moderators and caretakers. Depending on how any particular instance's funding and governance is setup, that can also result in members being more or less involved in the running of the place. (Which, also, is why some folks value being "belonging" to a particular instance.)
In ATProto, the "instance" is the complete stack you'd need to have ownership over the whole shebang. Some folks and communities value that. Versus Mastodon, Bluesky is just a much much bigger box.
You can also separate Mastodon from ActivityPub. You can make new apps atop ActivityPub - and folks are. Photos, videos, calendars, etc. It's based on JSON Linked Data, and that's expandable to other types of activities and data. If you really wanted to, you could make a great big all-encompassing app UX that handles everything. But, I guess no one's found that interesting enough for it to take off yet.
If there are advantages to ATProto over ActivityPub in this kind of deployment setting, they don't seem clear enough to offset the weird corporate parentage; like, I can see how Mastodon keeps chugging along no matter what companies get sold to who, but I don't see how ATProto survives the death of Bsky.
I still don't quite understand your comment.
>If there are advantages to ATProto over ActivityPub in this kind of deployment setting, they don't seem clear enough to offset the weird corporate parentage
The advantage of atproto is that it's literally "the web". Every app can aggregate from entire network, there's no isolation by default. It reduces to the degenerate smallest case just the same — you can have a single-user app that simply displays content from your PDS. But you can also start aggregating things (e.g. comments left by other users, which are stored on their PDS's). The whole big idea of atproto is that every app is effectively a CMS for app-agnostic "model" web.
What is the concrete thing bothering you? AT is already in the IETF process. It's not some weird corporate thing.
A "lite" version of Mastodon that dispensed with all of the complexity involved with managing multiple accounts and was optimized for a single user might be nice but with a hosted account you're paying for data storage (which Mastodon seems horribly inefficient with) so in practice that extra complexity is moot.
The thing there is it destroys the objection people have about having to find and fit in with a particular Mastodon server community.
It also makes Mastodon look more like the original blogosphere and less like Twitter, which is a good thing.
It is just an entire Mastodon instance with one account, though.
I mostly skipped over it because a Relay is an optimization and not essential to the shape of the network. It's not a fundamental element in the same way that PDS (hosting) and AppViews (app servers) are. It's more like a "next reasonable thing" an engineer would bolt on to make it easy to create apps.
An app can work without a Relay (like https://reddwarf.app/ does). There are caches like Constellation (https://constellation.microcosm.blue/) that you can just query directly.
A Relay is not an "instance" in any meaningful sense because it is a dumb retransmitter. It is cheap to run one, and it is easy to pool them between multiple apps. (Fun fact for nerds: the Relay's API for subscriptions is literally the same as a single server's. So a Relay is kind of a facade for "a bunch of servers" that lets you listen to their events combined.)
Early on (more than a year ago), running a Relay used to be more expensive because any Relay was expected to store the entire network archive. This is no longer a part of the contract, but a lot of discussions still reference or assume that. The current cost of running your own Relay (if you don't want to pool with anyone) is about $30/month. There are community-run Relays like https://firehose.network/ that you can use too.
I wonder why you are vagueposting here instead of stating your position firmly. Maybe because you are afraid to be shown wrong, but who knows ?
It's not centralized in any way that matters. The Relay Bluesky uses is open source, you can run your own for $30/month if you really insist on doing that, it's trivial to pool between multiple apps if you want to lower costs, and there are already a few independent ones you can just use directly now, for example:
- https://pdsls.dev/firehose?instance=wss%3A%2F%2Fatproto.afri...
- https://pdsls.dev/firehose?instance=wss%3A%2F%2Feurope.fireh...
There's only one PLC directory.
There's very few full relays (edit: appviews), none that I'm aware of that don't mirror bluesky censorship/moderation decisions.
- Re: PLC directory, indeed, there is only one of those. I think this is a legit point but it's worth considering the whole point of PLC directory is to be the single minimal stateless open source part that lifts identities out of apps and hostings. PLC governance and maintenance is being spun out into a Swiss organization (https://atproto.com/blog/plc-directory-org). Longer term the idea is for it to have a similar role to ICANN. Here's more on that: https://youtu.be/9z0z-Qu66yM?si=_8Dcw1M3VSKFGZhm&t=493
- Re: full Relays, they're easy/cheap to run, and you can run one yourself if you think the other ones are coordinating with Bluesky and don't trust their decisions. You don't need to depend on something else to do that.
And since that sounds like a massive centralization problem, how do we have a dozen more of them with independent governance that aren't all controlled by either the same legal entity or by whoever has legal leverage to compel that entity?
I get that it’s not ideal but I think it’s worth keeping in mind that there’s not much you can mess up with it other than refusing to update requests. The threat model is very limited and it would immediately be obvious that this is happening, killing the credibility.
ICANN is a severe risk btw. Current new protocols should be designed to avoid DNS wherever possible.
At the end of the day, truly fully decentralized systems are literally impossible, there's always a centralized aspect (at least for bootstrapping) and it's usually DNS-shaped.
That being said, PLC directories are a problem that blockchains (yuck) actually solve very well: trustless, public ledgers. I would not be surprised if we see a separate implementation based on an architecture derived from such systems.
Bluesky's moderation actions are generally implemented as moderation labels which take effect at the AppView level. Sometimes they'll take down someone's PDS or censor from their relays, but I don't believe third-party relays are aware of those relay takedowns at all.
If the instance goes down, the network stays up and continues to work, minus only the accounts on mastodon.social. This is not the case on bluesky afaik. They got DDosed a few months ago and the whole network was down because of it. https://news.ycombinator.com/item?id=47802330
In ATProto there aren't 'instances', and its technically 'decentralized' but theres really only bluesky.
But this is indeed somewhat technical; in an ideal world clients would automatically fall back to alternative AppViews.
I personally think that this actually leads to healthier communities but that may be a matter of taste!
The guy who runs FSE (one of dark fedi's more notable instances) has written a lot of good blog posts on his side of the technical and social details, his one about running FediList is a good picture of the type of one-sided politics involved (and, if you're into the technical stuff, is rich with that too): https://blog.freespeechextremist.com/blog/about-fedilist.htm...
It seems to be the nexus of federation + https://signal.org/blog/the-ecosystem-is-moving/
The one down side of the system is the cost. It's cheap to host a PDS but expensive for other components. Users could not relies on "someone" for running those components for free forever.
The difference is that it's easy to scale ATProto AppViews up beyond the reach of their users. It can scale down though. It is not easy to scale ActivityPub instances up beyond the scope of the people who use it, and it would probably be way more expensive if you tried.
- Relay as an optimization. That's cheap-ish ($30/mo) or free-ish if you pool with others.
- Your own app server. That's on par with normal web apps as long as you can keep a socket open. What's expensive is if the app you're making is a fully capable copy of Bluesky itself with gigabytes of existing posts — but is that the app you're making? The economics here are identical to normal web app stuff.
This is the implicit idea in my comment when I said it's expensive. If Bluesky banned me and I could not find another AppView with comparable reach and audience, I lose, the ban is effective.
Another problem is ATProto users don't usually associate then with an AppView the same way Mastodon users associate with the instance, it's hard to raise fund to sustain the infrastructure cost.
Okay, but that's always the case when you get banned from a service. The difference here is that it's possible to build a competing service with different moderation decisions being a lens over the same data.
My concern isn't technology or culture, it's money. At the moment, ATProto is existentially dependent on Bluesky PBC, a venture-funded startup ($100M from Bain Capital). There are people doing good work to make it more decentralized, more power to them, but at the moment it's still deeply centralized. And it's hard to see what the business model is that will support what Bsky PBC does at a global scale. Eventually Bain will want to see a revenue stream that justifies their investment; maybe there's a way to do that that doesn't involve enshittification but it's certainly not obvious.
You can dislike the instance-centeredness of Fedi/Masto (seems to have worked OK for email over the decades) but it's an actual thing that's actually working. And offers account migration without losing followers if you don't like the instance you're on. And has multiple really excellent client software packages. And seems to be covering its costs through a mixture of Patreon, co-operative & nonprofits, some Euro-gov help, all without any VC input. It can't be bought or owned by anybody.
Put another way, this is a really interesting space. But the technology is less interesting than the culture, and the culture is less interesting than the m money.
The mitigation is of course more companies and open source projects getting involved. As far as I understand it, the protocol is pretty well designed, and there is a bunch of open source out there already. It just needs more people to get involved.
But the article pointing out that you can migrate your Bluesky account to a thing called Eurosky was actually news to me. As is the existence of non Bluesky owned applications on top of atproto. I might give those a try actually. It seems a lot has happened since I last looked at this stuff a few years ago.
That still leaves governance of the protocol as a problem. That would ideally need to be untangled from Bluesky as well. But that seems doable as well. The more independent atproto software projects are out there, the harder it is for Bluesky to make breaking changes. That naturally pushes for some independent governance. I wouldn't be surprised to see that happen over time. But worst case, there could be some kind of fork/split of the network.
It would be interesting to see some attempt to bridge with other networks. A mastodon / bsky hybrid. Why make people choose? Despite X's demise, it's still X versus everything else. There's also Meta's Threads and a few others. The whole "not X" space fragments users over multiple networks that sort of could federate if they would but they really aren't. I think Threads is nominally mastodon compatible at least but actually federating is a bit frowned upon by Mastodon users.
And while we are "at" it, why not support email as well? Which is the og. federated communication network with essentially all internet users as active users. It's not perfect, but nothing better ever managed to replace it.
Separating identity from protocol is a good design choice. Cross protocol federation is a logical next step. It's all about receiving content from people, not about staying in walled gardens that belong to share holders.
Yes, a lot has happened! The scene still has very much indie vibe, but there's a lot going on in the Atmosphere. Atproto blog has recently started showcasing some community projects so check it out: https://atproto.com/blog
>That still leaves governance of the protocol as a problem. That would ideally need to be untangled from Bluesky as well. But that seems doable as well.
The core part of the protocol is literally going through the IETF process now: https://atproto.com/blog/taking-at-to-the-ietf. It's happening.
Re: other things, it's up to the community to do this. You can get involved. BridgyFed is doing cross-protocol federation and has been doing for a while: https://fed.brid.gy/. I'm sure there are other things that could be done in that space.
THANK YOU. It seems like far too few in this space really understand the benefits of actual decentralization.
ATProto feels like "centralized, except also we get other people to do the hard work with few of the benefits."
*: Not an .xyz, has proper SPF and DKIM records
The main different is the designs Facebook has employed manipulated their users to adopt this "scroll down" method of reading. Each item of information is only displayed just a few seconds on user's screen, unless user stopped scrolling at the item they really interested in (and then maybe tap to open it).
That's not the same design used by blogs. Think of blogs as mini news sites, it encourages their readers to open the content in a full page to read it without interruptions. And, the readers has to calm their heats down to read long statements, this costs time and demands focus.
If you port the design used by blogs and apply it to display Facebook posts, that will be user-hostile, because user has to click each post only to read a potentially very short content.
The opposite is true too. You can't encourage user to "scroll down" a wall of long texts just to read the next wall of long texts, because that will be exhausting. You can't even create the anticipation that there's more stuff down, because that will just manipulates the user to keep scrolling down and skip.
That's why I think even you technically can aggregate blogs and social media in one app, you should probably be careful about it.