z428 (z428@loma.ml)'s status on Tuesday, 05-Sep-2023 15:47:13 JST
z428Serious question, no offense or provocation intended: With this stuff being baked into Hubzilla and, apparently, also design-wise into Bluesky / AT, can anyone out here involved with the #ActivityPub specification process outline why nomadic / easily portable identity isn't built-in here by design? Looking at the (to-be-expected) dynamics of instances going up and down, blocking each other or moving to newer, different pieces of software, this seems an absolutely obvious requirement, so I wonder why this has been left out of the standard / spec?
@z428 When the ActivityPub spec was written the standard for decentralized identity didn't exist. But now Decentralized Identifiers (DIDs) is a W3C standard, so we can tackle this problem.
While this is true, there's more history. At the time #ActivityPub became recommendation the people involved knew that important improvements were required in future iterations. This just never happened. Specs never evolved and projects created their own solutions.
For many years, what's now #Streams and #Nomad protocol, created by @mike has had nomadic identity. Why this hasn't picked up by other projects? Idk, getting such adoption is likely just as hard as evolving specs.
@smallcircles@mike@z428 As far as I know, there's no documentation for streams' implementation of nomadic identity. I think I managed to grasp the overall idea from various conversations but not enough to build an interoperable software. The reason I prefer DIDs over multi-home model is that there's no need to register accounts on other servers in advance (although I could misunderstand something about Nomad).
I provided my input to the AP spec editor and it was rejected outright. Everything I provided to the ActivityPub editor was rejected outright. If there were any questions, it had to go through the Mastodon dictator, who rejected anything he didn't invent. And then the ActivityPub editor would likewise reject it. "Mastodon has millions of users, you don't".
That's the way the process works.
The major concern was that nomadic identity is hard, and the clock was ticking on when the spec had to be finalised. The ActivityPub editor also insisted that it be done using the draft digital identity spec. So that ensured it would never make it into ActivityPub.
Here we are 5-6 years later and they still can't figure out how to do nomadic identity in a decentralised framework (outside of using torrents or centralised resolvers). Meanwhile we've had it, used it, and improved it for well over a decade.
There's a specification in the public domain. Some complain that it isn't enough, but I'm one person in a planet of 8 billion and haven't had any help developing this. The only help I ever get is with bike shed stuff - web interfaces. Not one person has offered any help polishing up the spec or improving the actual implementation code or even offered critique and discussing the subject. Just "I can't use this. Bye." [edit: apologies. That isn't entirely correct. I did get help from one person.]
I've started to pick it up and try again using did's as a proof of concept, but I'm retired now and really can't be bothered dying on the same hill over and over again.
But I will try and update Nomad (the protocol, formerly Zot) to use a did: form. It's just a replacement WebMTA for delivering JSON ActivityStreams which is nomadic aware. There's still no chance of it ever getting into ActivityPub unless it's invented by the Mastodon dictator.
Meanwhile the spec is in the public domain and there are working implementations and it federates with ActivityPub and nobody is holding a gun to anybody's head.
And as it relates to fep-7628, we provide the "copiedTo" property in ActivityPub as an analogue to Mastodon's "movedTo" property. It has the same semantics as the Mastodon property except the original identity isn't deleted [edit: and can be an array]. This is documented in the FEDERATION.md document of the streams repository.