41–50 of 165 posts
Earlier quoted context omitted.
I'm sorry to hear about your bad experience. I've hidden the counter for screen readers. Please try again when you're ready.
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.
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/ ) using HTTPS/TLS to improve transit encryption, or Web Key Directory…
No, no one wants to do that.
> 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-mes…
> 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?
> 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-mes…
> 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?
> 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-mes…
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.
> 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-mes…
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 previ…
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.
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?
Why do you find the panel experience so bad?
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/ ) using HTTPS/TLS to improve transit encryption, or Web Key Directory…