@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.
Take a look at this proposal, for example: https://codeberg.org/fediverse/fep/src/branch/main/fep/ae97/fep-ae97.md
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 Yes, exactly, something like this was bothering me here while thinking about that, too. In quite some fields (including this, including, too, particular aspects of message delivery as seen in example in SMTP), it seems quite some interesting aspects of pre-existing technology have been omitted or ignored in #ActivityPub, and I'm trying to understand the reasons for that. Why not build on things and learnings that already have been made? Are/were, in example, the #Streams / #Nomad implementations or designs too complex for building on?
@z428 @mike @silverpill @smallcircles
The reasons are the same as usual aren't they? Constraints on the time and availability of people during the standardisation process. Only so much time to get consensus do you get it on the basics and try to make it extensible.
Yes, indeed. It is very, very hard to get something going when the scope and audience are so broad.
@smallcircles @z428 @mike @silverpill
And if you try and get it all right before you release then you end up like bluesky did, just arguing and not releasing anything for half a decade.
@pre But wasn't the Hubzilla implementation of Nomadic identity already around at least early in the #ActivityPub specs process, or did it come later? I think it was but I might as well be wrong.
@z428 @mike @silverpill @smallcircles
Zot was first released like half a decade before the ActivityPub spec, but I think it'd be fair to call it a minority experimental system on Fedi at the time, even now really.
Not the kind of thing you could get unanimous consensus on without days of arguing about how the protocol should work and which crypto systems to use etc.
@pre Wonder, though, whether it was even taken into consideration for / while specifying #ActivityPub. (And, apparently: Given the very _idea_ existed half a decade ago, I wonder why this idea wasn't even more obvious when ActivityPub specs gained speed? That's the other thing that's somehow keeping me confused - this is, like, really so _astoundingly_ obvious, even everyone who used e-mail before - as a service often referred to when trying to outline the advantages and function of decentralized networks - of course came with more portability baked in with either your messages living in an IMAP server which you easily could copy around - or living in a completely "local" mail box structure on your device, thus also being kind of decoupled from the actual service you used for sending/receiving... would e-mail ever have gained relevance if it was all about "switch account and you lose all your communication history and messages without a chance to fix that"?)
You mention half decade ago, and I’d reply by pointing out that concepts like PKI, Web of Trust, and other technologies that would enable nomadic identity have been around since the 80s at least.
These ideas were around for decades.
I really get the sense that ActivityPub developers were so focused on today’s web technologies that they didn’t go back and learn from past bodies of work that could have made a huge difference.
@volkris Well ....... yes. I didn't want to think along these lines, but actually these idea of all that stuff being focussed primarily on web technology, not networking technology, feels present in some part of the specs. Otherwise, talking asynchronous messaging and delivery, there seem quite some things in protocols like SMTP, NNTP, XMPP PubSub, ... to learn from. I do, in example, also have a very very very gloomy gut feeling about scalability in 1,000s of instances federating with 1,000s of other instances by pushing the same data around, the same data mostly being huge JSON structures. But that's ... a different aspect of it, I guess. And maybe unavoidable, given it seems the web has practically taken over here. (Or maybe I'm generally too rude, which might as well be.)
Regarding scalability, YES! when I read the spec for the first time I had the similar thought, that this system doesn’t look like it had any thought about scalability.
I even commented to some developer friends about this, joking that it doesn’t seem like anyone did a big-O analysis of this system, and one replied with a sigh that some schools don’t even teach big-O anymore.
It just really reinforces my sense that ActivityPub was designed by people with a very superficial background, without much understanding of lessons learned long ago.
I don’t mind being openly critical of it :)
@volkris @z428 @mike @silverpill @smallcircles
Still reckon it was likely more about time and the constraints of getting consensus than lack of technical knowledge by those involved.
Email servers never copy your message to your new email provider either FWIW. Switch account and you do indeed lose all the stuff in your inbox and any messages saved to the server's imap boxes. You can't transfer you handle there either like you can move your number on modern phone networks.
I just don’t see any evidence that this was about compromising in the committee to reach consensus.
Everything I see is consistent with, and more simply explained by, a committee that didn’t have a technical depth of knowledge and experience to see the problems that would arise from repurposing off-the-shelf components from web tech.
