@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.
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.
@volkris @z428 @mike @silverpill @smallcircles
Certainly agree it scales poorly though. Sending the same message 100 times to your 100 followers on a single server seems pretty wasteful. And not including any meta-data like preview cards so causing inadvertent DDOS attacks on pages, that could do with work.
@pre Sure, you're right, IMAP doesn't automatically copy over your stuff, but at least (given a decent client) it's an option. You can take all your communication, including metadata, keep it, do backups (you can do that with most Fediverse systems too), bring it into a new server and follow up on any previous communication you had. The latter part is rather ... flawed in ActivityPub environment as far as I see. A lot of systems (though not all) seem able to export history, few (Firefish?) seem able to also import that communication again. Whether, in example, I could "just" switch account over to another provider and follow up communicating in what used to be a "private" thread with multiple recipients before probably remains to be seen.
Yes, quite a part of that is client functionality, but core features for that seem to just missing in the protocol, like a standard import/export functionality for posts. And that's a tad sad because these are use cases known for decades with existing other protocols...
@z428 @mike @silverpill @smallcircles @volkris
But can you have a standard way to back up posts when not all activitypub servers even will deal with notes at all, and others will have stories-type activities and others will have video-messages like Peertube and others will have future types of activity not even invented yet?
And as soon as you're into that conversation, you're looking at the clock and wondering when the deadline for submission is and if it can all be done in time.
Re-importing messages on a new URL when if anyone has any record of them at all to look for they'll be looking to the old URL seems tricky. Rebroadcasting them to the network sounds spammy.
How long would the conversation to decide a consensus on all that take?
I don't know it well, but it seems to be extensible and people are working on it. Don't expect it'll ever be finished though, no more than http is finished.
@pre Sure. No real objections here, but that's where I see a big big problen with this kind of standardization. Because the downside of this is rather obvious: You end up with an immense amount of fragmentation both in how the defined parts of the standards are implemented and in how the undefined parts of the standard are used in various implementations. The outcome is a heterogenous environment with an immense load of different interfaces, leaving it entirely up to a particular user to understand or have an idea whether a particular attempt of communication will (not) work out - just as if you, while using e-mail and composing a message to a crowd of people, all of a sudden are in charge of imagining _every_ mail client out there and the capabilities it most likely can have. In the end, you'll end up with a network for idealists, enthusiasts and tinkerers, and it just takes yet another Twitter to cater for all those who "just" want to use technology that somehow works out of the box. This is a messy situation and it feels, especially now, like a missed opportunity once again, in-line with XMPP and Diaspora. 😔
@z428 @mike @silverpill @smallcircles @volkris
Heh. Yeah. I get a lot of email I can't read coz I read using Mutt in a terminal. The ones trying to send HTML are mostly spam anyway.
@pre (I then and now get mails with time plannings inline, and at some point I repeatedly get in trouble using mutt because then and now people love to use coloured text to highlight interesting aspects of timelines - and it's extremely hard to communicate to not have an MUA capable of displaying even coloured text in 2023... 😉 )
@z428
The worst is the email-verification links that are like half page long and malformed by line-breaks in the terminal.
I have dragged windows many times wider than the screen so I can select the whole thing.
Honestly email folks, you don't need 10000 characters in your validation links!
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.
@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.)
@pre @mike @silverpill @smallcircles