Speaking of such things, an email client or an email server are never as monopolistic as Chrome.
So maybe email is a good candidate for something that should be torn down and built anew right after the Web.
Also email doesn’t have to be destroyed entirely, it’s very modular.
Where they had UUCP paths, and now have addresses in some services, just need to have John Doe <3cec7f8c438fa578dbd3a1557b822df469490a12>, with 3cec7f8c438fa578dbd3a1557b822df469490a12 being a hash of “johndoe” here and a hash of his pubkey in reality, and his pubkey can be retrieved from some public directory.
And have the letter signed by it (and encrypted possibly, though this of course would hurt server-side solutions of spam problem).
Frankly they can have a common replacement, in my humble opinion. When separating identities from servers, one can do the same with websites. How is a newsgroup fundamentally different from a replicated website collaboratively edited? If a letter can have a universal identifier, what prevents one to put a hyperlink to it? If we need scripts, what prevents us from having them in a letter’s content? If we need to reach a server by hostname and IP, what prevents us from doing just that from a letter, just the letter being the primary point of entry?
I just think that the old “vector hypertext Fidonet” joke is not so dumb, if you think what it could literally mean.
The problems with email are many but the two that would warrant rebuilding is that the technology is a mess of under specified 1970s “standards” and the fact that email should really be replaced with multiple different systems according to modern usage.
Only a tiny portion of modern emails really use the “anyone can send an email to anyone unannounced” capability that cause all the trouble with spam.
The usage for a password reset and universal access system for accounts all over should really be split into some kind of specialized system.
As for the rest, most emails seem to be messages from systems where we have accounts or performed some other kind of signup, those could easily be authenticated with a key provided at signup both to make filtering and easier and to be able to revoke authentication, not to mention prevent selling of addresses or usage by third parties after a security leak. A more structured format for common messages (e.g. invoices, notifications about instant messages on some website,…) would also be a good idea.
those could easily be authenticated with a key provided at signup both to make filtering and easier and to be able to revoke authentication
That’s what Tox links had for spam protection, an identifier of user plus an identifier of a permission. Agree on this.
More structured … I’m not sure, maybe a few types (not like MIME content type, but more technical, type not of content, but of message itself) of messages would be good - a letter, a notice, a contact request, a hypertext page, maybe even some common state CRUD (ok, this seems outside of email, I just aesthetically love the idea of something like an email collaborative filesystem with version control, and user friendly at the same time), a permission request/update/something (for some third resource).
Where a letter and a hypertext page would be almost open content as it is now, and a notice would have notice type and source, similarly with contact request (permission to write to us, like in normal Jabber clients, also solves those unannounced emails problem, sort of), and permission requests.
If so, then the password reset and such fit in well enough. Spam problem would be no more, at the same time all these service messages could be allowed, and having only ID and basic operational information wouldn’t be used for spam.
Speaking of something that needs tearing down and building anew, email is a good candidate for that.
Speaking of such things, an email client or an email server are never as monopolistic as Chrome.
So maybe email is a good candidate for something that should be torn down and built anew right after the Web.
Also email doesn’t have to be destroyed entirely, it’s very modular.
Where they had UUCP paths, and now have addresses in some services, just need to have John Doe <3cec7f8c438fa578dbd3a1557b822df469490a12>, with 3cec7f8c438fa578dbd3a1557b822df469490a12 being a hash of “johndoe” here and a hash of his pubkey in reality, and his pubkey can be retrieved from some public directory.
And have the letter signed by it (and encrypted possibly, though this of course would hurt server-side solutions of spam problem).
Frankly they can have a common replacement, in my humble opinion. When separating identities from servers, one can do the same with websites. How is a newsgroup fundamentally different from a replicated website collaboratively edited? If a letter can have a universal identifier, what prevents one to put a hyperlink to it? If we need scripts, what prevents us from having them in a letter’s content? If we need to reach a server by hostname and IP, what prevents us from doing just that from a letter, just the letter being the primary point of entry?
I just think that the old “vector hypertext Fidonet” joke is not so dumb, if you think what it could literally mean.
The problems with email are many but the two that would warrant rebuilding is that the technology is a mess of under specified 1970s “standards” and the fact that email should really be replaced with multiple different systems according to modern usage.
Only a tiny portion of modern emails really use the “anyone can send an email to anyone unannounced” capability that cause all the trouble with spam.
The usage for a password reset and universal access system for accounts all over should really be split into some kind of specialized system.
As for the rest, most emails seem to be messages from systems where we have accounts or performed some other kind of signup, those could easily be authenticated with a key provided at signup both to make filtering and easier and to be able to revoke authentication, not to mention prevent selling of addresses or usage by third parties after a security leak. A more structured format for common messages (e.g. invoices, notifications about instant messages on some website,…) would also be a good idea.
That’s what Tox links had for spam protection, an identifier of user plus an identifier of a permission. Agree on this.
More structured … I’m not sure, maybe a few types (not like MIME content type, but more technical, type not of content, but of message itself) of messages would be good - a letter, a notice, a contact request, a hypertext page, maybe even some common state CRUD (ok, this seems outside of email, I just aesthetically love the idea of something like an email collaborative filesystem with version control, and user friendly at the same time), a permission request/update/something (for some third resource).
Where a letter and a hypertext page would be almost open content as it is now, and a notice would have notice type and source, similarly with contact request (permission to write to us, like in normal Jabber clients, also solves those unannounced emails problem, sort of), and permission requests.
If so, then the password reset and such fit in well enough. Spam problem would be no more, at the same time all these service messages could be allowed, and having only ID and basic operational information wouldn’t be used for spam.
That’s how you get monetized spying enshittified email. Do you want monetized spying enshittified email?
Like Gmail?
Is that different from the unencrypted email we have now that is 99% spam and the other 99% are delivery problems due to anti-spam technologies?