10 ms·

Modern email can be built from borrowed parts

198 points by andros 3mo ago

amelius 3mo ago
> First-contact consent: an unknown sender doesn't get into the mailbox; they land in a "requests" box with their first message visible (like Signal's message requests). You accept, and the thread opens forever. A stranger can knock on your door, which is the essential property of mail, but they can't fill up your living room. I like this. Question: can this e-mail specification/implementation also replace direct-messaging protocols (like WhatsApp)?
- aboardRat4 3mo ago
  >Question: can this e-mail specification/implementation also replace direct-messaging protocols (like WhatsApp)? Deltachat
- fny 3mo ago
  Is there any reason they shouldn't be the same?
- xd1936 3mo ago
  This is the way hey.com operates. It's nice.
- MrGilbert 3mo ago
  > I like this. Honestly, I'd want this as a default. I wonder if a mailserver can be configure like this. Doesn't sound too hard, does it?
  - thesuitonym 3mo ago
    Believe it or don't, most mailservers actually are set up this way, but it's completely invisible to the user: https://en.wikipedia.org/wiki/Greylisting_(email) https://en.wikipedia.org/wiki/Greylisting_(email) Greylisting is not perfect, not even close, but it allows servers to reject huge amounts of garbage mail while allowing new mail from unexpected parties without user intervention.
    - dizhn 3mo ago
      It is similar but not the same thing. It does not have anything to do with the email being legit (non spam) or not. It only catches emails that do not do what they supposed to do when they are deferred for a little bit. They are supposed to try again later. (A super nice feature of email which protects you from losing all incoming emails when your server is down for a short time). The reasoning here is hopefully a spam script or software will not implement the standard properly or will skip apparently broken destinations. What parent wants is also possible and I remember people doing it as far back as the early 2000s. You would basically manually whitelist an email or have them bypass the list (once or always) with something like a key word or token sort of like a captcha which can be shared off band.
      - thesuitonym 3mo ago
        It's definitely possible, a few companies do it, and let me tell you: People hate it.
        BeetleB 3mo ago
        I've been doing it for almost a decade. Only one person has complained. I'm surprised by the hoops people are willing to go through to contact me. https://blog.nawaz.org/posts/2018/Sep/solving-my-email-problem/ https://blog.nawaz.org/posts/2018/Sep/solving-my-email-probl...
        thesuitonym 3mo ago
        I'm glad it works for you, but the overwhelming majority of people are not you, and they hate it.
        BeetleB 3mo ago
        Citation needed.
  - PaulRobinson 3mo ago
    "We" tried this in the late 1990s. I remember writing an exim config to do this a couple of ways back in my ISP times: 1. "The recipient will not get this message until you authenticate yourself as a legitimate sender at this URL [...]" - resulted in people never getting mail from no-reply addresses they cared about (banks, e-com, etc.) 2. "This sender has sent you an email, with this subject and this first paragraph. Click here to whitelist, here to blacklist" - created a lot of churn on first setup that users didn't like as a UX Baking it into the protocol - even now in SMTP and IMAP land - is doable, but would be resisted by email providers who, for example, make their money selling data to marketing agencies. Like, you know, Google, Microsoft, Yahoo... I've seen other approaches proposed - even at IETF level - over the years, including digital postage stamps (sender pays to send email, your server gets paid, and may reject non-stamped/paying email), but it's the usual network effect: until it becomes widely supported it won't "stick". The stuff that has been adopted has basically been stuff that Google likes, period.
    - baudehlo 3mo ago
      It also misses one of the biggest fundamental problems with SMTP: Lack of per-recipient replies. Though you could potentially mandate a single recipient per request. We wrote a plugin to emulate that in Haraka, where you just 400 (temp fail) each subsequent recipient. The downside is some sources just plain don't retry.
      - inigyou 3mo ago
        LMTP is a small modification of SMTP with a per-recipient response code - but I'm not sure what it's intended for. It isn't used on the internet. It's sometimes used as IPC within a mail server.
        baudehlo 3mo ago
        LMTP is for delivering to an IMAP (or JMAP) mailbox, generally. We also have a plugin for that. But it has certain flaws for exposing it to the internet (I just forget what they are right now).
  - ponyous 3mo ago
    Spark email client supports this. It’s great
  - stackghost 3mo ago
    Pretty sure 37signals' email/calendar offering ("Hey") works this way.
- TheOtherHobbes 3mo ago
  The unknown request will be buried in spam - a problem we have already, but worse. And I do not want an infinite thread conversation. I want to be able to split off - and perhaps archive and export - different conversations by topic. I recently had to some legal things, which included forwarding copies of a certain conversation to a lawyer. This turns out to be unreasonably difficult because email clients quote previous conversations. You want a clean thread of comment and reply about a specific topic. You don't get that. You do get it on chat services, but there's no option there to create sub-conversations. If I was redesigning email I would think long and hard about different use cases and workflows and start with an RFC. Protocols are far downstream of that.
  - tcfhgj 3mo ago
    > You do get it on chat services, but there's no option there to create sub-conversations. It's called threads - even Matrix has these
  - jancsika 3mo ago
    > The unknown request will be buried in spam - a problem we have already, but worse. I feel like every one of these suggested changes to email comes with a functionally equivalent parody magic trick. For this one, a magician has two stacks of cards: a tall stack of "spam" cards, and a small stack of "inbox" cards. The magician moves the stacks apart to make a spot for a new "request" stack. To start the stack, they pick up five "request" cards from the inbox stack with one hand while subtly pushing the entire stack of "spam" cards with the other hand to spot they made for the "request" stack. They then pass the five cards they were holding behind their back, revealing them with the opposite hand and finally shuffling them into the now tall stack of "request" cards. Ta da! > If I was redesigning email I would think long and hard about different use cases and workflows and start with an RFC. A magician sweeps 17 sloppy stacks of cards off the table. They then show how the first 15 cards they pick up can more easily be arranged in only three stacks. Voila! Everybody claps. While the audience members put money in the hat, the pedants stick around and watch the magician pick up the rest of the cards and end up with 18 sloppy stacks by the time the audience for the next show arrives. Edit: clarification Edit 2: I forgot this part: "Protocols are far downstream of that." So imagine 8 tiny tables below the main one which somehow end up with more than 52 cards in each of their 17 sloppy stacks.
- dzonga 3mo ago
  other email clients/services like Hey etc do this. at one point Gmail had a service for this - if I remember well - but google being google - I guess it was just a promotion project for someone.
