Hacker News Reader

Comment by grishka | Hacker News Reader

So suppose someone had a domain and a Bluesky identity associated with it. They deleted their account for whatever reason and let the domain expire. Later, someone else bought the domain, but since it had a previously-deleted account associated with it, it's permanently banned from identifying a Bluesky account ever again. Do you really think that's adequate?

I really like the ActivityPub approach more. There, if a domain changes hands, so potentially do all accounts associated with it. An account can be permanently deleted by sending a Delete{Person} activity to the network, but that doesn't prevent an account with the same username from being created again.

View on HN

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 domain ever changes hands (thus the key changes) all sorts of stuff breaks in frustrating ways.

Even worse are the assumptions that a given node will never migrate between DNS entries or appear at multiple DNS entries simultaneously. In practice this comes up all the time because people regularly stand a node up on a cheap VPS using an off the cuff domain. Then some time later they either forget to renew the domain or have second thoughts about it.

While I appreciate that it's always easy to criticize things in hindsight there's no lack of aggravating real world problems related to the way AP models identity.

"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?

It might be the case that the designers of email and the designers of ATProto and the designers of AP all assumed the owner never changes. But I think the actual behavior of the protocols in the event of a change is different.

For email, if the owner changes, the new owner gets full control. This is nice for the new owner, but maybe not so for the old owner, because now any emails meant for the old owner can be read by the new owner.

For ATProto and AP, it sounds like in the event of an owner change, things kind of break. This protects the security of the old owner to some degree, but means the new owner can't really do much.

Not really? Email is a dinosaur of a protocol that doesn't properly handle authentication to begin with.

Anyway other protocols or implementations making the same class of error doesn't change the fact that it's an error and that it causes real world problems for users such as described in the linked page.

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.

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.

> if the domain ever changes hands (thus the key changes) all sorts of stuff breaks in frustrating ways

Actually no. It's not supposed to break implementations that are made according to spec. It's not quite TOFU. Keys can be rotated. An Update activity would not work in this case because the new domain owner will not have the private key to sign it, but a periodic refresh that most implementations do will. The only fundamentally immutable field of any AP object, including an actor, is the ID. In practice, objects usually don't change types either, even though the spec technically doesn't forbid that. The only case I know when they do is when you edit a post and attach a poll, or remove a poll from a post that had one. Then the type changes between Note and Question.

Of course the dependency on DNS isn't nice. But we haven't invented anything better yet, so this will have to do for now.

Account migration on the fediverse is a thing, but it could be better by transferring past content. This is an active area of research right now.

Yeah it's a fair point that the spec as written doesn't preculde handling domains in a more sensible manner. But in practice it's a headache. Spin up a VPS, create A@X, send out some messages, nuke the VPS, spin up a new VPS and create a new A@X, send out some more messages, and check how well remote instances handle the situation. Maybe things have improved since the last time I encountered that? I doubt it though.

> Account migration on the fediverse is a thing

Has something changed within the past year or so? Because if you're referring to the mechanism where a notification is sent out that A@X has moved to B@Y I hardly consider that to qualify. Proper account migration would mean moving the account itself, not automated assistance coordinating the person behind an account switching from one to the other.

> Spin up a VPS, create A@X, send out some messages, nuke the VPS, spin up a new VPS and create a new A@X, send out some more messages, and check how well remote instances handle the situation.

If you do it in a rapid succession, then of course it would not work. You have to wait at least a day, and then, when you send something to another server, there's a good chance it would refresh your actor and pick up the new key. You can also force a refresh on a server where you have an account by pasting your self-hosted account's username or URL into the search.

> Proper account migration would mean moving the account itself

There is no such thing as "account itself" as a separate entity in ActivityPub. The URL that points to the actor object JSON, aka the ID, is your account, and that includes the domain. There are no higher-level identities.

Exactly my point. Account migration simply isn't supported. Not in any practical sense.

> there's a good chance it would refresh your actor and pick up the new key.

And how will this be displayed to users of remote instances? Last I checked it was a confusing mess on most implementations (ie every one I have experience with) and the mess would persist indefinitely without manual intervention in the db by a given remote admin.

In the event a domain has changed hands then even with remote intervention no truly satisfactory outcome is possible. This is due to, as you rightly point out, there being no higher level identities. The domain is a fundamental part of the account as modeled by AP which makes conflicts a serious problem.

Just to be clear, this is specific to did:web, did:plc does not have the same downsides (it has different ones).

I’m trying to understand how “burning” works here. If I understand correctly:

1. Someone has a domain, example.net. They set up a did:web:example.net, and a handle @example.net pointing to it.

2. They deleted their account and let the domain expire.

3. I register the domain, but can’t set up did:web:example.net again. But I assume I can still set up did:web:mynewdid.example.net, and then point @example.net to that DID instead.

I won’t have access to the original account, but I will be able to use that domain as a handle for a new one.

(This, of course, is only my assumption. I’ve been able to switch my domain from one did:plc to another, but I haven’t tried it for did:web.)

Reply on news.ycombinator.com