Hacker News Reader

Comment by paride5745 | Hacker News Reader

The nightmare of the Wsocial rollout is a testament of the massive control Bluesky has on the ATProto network.

If Wsocial was on ActivityPub or Nostr nothing similar would have happened.

ATProto has serious centralisation problems, baked into the design. And it makes sense, considering it came out of a Twitter R&D experiment to "decentralise" Twitter itself. Pure federation was never part of the initial design.

ActivityPub and Nostr solve the issue already.

View on HN

I think decentralization is just not something users care about generally.

- many people wish they could control what they see and who they talk to. (Eg control the algorithm, avoid censorship from big tech)

- some people care about owning their data so it doesn’t go away when a company fails

- technical people are interested in building more types of social apps that aren’t just twitter posts etc

- nearly everyone just wants a fairly seamless experience without a lot of gotchas or technical problems to solve like self hosting an instance for your friends that falls over if too many people use it and is tricky to network with others.

Bluesky is trying to solve all those kinds of problems, which I think is pretty interesting, and I don’t think the others are quite doing the same thing technically. At the end of the day they are all pretty niche.

But Bluesky does not solve these points:

- content not in line with the political left is censored

- sure, you have your data in your PDS, but it is de-facto useless if the central identity server of Bluesky goes down

- ActivityPub and Nostr solve this already without being owned by a company

- you cannot easily and cheaply have an ATProto instance. AP and Nostr solve this already

> - content not in line with the political left is censored

What do you mean? Individual apps can choose to censor I guess, but you can fairly trivially run an AppView with no filtering whatsoever if that's what you fancy.

> - sure, you have your data in your PDS, but it is de-facto useless if the central identity server of Bluesky goes down

That's not correct. You can use plc, which Bluesky operates the largest directory for, but you can also use web, which completely bypasses Bluesky all together.

> - ActivityPub and Nostr solve this already without being owned by a company

What's 'this' here?

> - you cannot easily and cheaply have an ATProto instance. AP and Nostr solve this already