- BeetleB 3mo ago
  I (and many others) do this: https://blog.nawaz.org/posts/2018/Sep/solving-my-email-problem/ https://blog.nawaz.org/posts/2018/Sep/solving-my-email-probl... (Not answering your question, but referring to the approach).
- inigyou 3mo ago
  The original Delta Chat literally implemented WhatsApp-over-email. They've since changed the design so it uses its own protocol and servers instead of email.
syhol 3mo ago
I'm very excited by this idea. I feel like email/chat is ripe for reinvention. I don't agree with "Domain control as a fallback", as the author said "a domain is not owned, it is rented" and I want to normalise the idea that if you lose your private key, you need to start again. I hate that we keep giving so much authority to domains, it's such a big weakness. The author even left the key rotation chain out of the initial implementation. I still think root/signer keys or sigchains are decent options.
8organicbits 3mo ago
I think the network effects make email hard to replace, virtually everyone online has an email address. If this could include a migration path, with backwards compatibility with SMTP, I think it would have a better shot of getting adoption. Modern email already depends on HTTP, with protocols like MTA-STS (https://www.rfc-editor.org/info/rfc8461/ https://www.rfc-editor.org/info/rfc8461/) using HTTPS/TLS to improve transit encryption, or Web Key Directory (https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/ https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-s...) which uses HTTP for public key distribution. Personally I think these incremental improvements of SMTP are more promising than replacements, but we deserve better email however we can build it.
- myaccountonhn 3mo ago
  The sad thing is that the only successful attempts at tackling its popularity are proprietary, closed ecosystems.
- citizenpaul 3mo ago
  Yeah, this subject comes up every couple months. The problem is not getting it working. Its that email is a captured system at this point and the real work is various reputation management processes that the big providers control or you can't send email to/from them. They also have no real interest in letting you be your own email provider so its just pushing a rock up a hill grind, for what? To save <$100 a year piggybacking on another provider as a custom domain? or just use a free provider?
  - calvinmorrison 3mo ago
    Having worked at a provider, that is not the psychology at all. The #1 priority is to keep the mail flowing. #2 incremental improvements to security, spam, reputation is a distant second. The other thing is, providers already know and have people who work on email standards, work in the ecosystem, etc. So once you're inside, with people who know whats going on, know the tools, know how things work intuitively without having to read a manual, theres less desire to change.
wuschel 3mo ago
> Optional postage for strangers: the server can answer a first contact with a 402. Configurable per mailbox; the cost of cold spamming stops being zero. Interesting take re putting a cost on spam. Perhaps another take would be functionally implementing introductions. > First-contact consent: an unknown sender doesn't get into the mailbox; they land in a "requests" box with their first message visible (like Signal's message requests). You accept, and the thread opens forever. A stranger can knock on your door, which is the essential property of mail, but they can't fill up your living room. Unfortunately, this will only move the problem, and only reduce it in the case when all outside communication is ignored.
- philipwhiuk 3mo ago
  Yeah the 'Requests' folder just becomes the new Inbox folder. Email clients already highlight/filter people in your contacts
  - Multicomp 3mo ago
    We could add a friend-of-friend for 1 degree of separation (Alice gets an email from Bob, she doesn't know Bob, so it would go into her Requests folder. But Charlie knows Bob and has said 'yes this guy is legit' and Alice has configured her email to trust Charlie's email recommendations up to 2 degrees of separation, so it goes into the inbox with an explanation that it was allowed by Charlie's trust of Bob). And poof, we've poorly remembered Web of Trust from 20 years ago! Overall I do love the idea of HTMP and if we could get it to easily fall back to standard old bad email, I think it could start as a niche and then upgrade towards HTMP over time as more clients adopted support for it.
endre 3mo ago
still better than CoI
AKSF_Ackermann 3mo ago
Content-addressed email breaks mailing lists, as those need to be able to add headers for subscribe/unsubscribe/list id, etc. There is a reason DKIM allows you to pick which headers to sign.
- kamma4434 3mo ago
  Do we need mailing lists at all?
  - ninalanyon 3mo ago
    I Linus Torvalds needs them. And that's a good enough reason for their existence as far as I'm concerned.
gostsamo 3mo ago
Unfortunately, stopped reading at one moment, because though the idea might be interesting, the packaging was unbearable. The obnoxious real time visitors counter seriously screws with my screen reader. I don't care how many people are reading this every 3 seconds updated not only with numbers, but with randomly chosen emois in my speech stream. If you have a website, please, don't subject your visitors to something like that.
- andros 3mo ago
  I'm sorry to hear about your bad experience. I've hidden the counter for screen readers. Please try again when you're ready.
  - jeffbee 3mo ago
    The combination of "I have an idea for changing one of the fundamental experiences of modern life" and "my website is obnoxious and hostile" didn't really work for me.
    - gostsamo 3mo ago
      Mistakes happen.
    - andros 3mo ago
      The entire website is accessible; I dedicated ample time to it. This was a minor oversight, but I wouldn't call it hostility.
      - hju22_-3 3mo ago
        To the letter of the word? Perhaps. To the spirit? Hmm. Strange then that you reject critique elsewhere. Accessibility is not just a checkbox, it's to consider and test the actual use of it.
  - gostsamo 3mo ago
    Thanks for the change.
deleted 3mo ago
[deleted]
ccamrobertson 3mo ago
I think a lot of these concepts are fun/interesting, but I like that email today functions more like a mailbox than WhatsApp or Telegram. Whilst digital (or paper) spam is obnoxious I dislike the idea of binning every sender into a "unread" box until I approve them. I miss unreads all the time across apps like X and Telegram. As a first step I would focus on something like broad S/MIME support. Unfortunately I suspect that the biggest email providers are disincentivized from doing this as it would disrupt their business models.
thesuitonym 3mo ago
> Let's design the successor to email on top of HTTP You can stop there, I've heard enough. Not everything is hypertext.
- andros 3mo ago
  Usually, informed people only read the headline.
- beej71 3mo ago
  And HTTP transports many, many more things than hypertext. It seems like a sensible choice for this use case in terms of capabilities.
  - inigyou 3mo ago
    Why, what advantage does adding the extra layer bring? You can just open a socket and send JSON to it, you know, you don't need this layer. But if the layer brings advantages then you should, but you have to explain the advantages.
    - beej71 2mo ago
      Since it's email, we probably want to send content of several different types, and MIME is baked into HTTP. And the commonality with email-style headers is nice, as well.
- jjice 3mo ago
  From the first paragraph: >The goal is not to replace the current mail system, heaven forbid!, but to learn, have fun and discover current technologies to swap out every element: sending, receiving, gateway, keys, and so on. It's all for fun.
aboardRat4 3mo ago
Self-ejecting panels on three sides of the website are a horrible user experience. Other than that... The most important thing is not the protocol, it's the gui. At the moment email's gui is horrible on all platforms without exception. If/when a decent gui appears, protocols will follow. Also, JMAP did reading can probably be just WebDAV?
- andros 3mo ago
  Why do you find the panel experience so bad?
  - flexagoon 3mo ago
    It's very annoying on mobile, covering half of the page all the time
    - andros 3mo ago
      When you scroll down, they should all disappear. Do you have JavaScript disabled? What browser and device are you using?
      - zahlman 3mo ago
        FWIW, I'm on desktop but I do have JS disabled (more precisely, I use NoScript). This results in the top and left-side bars staying decorative and unobtrusive, but the concurrent visitor counter thingy is floating well above the bottom-right of the page. But then, as I shrink in the page width, the left-side bar and the concurrent visitor counter swap sides, and also a bunch of the content from the top is added to a new bar at the bottom. Eventually, the horizontal space between the side components becomes irrelevant such that they function as an additional bottom bar. At which point, maybe 40% of the vertical space is used for navigation and other shiny toys. This is really annoying, and the overall experience is inconsistent across widths. (Also, at all widths, the top-bar has a transparent background, so main page text interferes with top-bar text as it scrolls.) All of this is done in CSS, so presumably it can be fixed that way too.
philipwhiuk 3mo ago
Old version: * DNS lookup for MX record New version * DNS lookup for A record * HTTP request for .wellknown/htmp/known_hosts Not sure why this is being considered as an improvement? > each mailbox of a domain on a different provider Why is this useful/necessary or even 'good'?
- rzerowan 3mo ago
  Id think its for enduser flexibility and convenience. Its more involved to alter DNS records vs just adding a text line to a webpage and hitting that default endpoint as standard. Same way LetsEncrypt allows the easiest setup with the .wellknown endpoint , where a user may not have DNS access beyond the initial A record setup.
  - inigyou 3mo ago
    Why is one more involved than the other? DNS is just a text file too. And you might not even have a web server. Why should mail servers be required to also be web servers? And what if the web server for that domain is already a completely separate system, and now you force it to be linked to the email system?
- stackskipton 3mo ago
  It's not a good idea, I'd call it terrible in fact. We have MX Records, might as well use those. If not, use SRV records. Requiring mail server to involved in root of the domain is terrible idea.
- 8organicbits 3mo ago
  Email currently uses an HTTP request to https://mta-sts.<domain>/.well-known/mta-sts.txt, per RFC 8461. Depending on HTTPS/TLS instead of DNSSEC is one major reason you see this approach gaining popularity.
  - winstonwinston 3mo ago
    To be fair, it’s used by only those who choose to use horrendous “mta-sts” instead of DNS-based Authentication of Named Entities (DANE). I might add that if you want to enforce SMTP TLS, you can do just that without mta-sts or DANE.
jfb 3mo ago
I like that the author at least head fakes towards postage, which is how spam gets solved, for real. It's far too late for SMTP, but I don't mind folks thinking hard about it.
- inigyou 3mo ago
  I thought there were good reasons it was repeatedly rejected in the past
zdw 3mo ago
I'd take this the opposite direction - HTTP should get more like SMTP. Take this thought experiment - how does nearly every other standard protocol (DNS, SMTP, etc.) except for HTTP survive at scale without server-side load balancing? Thankfully we're heading in this direction due to happy eyeballs and related client-side retry mechanisms.
dinkelberg 3mo ago
Copies the mistake from PGP with the unencrypted metadata.
bellowsgulch 3mo ago
This is measurably worse in every way if only by saying you've thrown out everyone's existing mail stacks. No, no one wants to do that.
teddyh 3mo ago
More people should be aware of their history. This text made the rounds in the late 1990s as spam was starting to become a problem. Everybody and their dog had their own “ultimate solution” to the spam problem, which they all thought was obviously the correct one, but all of them were more or less equally unworkable: <https://craphound.com/spamsolutions.txt https://craphound.com/spamsolutions.txt>
- zahlman 3mo ago
  To be clear, "this text" refers to the link at the end, not to TFA, correct?
  - teddyh 3mo ago
    Yes. Sorry for being unclear.
jerf 3mo ago
I would advise reconsidering keeping the current format exactly. Something that would allow conventional email addresses to kept in a list that disambiguates them unambiguously would probably be a good idea. You don't want to embed the entire email in JSON. Too many parsers past, present, and future tend to want to decode the entire JSON document into memory before doing anything else, and so you'd be forcing entire email documents to be held in memory at scale, which causes you major problems. I'd recommend something more like either a JSON header that defines what parts are in the email, followed by a normal MIME document, which is perfectly normal in HTTP with other things that use the format as well, or having the top level continue to be a MIME document and specify that the first part must be a JSON document containing the headers. JSON replacing the headers is generally something that would be a good idea, though. That improves the ability of more language environments to be able to handle the email as a stream or in chunks with "normal" libraries and practices. MIME parsers in languages that tend to favor pulling everything into RAM as a string are still more likely to have been forced to face this issue already.
- zahlman 3mo ago
  > You don't want to embed the entire email in JSON. Too many parsers past, present, and future tend to want to decode the entire JSON document into memory before doing anything else, and so you'd be forcing entire email documents to be held in memory at scale Why? Even if your system loads emails into memory a whole email at a time, that doesn't imply that it will load large numbers of emails simultaneously. The kind of processing that can be done by stream-processing large numbers of emails in parallel seems rather limited to me. > I'd recommend something more like either a JSON header that defines what parts are in the email, followed by a normal MIME document, which is perfectly normal in HTTP with other things that use the format as well, or having the top level continue to be a MIME document and specify that the first part must be a JSON document containing the headers. JSON replacing the headers is generally something that would be a good idea, though. If we're specifically talking about being able to short-circuit after headers, then why not a JSON header followed by JSON representation of the body?
  - jerf 2mo ago
mrsssnake 3mo ago
Here is another, not so new, idea: Username is your public key, password is your private key. So we get end to end encryption and account ownership out of the box. Something similar to how .onion addresses work. Needing easy to remember addresses? Build aliases on top of that. Needing server-side automation? Handle trusted server your private key. Also, almost everyone carry a 24/7 powered and Internet connected device in their pockets. The Internet - network that allows globally sending any data between devices. Maybe with full redesign third-party email servers should be made optional. I believe we should focus less on how to redesign whole service and build more universal layers instead. First, vsending any data to any machine. Second, optionally remotely accessing our data. Third, mail-like format of data.
- jcgl 3mo ago
  Tightly coupling identity to cryptosystems should be entirely dismissed for anything that is supposed to have broad adoption. First off, these systems always require indefinitely-lived secrets. To rotate keys (or the whole cryptosystem—think future possible quantum computers) is to change identity. Therefore, to change keys is to break the previous identity. Anything that requires users to think about long-term secrets is user hostile and leads to a fragile system. Second, the economics of pubkey-as-address are untenable. Can you imagine publishing .onion addresses on billboards and business cards, let alone sharing them verbally? Absolutely not. Unless there’s something I’m missing (please do say), these problems are intractable when you’re dealing with cryptosystem-based identity. In the end, identity and naming and fundamentally human concerns. If you try to kludge around this with purely technical solutions, all you’ll end up with is a system that doesn’t adequately reflect what identity means to people. Good systems support this (DNS, email); bad systems fight this (cryptocurrency, nostr).
  - inigyou 3mo ago
    We need more and more varied DNS zones so there's competition between them. And not gTLDs which are just extensions of .us, but zones with genuinely independent administration.
    - 3mo ago
Mohiuddin7 3mo ago
[dead]
RajT88 3mo ago
A better protocol for email seems like it should be lower on the list compared to a better protocol for phone calls. And don't just say we'll build that on HTTP too!
- dredmorbius 3mo ago
  I'm thinking through the latter presently: <https://mastodon.social/@dredmorbius@toot.cat/116984051578438780 https://mastodon.social/@dredmorbius@toot.cat/11698405157843...>. And I see a few ideas that might be worth picking up from this proposal. Voice and text comms ... have much in common.
BeetleB 3mo ago
I don't want to replicate email. I want to fix it. Sending email should not be free. It should be really, really cheap to send an email to one person (like a fraction of a fraction of a cent), but get exponentially more expensive the more you send. People shouldn't be able to send emails to you without your prior approval (which you can revoke at an instant). The recipient should be able to charge a tack-on fee for having email sent to him. I should be able to charge annoying people a lot to send to me, and charge my friends almost nothing. People who send annoying stuff to me should pay more to get my attention. All of a sudden, forwarding that stupid article without thinking about the content (or even reading the article they're sending) will be second guessed. Save the money (and time), by sending only worthwhile stuff that you penned.
- beaugunderson 3mo ago
  > People shouldn't be able to send emails to you without your prior approval (which you can revoke at an instant). this sounds terrible... i've gotten so many useful random emails from strangers over the years.
  - BeetleB 3mo ago
    Depends how it's designed. I've been doing something similar for almost a decade. If I get an email from a non-whitelisted person, they get an auto reply asking them to go through a simple hoop. Once they do that, the email lands in my inbox. Yes, many people go through that hoop! I can still see their emails if they don't. They site in a Quarantine folder. I used to look at it frequently to catch the occasional straggler, but I rarely do that now. I've set up an LLM to go through all my quarantined emails in the last N days, and send me an email on which of the quarantined emails probably should be viewed. I'm OK missing out on a (very rare) good email if it means I don't have to deal with crap mass mails. And let me tell you: Life is great when you don't deal with mass mails.
    - beaugunderson 3mo ago
      ah, quarantine makes sense i handle the overload a different way... i age everything out of my inbox one day at a time, each gets a label showing the remaining days; they start at 7 and count down. that way i only ever have 7 days of email to look at. it also makes it clear who the big offenders are... if 10% of the emails are some new marketing thing it's easy to see and unsubscribe. i do hate that there's still so much manual work involved though, i would love if marketers had to pay.
mlhpdx 3mo ago
HTTP? It would be a more interesting thought experiment with CoAP. And, is it really “modern” if it still uses a model (essentially) requiring stateful compute like JMAP?
TeeMassive 3mo ago
Asymmetric signature generation has been a solved problem for more than a quarter of a century. So are distributed hash tables. I can't believe email hasn't been replaced. My take on it is to follow the money. Microsoft, Google and Yahoo have a vested interest in being the only big identity providers along probably with some 3 letters agencies.
astrodust 3mo ago
The irony here that HTTP headers are descended directly from RFC822 email headers.
rbanffy 3mo ago
The fact nobody reinvented e-mail on top of a different set of standards is a good indication that the current stack is not as broken as some people would like to think. It reminds me of a previous life, at a previous time, when everybody reinvented the content management system based on slightly different approaches, because they thought existing CMSs were too big. It starts with serving pages, then you want multiple templates, then you want accessibility, then you want to authenticate with LDAP, then you want to use the LDAP groups as your groups, and then you need to tie groups to roles, because groups mean one thing to the org, and roles mean another just to the CMS, then you realize a relational database isn't that good a match, then you realize it would be convenient to attach some logic, and a document database is no longer a great idea, then you need multiple datastores for content, then you need new workflows on top, then... The devil is in the corner cases. They have been solved in different ways, by different parties, for decades, not always documented ("because it was just a simple thing, that once, and we fixed it"). Unless you've been there, you are doomed to make the same mistakes, and nobody was everywhere to avoid all mistakes. Why not dedicate an effort to migrate all the COBOL code currently running almost every banking transaction? That should be easy ;-)
- HumblyTossed 3mo ago
  >> The fact nobody reinvented e-mail on top of a different set of standards is a good indication that the current stack is not as broken as some people would like to think. email is one of those technologies that "just works" but so many people seem to think it needs to be "fixed". it's generally very reliable and so people should just accept that and be grateful. It could be worse - it could be enshittified like so much other technology.
  - HDBaseT 3mo ago
    > it's generally very reliable and so people should just accept that and be grateful It's only really "very reliable" if you use Google or Microsoft for email, since they are the arbitrator of modern email.
    - 3mo ago
1saadcodes 3mo ago
I like the approach of building on existing standards instead of starting from scratch. That said, solving communication between users is a very different problem from replacing a system that has to work with literally everyone
inigyou 3mo ago
ActivityPub is literally SMTP over HTTP.
Keywordstat 3mo ago
I built KeywordStat, check it out. https://keywordstat.co/ https://keywordstat.co/
ojinai 2mo ago
[flagged]

198 points by andros 3mo ago

> First-contact consent: an unknown sender doesn't get into the mailbox; they land in a "requests" box with their first message visible (like Signal's message requests). You accept, and the thread opens forever. A stranger can knock on your door, which is the essential property of mail, but they can't fill up your living room. I like this. Question: can this e-mail specification/implementation also replace direct-messaging protocols (like WhatsApp)?

