Hacker News Reader

Comment by f38zf5vdt | Hacker News Reader

I still don't comprehend why Dorsey didn't just try to make the largest ActivityPub server on the web. Instead we get a haphazard rewrite of everything ActivityPub has already solved and a zany "you need an invite to get into this club" airdrop that feels dated to gmail 20 years ago. The service feels too much like "Elon bought Twitter, now we need to make Twitter again". That Dorsey is the principal investor makes it hard to think that it is anything else.

The only market it seems to be gaining traction in from my perspective is millennials who have nostalgia for old Twitter -- and as someone who grew up with old Twitter, I can say I don't really miss it.

View on HN

> I still don't comprehend why Dorsey didn't just try to make the largest ActivityPub server on the web.

Have you seen the ecosystem study BlueSky published in 2020? https://gitlab.com/bluesky-community1/decentralized-ecosyste...

Bit more of a summary https://twitter.com/bluesky/status/1511811083954102273

BlueSky/AT Protocol seems to have pretty distinct design goals that are not possible with ActivityPub.

Yeah, I have read about the things they want to do which are mostly cryptography related and which have absolutely zero reasoning as to _why_ they can't be done with ActivityPub. Signing all your messages? Yeah, you can append Ed25519 signature chains to any ActivityPub message. You could publish your base public key when creating an account. You could make software that hides all this beneath an abstraction layer so the end-user never has to deal with it. Exporting all your data and uploading it to another server is something you can already do with Mastodon. E2EE message? Coming soon to Mastodon. It's all things you can do _very easily_ on top of a fault tolerant federated public messaging system.

ActivityPub of course uses the same cryptographic certification virtually all the web does, just TLS/HTTPS and relies on the host cert to be valid. But if you wanted to add further levels of verification like pubkeys and sigs, there's absolutely nothing stopping you.

> Yeah, I have read about the things they want to do which are mostly cryptography related and which have absolutely zero reasoning as to _why_ they can't be done with ActivityPub.

I guess the race is on, then. Surely ActivityPub, with its much larger user and developer base, will grab the best ideas from AT Protocol and squash this redundant newcomer.

Differences in funding also matter.

Yeah, AT Protocol being "funded" by one company (Bluesky PBLLC) and ActivityPub being indirectly "funded" by multiple companies + organizations, some of them being Nextcloud GmbH, Framasoft (PeerTube), Tumblr (Yahoo).

Seems based on that variable, ActivityPub has the benefit of being more widespread, but that tends to also make changes go through slower. ActivityPub being a specification maintained by W3C also make changes extra slow, but stable at least, while AT Protocol probably won't have any stability guarantees for a long time.

Proponents of ActivityPub talk a lot about how flexible it is. I think that's the problem here.

Sure you could implement BlueSky-over-activitypub, but would it be usefully compatibile with mastodon-over-activitypub? If not, why add the complexity.

Can't comment on the bluesky aspect, but you've touched on my frustration with ActivityPub. When people were migrating to Mastodon, I took a look at making a single-user instance that would suit my personal needs and gracefully interact with the wider ecosystem and found that in my case the capabilities of ActivityPub are irrelevant, you are tied to the Mastodon teams choices.

Felt very much like in practice it just gives you tools to make mostly-insular federated apps, rather than letting different apps interact.

> Instead we get a haphazard rewrite of everything ActivityPub has already solved

As someone who doesn't seem to be a deep into the specifications (ActivityPub nor AT Protocol) as you are, how does ActivityPub handle people moving across servers without loosing old content and interactions? Like if I use server A but want to move to server B, how does that work in practice? How does server C who used to communicate with server A get notified that they now have to communicate with server B instead?

> The service feels too much like "Elon bought Twitter, now we need to make Twitter again"

Strange feeling considering bluesky was first announced in 2019 as a Twitter project, eventually spun out as a separate entity in 2021, and Elon didn't start the acquisition of Twitter until 2022 sometime.

The old server broadcasts a 'this person has moved'-message. Your followers will then automatically switch over to the new account.

This implies that:

- If the old server is offline or unwilling, you cannot move - Your old toots and interactions will still be tied to the old address, so you leave those behind.

There is some talk going on to find ways to mitigate this and it might be possible to fix the second issue.

The first issue is a bit trickier though. If you were to remove trust from the server, it becomes way harder to fight spam.

From the AT Protocol FAQ:

> Our solution for portability requires both signed data repositories and DIDs, neither of which are easy to retrofit into ActivityPub. The migration tools for ActivityPub are comparatively limited; they require the original server to provide a redirect and cannot migrate the user's previous data.

So it seems that AT Protocol has a solution to that specific problem, while ActivityPub does not. So there is some differences between the protocols after all, and it might seem like they have at least one reason for creating a new protocol rather than trying to adjust ActivityPub to fit as a solution?

We'll have to wait and see how many clients default to storing a complete data repository for AT in order to complete a migration from an offline server.

> If the old server is offline or unwilling, you cannot move - Your old toots and interactions will still be tied to the old address, so you leave those behind.

This is just like any other system that combine content delivery and identity on the same channel (e.g. web sites). Even if those 2 were separate, if your centralized identity provider is down, there is no way to update clients that depend on it, or to safely attest a new identity.

Allowing unverified servers to claim an identity or kick off a migration is a recipe for widespread hacking.

Right now, changing accounts is implemented by the old server sending a Move activity which tells all your followers where your new account is. This doesn't handle moving any content.

But, there's nothing fundamental about ActivityPub that prevents this: https://shadowfacts.net/2023/activitypub-portable-identity/. You can absolutely have posts identified by your identity (read: domain) rather than where they're hosted. Complete and seamless moves are possible, Mastodon just doesn't implement them.

Interesting, thanks for sharing that. This has been one of the things I felt that ATP got "right", so neat to see that ActivityPub can do it, even if Mastodon doesn't.

Interesting. So ActivityPub could support that use case, but currently doesn't. Combined with the fact that getting changes through to the specification itself (maintained by W3C), I could understand not wanting to spend the energy and effort on trying to go that route, and instead come up with something different.

Thanks for sharing your article, lots of good points in there.

> I still don't comprehend why Dorsey didn't just try to make the largest ActivityPub server on the web.

Because that would just restart at square one? It's like we've learned nothing about centralization since the web1 era.

Guess my post was too much of truth to handle, but I guess that’s just a proof of what I’ve said, at the end, I’m happy that social media is dying in its current form.

Reply on news.ycombinator.com