The terminology here of 'ATProto instance' doesn't really make sense. If you're talking about a PDS, you can use one of thousands of free PDS hosts, or host your own for free on Cloudflare (https://cirrus.earth/) or on your own hardware (there are PDS implementations which fit comfortably onto a Raspberry Pi, or an old phone, etc.)

Sure you can host your PDS, but if you want to deploy your own instance like you would do with Mastodon, you need to deploy a Relay and an AppView as well. And the way the network works, you need beefy servers for that.

On ActivityPub and Nostr you develop all kind of applications already, it is not only Twitter clones, but also Instagram clones, Reddit clones, on Nostr there is even the resurrected Vine (https://about.divine.video/).

And it is not trivial to switch from the Bluesky did:plc (which you cannot run in write-mode on your own and need to use the official Bluesky owned) to did:web, which you can run on your own.

The idea of an 'instance' is not really clear. If you want to run a social network on ATProto, you do need the relay and app view, and those are indeed heavy requirements, but the architecture is not the same, and it depends what you're actually trying to achieve.

If you just want to use ATProto for your own small app, there are ways to do it on more constrained hardware. The more usage it gets, the more it scales up.

> On ActivityPub and Nostr you develop all kind of applications already, it is not only Twitter clones, but also Instagram clones, Reddit clones, on Nostr there is even the resurrected Vine (https://about.divine.video/).

Same! You can explore the (unfortunately named, given the point I'm trying to make :)) 'Bluesky directory' to see apps which use ATProto: https://blueskydirectory.com

Note that most of these have nothing to do with Bluesky.

> And it is not trivial to switch from the Bluesky did:plc (which you cannot run in write-mode on your own and need to use the official Bluesky owned) to did:web, which you can run on your own

That's true, but it's not trivial to run your own Mastodon instance either...

>If you want to run a social network on ATProto, you do need the relay and app view, and those are indeed heavy requirements, but the architecture is not the same, and it depends what you're actually trying to achieve.

Note those are not heavy requirements in any atproto-specific sense.

Running an atproto relay (at the current scale) is $30/month. If you're running a popular app, this is probably comparable with some of your SaaS subscriptions. Or you could use a community-run one or pool resources with other apps. Also, many atproto apps don't use a relay at all, and rely on a community cache like https://constellation.microcosm.blue/ instead.

Running an AppView is only as expensive as running any backend. "AppViews are expensive" is a myth extrapolated from "Running a copy of a Bluesky AppView is expensive", which is true because a Bluesky AppView is a backend server that's supposed to store and serve millions of posts. It would be expensive with any technology! Atproto isn't adding an extra tax here. Running a centralized service at the same scale would be equally expensive, and a Mastodon instance at that scale would simply not run.

If your AppView only serves your app's users (and has nothing to do with Bluesky), the cost is cheap or nonexistent. It's just a normal backend that listens to a websocket stream and writes some stuff to a database.

Effectively what I meant by 'if you just want to use ATProto for your own small app, there are ways to do it on more constrained hardware. The more usage it gets, the more it scales up', but appreciate the top-up!

Relays are trivial to run now with changes to how syncing works a while back. AppViews are entirely up to the designer of the view. You can make it as complex and expensive or cheap and fast as you want, it’s entirely up to you. You do not have to provide the exact same functionality as Bluesky’s AppView and can basically do whatever you want.

> - content not in line with the political left is censored

Can you provide examples to me of this being true?

Wait, how do you think these two things relate, exactly, and how does it point in the direction of “Bluesky has so much control”?

Thats a claim with zero evidence put forward, and one that if evidence were put forward, would swing the opposite way.

What went wrong with Wsocial?

I don't mind the quasi-central nature of bsky, it's more of a problem that it's so heavily dominated by US politics.

Wsocial turned out to be a WEF honeypot or something.

That is not the point.

The point is that without talking with Bluesky, you cannot start your own ATProto product or you'll get throttled from the network.

Almost like the network is centralised.

Tons of people have started products without issue. But if you flood a popular relay with data that exceeds its rate limit then getting throttled is to be expected. This doesn’t prevent your participation in the protocol or network.

There are other relays and indexes out there that may have different rate limits. That’s just how these things work. The data from W is still there on their PDS, still public, still crawlable, and able to be backfilled within rate limits.

This is a non-issue.

That literally prevents your participation in the network, because you need the relay to be forwarding your messages to participate in the network. There is only one relay in BlueSky that matters. If the BlueSky relay is not relaying your messages, then you aren't on BlueSky.

Bluesky is not all of atproto, first of all. There are a bunch of apps thats don’t use any relay at all. Second, even if you aren’t on bsky’s relay, there are others, like the Blacksky relay.

I’m guessing from your constantly-incorrect capitalization of “BlueSky” that you’re not familiar with any of this even a little bit and you’re just repeating what you’ve heard from other, equally unfamiliar people.

> it's more of a problem that it's so heavily dominated by US politics.

I agree the default Discovery feed is not great, but you can just switch to a different feed like For You or the recent Eurosky version of it, called 'fu'. It vastly improves the experience.

Or join a European Mastodon server and solve the problem at the root.

and only have one feed? forgive me if I understand incorrectly but I'll take an open market of thousands of feeds and easy tooling to make my own that can pull from the whole network over just one local feed controlled by a server admin

https://blog.elenarossini.com/w-social-a-broken-ghost-town/

Basically, because they didn't warn Bluesky that they were going live, they had their traffic heavily trottled and they were unable to function.

So long for decentralisation if you need to talk to the owner of the protocol you are trying to use...

It's not that they didn't warn bluesky specifically. It's that they didn't warn relay operators in general. And IIRC they just needed to coordinate with a single relay operator who is reasonably trusted (ex blacksky or eurosky) but they didn't do that either.

The default rate limits are quite reasonable but big launches will blow past them so you gotta coordinate with someone.

And note that the relay federation/gossip agreements are largely manual configuration at the moment. Until someone pushes a proposal for an automated/dynamic topology management algorithm that doesn't get plagued with spam issues it'll stay this way.

No such problem on Mastodon/ActivityPub.

It absolutely is. Mastodon has rate limits and administrators have to manage and adjust them as necessary for their instances.

You probably just don't notice it as a user or as the operator of a small instance which to be fair is exactly the same with atproto. Users rarely notice rate limits and small operators rarely do either. It's the operators of large services that see these limits and have to coordinate with other operators.

The issue with W social is that they have a chronic inability to coordinate or play nice with anyone else in the atproto space. Rate limits aren't a problem if you are a good neighbor and you know your neighbors but frankly they just don't.

My Mastodon instance blocked Threads preemptively because they were afraid of the traffic driving up their hosting costs so you’re basically just very wrong or lying about this. A huge flood of incoming traffic can be hugely expensive for ActivityPub node operators. The problem of giant onboarding events is real, there’s just no default protection against them in Mastodon like there is in Bluesky, so operators either have to take matters into their own hands with defederation or risk driving their bill through the roof.

Reply on news.ycombinator.com