aboardRat4 3mo ago
>Question: can this e-mail specification/implementation also replace direct-messaging protocols (like WhatsApp)? Deltachat
fny 3mo ago
Is there any reason they shouldn't be the same?
xd1936 3mo ago
This is the way hey.com operates. It's nice.
MrGilbert 3mo ago
> I like this. Honestly, I'd want this as a default. I wonder if a mailserver can be configure like this. Doesn't sound too hard, does it?
- thesuitonym 3mo ago
  Believe it or don't, most mailservers actually are set up this way, but it's completely invisible to the user: https://en.wikipedia.org/wiki/Greylisting_(email) https://en.wikipedia.org/wiki/Greylisting_(email) Greylisting is not perfect, not even close, but it allows servers to reject huge amounts of garbage mail while allowing new mail from unexpected parties without user intervention.
  - dizhn 3mo ago
    It is similar but not the same thing. It does not have anything to do with the email being legit (non spam) or not. It only catches emails that do not do what they supposed to do when they are deferred for a little bit. They are supposed to try again later. (A super nice feature of email which protects you from losing all incoming emails when your server is down for a short time). The reasoning here is hopefully a spam script or software will not implement the standard properly or will skip apparently broken destinations. What parent wants is also possible and I remember people doing it as far back as the early 2000s. You would basically manually whitelist an email or have them bypass the list (once or always) with something like a key word or token sort of like a captcha which can be shared off band.
    - thesuitonym 3mo ago
      It's definitely possible, a few companies do it, and let me tell you: People hate it.
      - BeetleB 3mo ago
        I've been doing it for almost a decade. Only one person has complained. I'm surprised by the hoops people are willing to go through to contact me. https://blog.nawaz.org/posts/2018/Sep/solving-my-email-problem/ https://blog.nawaz.org/posts/2018/Sep/solving-my-email-probl...
        thesuitonym 3mo ago
        I'm glad it works for you, but the overwhelming majority of people are not you, and they hate it.
        BeetleB 3mo ago
        Citation needed.
