I was right about ATProto key management • Hacker News Board

Re: I was right about ATProto key management

#121

Post by direwolf20 » Mon, Jan 26, 2026, 12:51 PM UTC

danpalmer wrote: post #78

direwolf20 wrote: post #62

Earlier quoted context omitted.

ActivityPub isn't actually the spec of Mastodon. Treat claims of "Mastodon is ActivityPub" the same as you treat claims of "Bluesky is decentralised." Just expose the same interface Mastodon does and you'll be fine. Noting that almost nothing cares about the exact URLs you use, except for webfinger, but does care about the domain being the same as the right side of the @ sign.

> Treat claims of "Mastodon is ActivityPub" the same as you treat claims of "Bluesky is decentralised." Not sure if you meant this in the way I read it, but I believe that Bluesky is pretty much decentralised and tidying up the last bits of that, and I also believe that Mastodon is functionally ActivityPub and probably mopping up the last bits where the open spec meant anything. The problem with ActivityPub is that i…

> Bluesky is pretty much decentralised

????? what data could possibly lead to this conclusion?

https://arewedecentralizedyet.online/

Re: I was right about ATProto key management

#122

Post by direwolf20 » Mon, Jan 26, 2026, 12:52 PM UTC

robcohen wrote: post #33

direwolf20 wrote: post #32

Earlier quoted context omitted.

Unfortunately, the swarm is 99.99999% advertisements for penis enlargement pills. How can a P2P system filter them out? A federated system relies on each admin to filter them out. A centralised system does even better, relying on a single dictator to filter them out. A P2P system requires every user to filter every spam message, together consuming far more effort than the spammer needed to send it.

This isn't, and has never been a hard problem. Just pay for people's attention. People you follow don't have to pay, and make that transitive. Penalize people in your network who propagate spam by increasing the cost to get your attention.

Should I create 1 million accounts with bots that scroll endlessly to harvest microtransactions?

Re: I was right about ATProto key management

#123

Post by account42 » Mon, Jan 26, 2026, 1:02 PM UTC

Meneth wrote: post #105

fc417fc802 wrote: post #104

Earlier quoted context omitted.

I agree that the ATProto situation described is ridiculous. However the situation with AP is not nearly as cheery as you describe. The protocol commits the exact same sin, essentially baking in the assumption that any given ICANN DNS entry will only ever be controlled by a single entity for all time. Real world implementations then associate keys with nodes using a TOFU scheme (which makes perfect sense) and if the d…

"the assumption that any given ICANN DNS entry will only ever be controlled by a single entity for all time." Email has that problem too, doesn't it?

Email is more like physical mail - you send something to an address and whoever lives at that address gets the mail.

The described ATProto/ActivityPub behavior would be like trying keep the address tied to whoever lived there first.

Persistent identities are a nice goal but treating transient identities as persistent is not. A better designed system would use the domain name system only to look up the current identity associated with a name instead of trying to permanently tie the name to an identity.

Re: I was right about ATProto key management

#124

Post by account42 » Mon, Jan 26, 2026, 1:17 PM UTC

miki123211 wrote: post #99

jrm4 wrote: post #29

Earlier quoted context omitted.

So I agree with you that they should work like email -- but I've always said that Mastodon is better because it is like email; aka the power is in the nodes. What do you think is wrong about Mastodon? Genuinely curious because I also am super skeptical that ATProto brings anything that we really need.

The problem with centralized social media is that the admins have power over you. They can ban your account with no recourse, censor some of your posts (or some posts you want to read), or even post something from your own account that you don't approve of. Mastodon doesn't change this, it just changes who the admins are. It lets a person under the jurisdiction of admin A interact with a person under the jurisdiction…

> They can (and very often do) defederate from instances that post "too much nazi content", and if you disagree with the decision, there's again no recourse (you can migrate, but you won't get your lost relationships back).

Worse, they defederate instances that don't also defederate instances that they dislike badly enough so you can't even have neutral instances where you can communicate with everyone.

Re: I was right about ATProto key management

#125

Post by direwolf20 » Mon, Jan 26, 2026, 1:23 PM UTC

Meneth wrote: post #105

fc417fc802 wrote: post #104

Earlier quoted context omitted.

I agree that the ATProto situation described is ridiculous. However the situation with AP is not nearly as cheery as you describe. The protocol commits the exact same sin, essentially baking in the assumption that any given ICANN DNS entry will only ever be controlled by a single entity for all time. Real world implementations then associate keys with nodes using a TOFU scheme (which makes perfect sense) and if the d…

