Return email to its rightful place as the one true messaging protocol. It's this or use a dozen messaging apps for the rest of your life, there is no other realistic option.
Add the features that make people use other messaging protocols to email.
Description: Chat, mobile notifications, read receipts, and other features, should not be available to arbitrary addresses. User approves addresses who can use these features.
Implementation: Add-to-contacts UI in client.
Description: Dedicated chat UI. No subject line. Return to send.
Implementation: Add dedicated chat UI to client. Messages sent from chat UI have header
chat: true. Messages received with
chat: true are shown in chat UI. Only chat from contacts appear in chat UI. Chat from non-contacts appears in message request UI.
Degradation: Message desplayed in inbox UI.
Description: Some messages trigger mobile notification. User configurable.
Implementation: Mobile app has notification category for mail from contacts with header
Degradation: No mobile notification.
Read Receipts and Typing Indicators
Description: See read receipts and typing indicators on sent mail.
receipt-endpoint: <URL> header to outgoing mail. Display read receipts and typing indicators sent to own
receipt-endpoint. Only send read receipts and typing indicators to contacts.
Degredation: No read receipts or typing indicators.
Description: Initiate voice calls from within client.
Implementation: Query MX server for voice call endpoint. Display voice call button next to conversations where MX server supports voice calls.
Degredation: No voice call button displayed when not supported.
Same as voice calling.
Description: Email from arbitrary senders should go into a message request folder, instead of in the inbox, to prevent phishing attacks, and encourage users to whitelist contacts which enables richer features.
Implementation: Email from senders who are not contacts goes into message request folder. Message request folder is distinct from spam folder.
Degredation: Email appears in main inbox.
Description: Mail consisting of a small number of emoji is displayed in a larger font.
Implementation: Display mail consisting of a small number of emoji in a larger font.
Degredation: Emoji appear smol and sad.
Description: Users can send "stickers" which are scaled appropriately.
Implementation: Display mail consisting of a single image scaled to UI.
Degredation: Images appear at fixed size.
Improved Rich Text Support
Description: Allow rich formatting without breaking plain text readers or using arbitrary HTML.
Implementation: Messages can indicate that they are formatted as markdown. Format messages for graphical clients and display with added line-breaks for plain text readers.
Degredation: Messages appear as plain text markdown, which is highly readable.
Description: Messages between users are end-to-end encrypted to avoid being read by third parties.
Implementation: Query MX server for public key of receipient, encrypt mail for recipient with pubkey.
Degredation: Messages are not encrypted. This is strict improvement to not encrypting any email. Once email E2EE is widespread enough, refuse to send mail to recipients that don't support it.
Prevent Replies Leaking Information
Description: Including messages in replies bloats messages, can accidentally leak information, and has is not necessary due to threaded clients.
Implementation: Don't include original message in reply by default. User may use dedicated quote reply UI to include quotes of original message.
Faster Message Delivery
Description: Deliver email instantly without any delay.
Implementation: Define mapping of email symantics over HTTP/3 as email/2, providing persistant connections and an efficient binary encoding. Query MX server email/2 support and use it if available, using persistant connections and binary encoding for instant message delivery.
Degredation: Messages are delivered at normal speed.
Description: Messages can be configured to dissappear after some amount of time.
Implementation: Query if recipient MX server supports disappearing messages. If so, let sender set amount of time before messages disappear. Enforced by recipient, not sender, since sender enforcement is impossible.
Degredation: Option to turn on disappearing messages is not available when not supported by recipient.
Description: It should be possible to easily add and remove addresses from group chats.
Implementation: Email already supports group emails, but configuring adding and removing addresses from group chats is difficult. Query MX server for group chat support endpoint. Dedicated API for creating and updating group chats, referenced by ID. Group chat emails are associated with ID, instead of just being arbitrary lists of addresses, allowing any participant, if they have the permissions, to add and remove members from chat.
Degredation: Group chats are received as ordinary multi-address emails.