Thanks a lot for your great feedback!
Is the salt supposed to be a secret too? Is it app specific? In the case that the user wants to use a second client to read his dm3 messages, do they need the salt too or will the new app just generate a new key with a new salt? In that case, we would need to list multiple public keys so that the user could receive messages in many devices.
The salt isn’t supposed to be a secret. It’s always stored unencrypted together with the encrypted payload (messages, contact list, …). The following snippet shows the typings of a storage object:
{
version: string;
salt: string; // unencrypted randomly generated string
payload: string; // encrypted user storage
}
If the app retrieves the storage JSON file, it will read the salt property and ask the user to sign the salt with his wallet. The signature will then be used to derive the key to decrypt the payload. This way, the wallet owner will always be able to decrypt a storage object. We did it this way because MetaMask deprecated eth_decrypt and eth_getEncryptionPublicKey. The good thing about not using eth_decrypt and eth_getEncryptionPublicKey is that we are not bound to MetaMask anymore.
So, if a user wants to load his messages on a second device/client, he just needs to load the storage file and sign the salt with his wallet.
It is also possible to export the encryption key. The export makes it possible to use dm3 on a device without access to the Ethereum private key. For example, if you used dm3 at first on your desktop computer and now you also want to use it on another device but you don’t want to put your ethereum private key there. Therefore you just need to scan a QR code representation of the encryption key with the new device.
Any service could decide to be the server of the user’s messages. Is there a standard way for one service to retrieve messages from the other? I would suggest that every DM3 compatible service should have an API that returns an (encrypted?) RSS feed with messages for/from any user. This way messages could be replicated among many services, if the user so desires
The user selects the delivery service he wants to use by putting it into his profile which can be accessed by querying the eth.dm3.profile ENS Text Record of the user. If I want to send a message to a specific user, the dm3 app will look up the URL of the delivery service this user is using and send the message there. The delivery service just buffers incoming messages until they are delivered. After the messages are delivered, the delivery service will delete the message (similar to pop3 for email). If the dm3 app instance retrieves the message, it will store it at the storage location the user selected (browser storage, local file, ipfs, google drive or dm3 storage service). This way, the user has complete control over the location of his data.
I agree it would make sense for the dm3 storage service to provide an API method to move the complete user storage of one user to another dm3 storage service instance or a completely other storage location. I created an issue for that https://github.com/corpus-ventures/dm3/issues/278
I see some very different applications that would require slightly different implementations: one to one private chats, group private chats, and social media posts (both public and within a given audience). Do you see the same protocol as serving all of these?
I think most of the use cases you mentioned should be possible to realize with just minor changes on the protocol side. For example, I implemented a public message feed demo version of dm3. In this case, the delivery service would store the feed and make it publicly available. So if your dm3 app instance would like to get my public feed, it would look up the eth.dm3.profile ENS text record of hai-ko.eth. There it would find the URL to my delivery service and my public signing key. Then the app would query the delivery service to get the feed and check the signatures of every message in the feed. The public messages would then be shown to you if the signatures are valid.