"the assumption that any given ICANN DNS entry will only ever be controlled by a single entity for all time." Email has that problem too, doesn't it?

No, since email is delivered to whoever owns the domain at the time the email is delivered. Besides a spam reputation score — which is a problem — one mail server doesn't retain a long-term trust relationship with any other.

Re: I was right about ATProto key management

#126

Post by direwolf20 » Mon, Jan 26, 2026, 1:24 PM UTC

Dylan16807 wrote: post #83

skybrian wrote: post #2

It's written in anger, but I'm optimistic that this will eventually get fixed, and documenting bad experiences like this will help.

If you mean the buggy and badly documented process, sure. But the complaint it builds up to is that instance-wide bans can ruin you when there are super big instances, and that's not something that can be fixed.

Any system that can ruin a spammer can also ruin someone who isn't a spammer, since the system can't tell the difference.

Re: I was right about ATProto key management

#127

Post by direwolf20 » Mon, Jan 26, 2026, 1:24 PM UTC

somat wrote: post #88

anon7000 wrote: post #26

Earlier quoted context omitted.

Bluesky is designed the way it is because of scale. How do you make a p2p app that can handle hundreds of millions of posts per day without beefy servers helping? Bsky is designed so that the microservices themselves can be decentralized and so multiple different types of apps can be built on the same protocol/infra. Obviously, it’s early days, and hopefully there is even more experimentation in the p2p space. But at…

You invert the problem. People want to build store and forward systems because that is their mental model of the problem. store and forward system are fine, and there are many advantages to them, but direct request systems scale much better. basically have each user fetch their messages from the locations they want rather than delivering the messages to them. think how the web works vs how email works.

RSS! But you can't make a personalized timeline with a pull model, and that's where the money seems to be.

Re: I was right about ATProto key management

#128

Post by account42 » Mon, Jan 26, 2026, 1:25 PM UTC

glenstein wrote: post #79

echelon wrote: post #22

Earlier quoted context omitted.

Peer to peer, not federation, is the way forward. We should only build peer to peer social protocols. Websites and communities should simply sample from the swarm and make it easy for non-technical users to post and consume. They should be optional and not central points of failure (or control). {Twitter, YouTube, Reddit, Instagram, TikTok, WhatsApp, Discord} should work like {Email, BitTorrent, PGP}. Bluesky and Mas…

I don't disagree, but I'm baffled that, with P2P as your preferred outcome, your orientation toward federated infrastructure is one of opposition rather than support. It feels philosophically confused to me; they're your natural allies, they're a step in your preferred direction and they have an instance of real world success (well, to a degree) which is important. Whatever theory of change motivates this form of cri…

This is a flawed argument. If someone wants X they don't need to also support Y just because it's closer to X than other alternatives.

Re: I was right about ATProto key management

#129

Post by direwolf20 » Mon, Jan 26, 2026, 1:25 PM UTC

cluckindan wrote: post #48

anon7000 wrote: post #26

Earlier quoted context omitted.

Bluesky is designed the way it is because of scale. How do you make a p2p app that can handle hundreds of millions of posts per day without beefy servers helping? Bsky is designed so that the microservices themselves can be decentralized and so multiple different types of apps can be built on the same protocol/infra. Obviously, it’s early days, and hopefully there is even more experimentation in the p2p space. But at…

You use routers as the beefy servers. Unicast, multicast, broadcast. Unfortunately that means the implementation needs to reach all the way into the network layer.

Multicast doesn't work on the global internet, and can't, due to problems of scalability and billing. It's sometimes possible to negotiate with specific ISPs to use multicast in specific ways on their network.

Re: I was right about ATProto key management

#130

Post by direwolf20 » Mon, Jan 26, 2026, 1:26 PM UTC

miki123211 wrote: post #99

jrm4 wrote: post #29

Earlier quoted context omitted.

So I agree with you that they should work like email -- but I've always said that Mastodon is better because it is like email; aka the power is in the nodes. What do you think is wrong about Mastodon? Genuinely curious because I also am super skeptical that ATProto brings anything that we really need.

The problem with centralized social media is that the admins have power over you. They can ban your account with no recourse, censor some of your posts (or some posts you want to read), or even post something from your own account that you don't approve of. Mastodon doesn't change this, it just changes who the admins are. It lets a person under the jurisdiction of admin A interact with a person under the jurisdiction…

Is there any other way to deal with spammers that can't be applied to non-spammers by a malicious admin?