>0 noxzed @ 2021/06/21 13:05
A few month ago in tilde.chat/#gemini I was part in an interesting conversation about tranfering the concepts and goals of gemini to email. Despite the fact that email is a great decentralized standard in the online communication, it has a few historical flaws that are mostly impossible to patch. For example the lack of encryption per default. "Email" is basicaly a push protocol and not a fetch one like gemini. The goal would be to design a protocol that can be used to push fully encrypted data (or messages) from one user (or system) to another. If you already know a project or idea in that direction, feel free to link it below. For a push orientated protocol the receiver of the message should be online most of the time and adressable, therefore the client-server-architecture should be used. Even thou it could be the case that a server is not always online (eg. if its solar powered). A basic path of a message could be the following: [Client A]->[Outbox A]->[Server A]->[Server B]->[Inbox B]->[Client B] There are different challenges to tackle and most of them are just rethinking existing protocols: * Encryption and the Public Key Infrastructure * Envelope- and Message-Format * Mailbox-Format * Address / Identifier * S2S-Protocol * C2S-Protocol ## Encryption and the Public Key Infrastructure I'm not an expert on encryption and only know the basics of asymmetric encryption. For this very reason I don't know how to design such a system that is capable of fetching and validating the public key(s) of a specific user, to be a able to send him an encrypted message. There a a lot of pitfalls I don't know. ## Envelope- and Message-Format The envelope itself contains 3 parts: * Receiver address (eg. bob@foo.bar) * the message (encrypted) * the signature of the sender server of the above data The server can not see the content of the message or who is the sender address. The message can only be decrypted by the client and contains header and a body. The body can contain multiple segments like a message or attachments. Besides normal attachments that contains the file directly, it should be possible to reference/link to files that are to big to attach. Next to the link of the file there should be a decryption key and an expiration date provided, that way the files can be downloaded to a later time. (This could be used as a tracking pixel, but I'm not sure how to work around the filesize of a message with big attachments). ## Mailbox-Format Right now MAILDIR or MBOX let have the server full control over the messages and can see a lot of the content/metadata of the mails. This should not be possible. Due to the full encryption, the server can not spam check the mails or filter them by any criteria. This needs to be done by the clients. The user mailbox could have 3 directories: * inbox: all messages that were received by the server for this user (the user removes the message from the inbox after moving it into the encrypted data directory) * outbox: messages that the server should send to the receiver (the server deletes the message after it was send) * data: all files that are shared by the users clients (messages, encryption keys, etc) but fully encrypted ## Address / Identifier The address must contain at least two parts: the user identifier and the server identifier. eg: * alice@example.net (normal address) * alice+whatever@example.net (disposable address for alice) * groupconversation/alice@example.net (address the user alice in a group conversation or mailinglist) ## S2S-Protocol This would possible be the hardest part of all, because a server needs to be sure to receive messages only from trusted sources to prevent spam. The sender server connects to the receiver server and identifies itself and the receiver needs to validates this identity. Maybe over TXT records in the DNS or the servers have their own key-pair for signing and encrypting. ## C2S-Protocol The protocol provides access to the mailbox of the user. Perhaps SSH/SFTP could be enough to handle multiple clients from the same user? Messages itself could be written offline and sync to the servers outbox possibly days later, there should not occure errors on syncing the mailbox between server and the clients. Those a just a few thoughts on this topic. If you have a different approach or other ideas I'm pleased to hear them. Most of the ideas above are probably naive, but I think they could head into the right direction. You can answer directly in bbj or just link to your gemlog, if you want to post it there too. If there is a better platform (or mailinglist) for this thought experiment, please let me know. ~noxzed