@prologic@twtxt.net 👋 I can take a stab at it when I am done with the changes I am working on.
i am guessing you are using some form of webmention to notify the target of the DM? which loads it into a store for the user to read?
@prologic@twtxt.net for encryption. we can have browser/app generate ec25519 keypair. store the private on device and add pub to list of devices for the user on pod.
@prologic@twtxt.net sender generates an AES key encrypts message. gets the device list for user and encrypts key for each device. sends the encryptedkeys+cypertext.
@prologic@twtxt.net device gets the cypertext and uses it’s device key to decrypt one of the keys and then decrypts the cypertext.
@prologic@twtxt.net pod should probably track revocation of device keys and delete the encryptedkeys that are paired with revoked keys
@prologic@twtxt.net def would be a wider discussion on preventing the pod from adding its own key to a users device list. Or using device keys to authenticate instead of user/pass.
Can we not have clients sign their own public keys before listing them on their Pod’s account?
Yeah.. we probably could. when they setup an account they create a master key that signs any subsequent keys. or chain of signatures like keybase does.
@prologic@twtxt.net Ok.. so using NaCL boxes. yeah its just a combo of using secretbox with a generated key/nonce. and then using the pubkey box to encrypt the key/nonce for each device.
@prologic@twtxt.net I use https://key.sour.is/id/me@sour.is
I would need an out-of-band way to verify your public key’s fingerprint though 🤣
@xuu@txt.sour.is @prologic@twtxt.net This? Fingerprint: 161c614f08e4ed4d1c8e5410f8c457e6878574dbab7c9ac25d474de67db1bdad