- PaulRobinson 3mo ago
  "We" tried this in the late 1990s. I remember writing an exim config to do this a couple of ways back in my ISP times: 1. "The recipient will not get this message until you authenticate yourself as a legitimate sender at this URL [...]" - resulted in people never getting mail from no-reply addresses they cared about (banks, e-com, etc.) 2. "This sender has sent you an email, with this subject and this first paragraph. Click here to whitelist, here to blacklist" - created a lot of churn on first setup that users didn't like as a UX Baking it into the protocol - even now in SMTP and IMAP land - is doable, but would be resisted by email providers who, for example, make their money selling data to marketing agencies. Like, you know, Google, Microsoft, Yahoo... I've seen other approaches proposed - even at IETF level - over the years, including digital postage stamps (sender pays to send email, your server gets paid, and may reject non-stamped/paying email), but it's the usual network effect: until it becomes widely supported it won't "stick". The stuff that has been adopted has basically been stuff that Google likes, period.
  - baudehlo 3mo ago
    It also misses one of the biggest fundamental problems with SMTP: Lack of per-recipient replies. Though you could potentially mandate a single recipient per request. We wrote a plugin to emulate that in Haraka, where you just 400 (temp fail) each subsequent recipient. The downside is some sources just plain don't retry.
    - inigyou 3mo ago
      LMTP is a small modification of SMTP with a per-recipient response code - but I'm not sure what it's intended for. It isn't used on the internet. It's sometimes used as IPC within a mail server.
      - baudehlo 3mo ago
        LMTP is for delivering to an IMAP (or JMAP) mailbox, generally. We also have a plugin for that. But it has certain flaws for exposing it to the internet (I just forget what they are right now).
