Comment by lucideer | Hacker News Reader

Comment by lucideer | Hacker News Reader

Parent Full thread

Your added point fits in with the initial red flag for me - before I saw pfraze's (excellent) post here - that the vast majority of what I've read advocating for ATProto says very clearly: "Account portability is the major reason why we chose to build a separate protocol.".

Account portability is in no way incompatible with ActivityPub. It's not built into the spec., but it's also not forbidden / prevented by the spec. in any way. From ActivityPub's perspective it's an implementation detail.

Would it be nice if it was built into the spec: yes. Does that justify throwing out the baby with the bathwater?

I was hoping pfraze would offer some better reasoning, but while the post above is a great read for the technically curious, its very "in the weeds" so doesn't really address the important high-level questions. Textbook "technologists just want to technologise" vibes: engineers love reinventing things because working out problems for yourself is the fun part, even if many people have come together to collaborate on solving those problems before.

An unspecified "implementation detail" is essentially another way of saying that it doesn't work.

I've ported my account on ActivityPub a couple time, and it's a horrendous experience -- not only do I lose all my posts and have to manually move a ton of bits, but the server you port from continues to believe you have an account and doesn't like to show you direct links on there anymore.

The latter could probably be easily solved, the former needs to be built into the spec or it will continue to be broken.

100% agree with everything in your post. I don't see how it contradicts anything I've said though.

> the former needs to be built into the spec or it will continue to be broken.

Absolutely, but ActivityPub doesn't preclude that. There's no reason for that proposed feature to be incompatible with the spec., or to have to exist in an implementation that is incompatible with ActivityPub.

Fwiw Mastodon, the most popular ActivityPub implementation, is (as is often the case with open standards) not actually fully compliant with the spec. They implement features they need as they need & propose them. This is obviously a potential source of integration pains, but as long the intent to be compatible is still there, it's still a better situation.

and I believe CalcKey? is adding account content migration, which is why Eugen is suddenly talking about account migration again.

Even framing it as 'account portability' is missing the point. I want to own my identity and take it with me anywhere. I shouldn't need to transfer anything, its mine. This model is fundamentally incompatible with how ActivityPub works (no, running your own server is not the same thing as decoupling identity from the concept of a server itself.) Could that change in the future? Maybe, but not without prior art. Even if you think @proto, farcaster, ssb, nostr, or others are doomed, we should be applauding them for attempting to push the needle forward.

It's not incompatible with how ActivityPub works at all.

The ActivityPub spec says that object id's should be https URI's, not that they must. The underlying ActivityStreams spec just requires them to be unique.

All that's needed to provide full portability without a "transfer" is for an implementation to use URI's to e.g. DID's, or any other distributed URI scheme. Optionally, if you want full backwards compatibility, point the id to a proxy and add a separate URI until there's broader buyin.

I think there's be benefit in updating the ActivityPub spec to be less demanding of URIs, and instead of saying that they "should" be https require them to be a secure transport, and maybe provide a fallback mechanism if the specific URI mechanism is not known (e.g. allow implementations to provide a fallback proxy URL), but the main challenge there is not the spec but getting buying from at least Mastodon. The approach of providing a https URI but give a transport-neutral id separate to the origin https URI would on the other hand degrade gracefully in the absence of buyin.

> the main challenge there is not the spec but getting buying from at least Mastodon

Which is why promoting a new competing and incompatible protocol is a good way to push for change.

You want Microsoft to become more open? Then start promoting a pure FLOSS alternative until they can't ignore it anymore.

You could do the same a lot easier by pushing an incompatible change to ActivityPub that'd be easy to adopt.

Reply on news.ycombinator.com