- ponyous 3mo ago
  Spark email client supports this. It’s great
- stackghost 3mo ago
  Pretty sure 37signals' email/calendar offering ("Hey") works this way.
TheOtherHobbes 3mo ago
The unknown request will be buried in spam - a problem we have already, but worse. And I do not want an infinite thread conversation. I want to be able to split off - and perhaps archive and export - different conversations by topic. I recently had to some legal things, which included forwarding copies of a certain conversation to a lawyer. This turns out to be unreasonably difficult because email clients quote previous conversations. You want a clean thread of comment and reply about a specific topic. You don't get that. You do get it on chat services, but there's no option there to create sub-conversations. If I was redesigning email I would think long and hard about different use cases and workflows and start with an RFC. Protocols are far downstream of that.
- tcfhgj 3mo ago
  > You do get it on chat services, but there's no option there to create sub-conversations. It's called threads - even Matrix has these
- jancsika 3mo ago
  > The unknown request will be buried in spam - a problem we have already, but worse. I feel like every one of these suggested changes to email comes with a functionally equivalent parody magic trick. For this one, a magician has two stacks of cards: a tall stack of "spam" cards, and a small stack of "inbox" cards. The magician moves the stacks apart to make a spot for a new "request" stack. To start the stack, they pick up five "request" cards from the inbox stack with one hand while subtly pushing the entire stack of "spam" cards with the other hand to spot they made for the "request" stack. They then pass the five cards they were holding behind their back, revealing them with the opposite hand and finally shuffling them into the now tall stack of "request" cards. Ta da! > If I was redesigning email I would think long and hard about different use cases and workflows and start with an RFC. A magician sweeps 17 sloppy stacks of cards off the table. They then show how the first 15 cards they pick up can more easily be arranged in only three stacks. Voila! Everybody claps. While the audience members put money in the hat, the pedants stick around and watch the magician pick up the rest of the cards and end up with 18 sloppy stacks by the time the audience for the next show arrives. Edit: clarification Edit 2: I forgot this part: "Protocols are far downstream of that." So imagine 8 tiny tables below the main one which somehow end up with more than 52 cards in each of their 17 sloppy stacks.
dzonga 3mo ago
other email clients/services like Hey etc do this. at one point Gmail had a service for this - if I remember well - but google being google - I guess it was just a promotion project for someone.
BeetleB 3mo ago
I (and many others) do this: https://blog.nawaz.org/posts/2018/Sep/solving-my-email-problem/ https://blog.nawaz.org/posts/2018/Sep/solving-my-email-probl... (Not answering your question, but referring to the approach).
inigyou 3mo ago
The original Delta Chat literally implemented WhatsApp-over-email. They've since changed the design so it uses its own protocol and servers instead of email.

syhol 3mo ago

I'm very excited by this idea. I feel like email/chat is ripe for reinvention. I don't agree with "Domain control as a fallback", as the author said "a domain is not owned, it is rented" and I want to normalise the idea that if you lose your private key, you need to start again. I hate that we keep giving so much authority to domains, it's such a big weakness. The author even left the key rotation chain out of the initial implementation. I still think root/signer keys or sigchains are decent options.

8organicbits 3mo ago

I think the network effects make email hard to replace, virtually everyone online has an email address. If this could include a migration path, with backwards compatibility with SMTP, I think it would have a better shot of getting adoption. Modern email already depends on HTTP, with protocols like MTA-STS (https://www.rfc-editor.org/info/rfc8461/ https://www.rfc-editor.org/info/rfc8461/) using HTTPS/TLS to improve transit encryption, or Web Key Directory (https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/ https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-s...) which uses HTTP for public key distribution. Personally I think these incremental improvements of SMTP are more promising than replacements, but we deserve better email however we can build it.

myaccountonhn 3mo ago
The sad thing is that the only successful attempts at tackling its popularity are proprietary, closed ecosystems.
citizenpaul 3mo ago
Yeah, this subject comes up every couple months. The problem is not getting it working. Its that email is a captured system at this point and the real work is various reputation management processes that the big providers control or you can't send email to/from them. They also have no real interest in letting you be your own email provider so its just pushing a rock up a hill grind, for what? To save <$100 a year piggybacking on another provider as a custom domain? or just use a free provider?
- calvinmorrison 3mo ago
  Having worked at a provider, that is not the psychology at all. The #1 priority is to keep the mail flowing. #2 incremental improvements to security, spam, reputation is a distant second. The other thing is, providers already know and have people who work on email standards, work in the ecosystem, etc. So once you're inside, with people who know whats going on, know the tools, know how things work intuitively without having to read a manual, theres less desire to change.

wuschel 3mo ago

> Optional postage for strangers: the server can answer a first contact with a 402. Configurable per mailbox; the cost of cold spamming stops being zero. Interesting take re putting a cost on spam. Perhaps another take would be functionally implementing introductions. > First-contact consent: an unknown sender doesn't get into the mailbox; they land in a "requests" box with their first message visible (like Signal's message requests). You accept, and the thread opens forever. A stranger can knock on your door, which is the essential property of mail, but they can't fill up your living room. Unfortunately, this will only move the problem, and only reduce it in the case when all outside communication is ignored.

philipwhiuk 3mo ago
Yeah the 'Requests' folder just becomes the new Inbox folder. Email clients already highlight/filter people in your contacts
- Multicomp 3mo ago
  We could add a friend-of-friend for 1 degree of separation (Alice gets an email from Bob, she doesn't know Bob, so it would go into her Requests folder. But Charlie knows Bob and has said 'yes this guy is legit' and Alice has configured her email to trust Charlie's email recommendations up to 2 degrees of separation, so it goes into the inbox with an explanation that it was allowed by Charlie's trust of Bob). And poof, we've poorly remembered Web of Trust from 20 years ago! Overall I do love the idea of HTMP and if we could get it to easily fall back to standard old bad email, I think it could start as a niche and then upgrade towards HTMP over time as more clients adopted support for it.

endre 3mo ago

still better than CoI

AKSF_Ackermann 3mo ago

Content-addressed email breaks mailing lists, as those need to be able to add headers for subscribe/unsubscribe/list id, etc. There is a reason DKIM allows you to pick which headers to sign.

kamma4434 3mo ago
Do we need mailing lists at all?
- ninalanyon 3mo ago
  I Linus Torvalds needs them. And that's a good enough reason for their existence as far as I'm concerned.

gostsamo 3mo ago

Unfortunately, stopped reading at one moment, because though the idea might be interesting, the packaging was unbearable. The obnoxious real time visitors counter seriously screws with my screen reader. I don't care how many people are reading this every 3 seconds updated not only with numbers, but with randomly chosen emois in my speech stream. If you have a website, please, don't subject your visitors to something like that.

andros 3mo ago
I'm sorry to hear about your bad experience. I've hidden the counter for screen readers. Please try again when you're ready.
- jeffbee 3mo ago
  The combination of "I have an idea for changing one of the fundamental experiences of modern life" and "my website is obnoxious and hostile" didn't really work for me.
  - gostsamo 3mo ago
    Mistakes happen.
  - andros 3mo ago
    The entire website is accessible; I dedicated ample time to it. This was a minor oversight, but I wouldn't call it hostility.
    - hju22_-3 3mo ago
      To the letter of the word? Perhaps. To the spirit? Hmm. Strange then that you reject critique elsewhere. Accessibility is not just a checkbox, it's to consider and test the actual use of it.
- gostsamo 3mo ago
  Thanks for the change.

deleted 3mo ago

[deleted]

ccamrobertson 3mo ago

I think a lot of these concepts are fun/interesting, but I like that email today functions more like a mailbox than WhatsApp or Telegram. Whilst digital (or paper) spam is obnoxious I dislike the idea of binning every sender into a "unread" box until I approve them. I miss unreads all the time across apps like X and Telegram. As a first step I would focus on something like broad S/MIME support. Unfortunately I suspect that the biggest email providers are disincentivized from doing this as it would disrupt their business models.

thesuitonym 3mo ago

> Let's design the successor to email on top of HTTP You can stop there, I've heard enough. Not everything is hypertext.

andros 3mo ago
Usually, informed people only read the headline.
beej71 3mo ago
And HTTP transports many, many more things than hypertext. It seems like a sensible choice for this use case in terms of capabilities.
- inigyou 3mo ago
  Why, what advantage does adding the extra layer bring? You can just open a socket and send JSON to it, you know, you don't need this layer. But if the layer brings advantages then you should, but you have to explain the advantages.
  - beej71 2mo ago
    Since it's email, we probably want to send content of several different types, and MIME is baked into HTTP. And the commonality with email-style headers is nice, as well.
jjice 3mo ago
From the first paragraph: >The goal is not to replace the current mail system, heaven forbid!, but to learn, have fun and discover current technologies to swap out every element: sending, receiving, gateway, keys, and so on. It's all for fun.

aboardRat4 3mo ago

Self-ejecting panels on three sides of the website are a horrible user experience. Other than that... The most important thing is not the protocol, it's the gui. At the moment email's gui is horrible on all platforms without exception. If/when a decent gui appears, protocols will follow. Also, JMAP did reading can probably be just WebDAV?

andros 3mo ago
Why do you find the panel experience so bad?
- flexagoon 3mo ago
  It's very annoying on mobile, covering half of the page all the time
  - andros 3mo ago
    When you scroll down, they should all disappear. Do you have JavaScript disabled? What browser and device are you using?
    - zahlman 3mo ago
      FWIW, I'm on desktop but I do have JS disabled (more precisely, I use NoScript). This results in the top and left-side bars staying decorative and unobtrusive, but the concurrent visitor counter thingy is floating well above the bottom-right of the page. But then, as I shrink in the page width, the left-side bar and the concurrent visitor counter swap sides, and also a bunch of the content from the top is added to a new bar at the bottom. Eventually, the horizontal space between the side components becomes irrelevant such that they function as an additional bottom bar. At which point, maybe 40% of the vertical space is used for navigation and other shiny toys. This is really annoying, and the overall experience is inconsistent across widths. (Also, at all widths, the top-bar has a transparent background, so main page text interferes with top-bar text as it scrolls.) All of this is done in CSS, so presumably it can be fixed that way too.

philipwhiuk 3mo ago

Old version: * DNS lookup for MX record New version * DNS lookup for A record * HTTP request for .wellknown/htmp/known_hosts Not sure why this is being considered as an improvement? > each mailbox of a domain on a different provider Why is this useful/necessary or even 'good'?

rzerowan 3mo ago
Id think its for enduser flexibility and convenience. Its more involved to alter DNS records vs just adding a text line to a webpage and hitting that default endpoint as standard. Same way LetsEncrypt allows the easiest setup with the .wellknown endpoint , where a user may not have DNS access beyond the initial A record setup.
- inigyou 3mo ago
  Why is one more involved than the other? DNS is just a text file too. And you might not even have a web server. Why should mail servers be required to also be web servers? And what if the web server for that domain is already a completely separate system, and now you force it to be linked to the email system?
stackskipton 3mo ago
It's not a good idea, I'd call it terrible in fact. We have MX Records, might as well use those. If not, use SRV records. Requiring mail server to involved in root of the domain is terrible idea.
8organicbits 3mo ago
Email currently uses an HTTP request to https://mta-sts.<domain>/.well-known/mta-sts.txt, per RFC 8461. Depending on HTTPS/TLS instead of DNSSEC is one major reason you see this approach gaining popularity.
- winstonwinston 3mo ago
  To be fair, it’s used by only those who choose to use horrendous “mta-sts” instead of DNS-based Authentication of Named Entities (DANE). I might add that if you want to enforce SMTP TLS, you can do just that without mta-sts or DANE.

jfb 3mo ago

I like that the author at least head fakes towards postage, which is how spam gets solved, for real. It's far too late for SMTP, but I don't mind folks thinking hard about it.

inigyou 3mo ago
I thought there were good reasons it was repeatedly rejected in the past

zdw 3mo ago

I'd take this the opposite direction - HTTP should get more like SMTP. Take this thought experiment - how does nearly every other standard protocol (DNS, SMTP, etc.) except for HTTP survive at scale without server-side load balancing? Thankfully we're heading in this direction due to happy eyeballs and related client-side retry mechanisms.

dinkelberg 3mo ago

Copies the mistake from PGP with the unencrypted metadata.

bellowsgulch 3mo ago

This is measurably worse in every way if only by saying you've thrown out everyone's existing mail stacks. No, no one wants to do that.

teddyh 3mo ago

More people should be aware of their history. This text made the rounds in the late 1990s as spam was starting to become a problem. Everybody and their dog had their own “ultimate solution” to the spam problem, which they all thought was obviously the correct one, but all of them were more or less equally unworkable: <https://craphound.com/spamsolutions.txt https://craphound.com/spamsolutions.txt>

zahlman 3mo ago
To be clear, "this text" refers to the link at the end, not to TFA, correct?
- teddyh 3mo ago
  Yes. Sorry for being unclear.

jerf 3mo ago

I would advise reconsidering keeping the current format exactly. Something that would allow conventional email addresses to kept in a list that disambiguates them unambiguously would probably be a good idea. You don't want to embed the entire email in JSON. Too many parsers past, present, and future tend to want to decode the entire JSON document into memory before doing anything else, and so you'd be forcing entire email documents to be held in memory at scale, which causes you major problems. I'd recommend something more like either a JSON header that defines what parts are in the email, followed by a normal MIME document, which is perfectly normal in HTTP with other things that use the format as well, or having the top level continue to be a MIME document and specify that the first part must be a JSON document containing the headers. JSON replacing the headers is generally something that would be a good idea, though. That improves the ability of more language environments to be able to handle the email as a stream or in chunks with "normal" libraries and practices. MIME parsers in languages that tend to favor pulling everything into RAM as a string are still more likely to have been forced to face this issue already.

zahlman 3mo ago
> You don't want to embed the entire email in JSON. Too many parsers past, present, and future tend to want to decode the entire JSON document into memory before doing anything else, and so you'd be forcing entire email documents to be held in memory at scale Why? Even if your system loads emails into memory a whole email at a time, that doesn't imply that it will load large numbers of emails simultaneously. The kind of processing that can be done by stream-processing large numbers of emails in parallel seems rather limited to me. > I'd recommend something more like either a JSON header that defines what parts are in the email, followed by a normal MIME document, which is perfectly normal in HTTP with other things that use the format as well, or having the top level continue to be a MIME document and specify that the first part must be a JSON document containing the headers. JSON replacing the headers is generally something that would be a good idea, though. If we're specifically talking about being able to short-circuit after headers, then why not a JSON header followed by JSON representation of the body?
- jerf 2mo ago

mrsssnake 3mo ago

Here is another, not so new, idea: Username is your public key, password is your private key. So we get end to end encryption and account ownership out of the box. Something similar to how .onion addresses work. Needing easy to remember addresses? Build aliases on top of that. Needing server-side automation? Handle trusted server your private key. Also, almost everyone carry a 24/7 powered and Internet connected device in their pockets. The Internet - network that allows globally sending any data between devices. Maybe with full redesign third-party email servers should be made optional. I believe we should focus less on how to redesign whole service and build more universal layers instead. First, vsending any data to any machine. Second, optionally remotely accessing our data. Third, mail-like format of data.

jcgl 3mo ago
Tightly coupling identity to cryptosystems should be entirely dismissed for anything that is supposed to have broad adoption. First off, these systems always require indefinitely-lived secrets. To rotate keys (or the whole cryptosystem—think future possible quantum computers) is to change identity. Therefore, to change keys is to break the previous identity. Anything that requires users to think about long-term secrets is user hostile and leads to a fragile system. Second, the economics of pubkey-as-address are untenable. Can you imagine publishing .onion addresses on billboards and business cards, let alone sharing them verbally? Absolutely not. Unless there’s something I’m missing (please do say), these problems are intractable when you’re dealing with cryptosystem-based identity. In the end, identity and naming and fundamentally human concerns. If you try to kludge around this with purely technical solutions, all you’ll end up with is a system that doesn’t adequately reflect what identity means to people. Good systems support this (DNS, email); bad systems fight this (cryptocurrency, nostr).
- inigyou 3mo ago
  We need more and more varied DNS zones so there's competition between them. And not gTLDs which are just extensions of .us, but zones with genuinely independent administration.
  - 3mo ago

Mohiuddin7 3mo ago

[dead]

RajT88 3mo ago

A better protocol for email seems like it should be lower on the list compared to a better protocol for phone calls. And don't just say we'll build that on HTTP too!

dredmorbius 3mo ago
I'm thinking through the latter presently: <https://mastodon.social/@dredmorbius@toot.cat/116984051578438780 https://mastodon.social/@dredmorbius@toot.cat/11698405157843...>. And I see a few ideas that might be worth picking up from this proposal. Voice and text comms ... have much in common.

BeetleB 3mo ago

I don't want to replicate email. I want to fix it. Sending email should not be free. It should be really, really cheap to send an email to one person (like a fraction of a fraction of a cent), but get exponentially more expensive the more you send. People shouldn't be able to send emails to you without your prior approval (which you can revoke at an instant). The recipient should be able to charge a tack-on fee for having email sent to him. I should be able to charge annoying people a lot to send to me, and charge my friends almost nothing. People who send annoying stuff to me should pay more to get my attention. All of a sudden, forwarding that stupid article without thinking about the content (or even reading the article they're sending) will be second guessed. Save the money (and time), by sending only worthwhile stuff that you penned.

beaugunderson 3mo ago
> People shouldn't be able to send emails to you without your prior approval (which you can revoke at an instant). this sounds terrible... i've gotten so many useful random emails from strangers over the years.
- BeetleB 3mo ago
  Depends how it's designed. I've been doing something similar for almost a decade. If I get an email from a non-whitelisted person, they get an auto reply asking them to go through a simple hoop. Once they do that, the email lands in my inbox. Yes, many people go through that hoop! I can still see their emails if they don't. They site in a Quarantine folder. I used to look at it frequently to catch the occasional straggler, but I rarely do that now. I've set up an LLM to go through all my quarantined emails in the last N days, and send me an email on which of the quarantined emails probably should be viewed. I'm OK missing out on a (very rare) good email if it means I don't have to deal with crap mass mails. And let me tell you: Life is great when you don't deal with mass mails.
  - beaugunderson 3mo ago
    ah, quarantine makes sense i handle the overload a different way... i age everything out of my inbox one day at a time, each gets a label showing the remaining days; they start at 7 and count down. that way i only ever have 7 days of email to look at. it also makes it clear who the big offenders are... if 10% of the emails are some new marketing thing it's easy to see and unsubscribe. i do hate that there's still so much manual work involved though, i would love if marketers had to pay.

mlhpdx 3mo ago

HTTP? It would be a more interesting thought experiment with CoAP. And, is it really “modern” if it still uses a model (essentially) requiring stateful compute like JMAP?

TeeMassive 3mo ago

Asymmetric signature generation has been a solved problem for more than a quarter of a century. So are distributed hash tables. I can't believe email hasn't been replaced. My take on it is to follow the money. Microsoft, Google and Yahoo have a vested interest in being the only big identity providers along probably with some 3 letters agencies.

astrodust 3mo ago

The irony here that HTTP headers are descended directly from RFC822 email headers.

rbanffy 3mo ago

The fact nobody reinvented e-mail on top of a different set of standards is a good indication that the current stack is not as broken as some people would like to think. It reminds me of a previous life, at a previous time, when everybody reinvented the content management system based on slightly different approaches, because they thought existing CMSs were too big. It starts with serving pages, then you want multiple templates, then you want accessibility, then you want to authenticate with LDAP, then you want to use the LDAP groups as your groups, and then you need to tie groups to roles, because groups mean one thing to the org, and roles mean another just to the CMS, then you realize a relational database isn't that good a match, then you realize it would be convenient to attach some logic, and a document database is no longer a great idea, then you need multiple datastores for content, then you need new workflows on top, then... The devil is in the corner cases. They have been solved in different ways, by different parties, for decades, not always documented ("because it was just a simple thing, that once, and we fixed it"). Unless you've been there, you are doomed to make the same mistakes, and nobody was everywhere to avoid all mistakes. Why not dedicate an effort to migrate all the COBOL code currently running almost every banking transaction? That should be easy ;-)

HumblyTossed 3mo ago
>> The fact nobody reinvented e-mail on top of a different set of standards is a good indication that the current stack is not as broken as some people would like to think. email is one of those technologies that "just works" but so many people seem to think it needs to be "fixed". it's generally very reliable and so people should just accept that and be grateful. It could be worse - it could be enshittified like so much other technology.
- HDBaseT 3mo ago
  > it's generally very reliable and so people should just accept that and be grateful It's only really "very reliable" if you use Google or Microsoft for email, since they are the arbitrator of modern email.
  - 3mo ago

1saadcodes 3mo ago

I like the approach of building on existing standards instead of starting from scratch. That said, solving communication between users is a very different problem from replacing a system that has to work with literally everyone

inigyou 3mo ago

ActivityPub is literally SMTP over HTTP.

Keywordstat 3mo ago

I built KeywordStat, check it out. https://keywordstat.co/ https://keywordstat.co/

ojinai 2mo ago

[flagged]