Private messages

[hackergrrl]

This is a work-in-progress!

This PR adds private messages, that enable two individual users (feeds) to communicate with each other such that other participants in the cabal will sync their messages, but not be able to read them. The messages are encrypted using private-box, which uses chloride.

The cross-stack implementation is tracked by cabal-club/commons#8

• Core API for publishing messages to a recipient
• Kappa View for indexing sent and received private messages
• Core API for reading private message conversations (via ^ kappa view)
• Core API for listing PM convos
• Tests

[khubo]

@noffle I could pick this up if you can guide a bit. Only api for fetching pm's by users is remaining?

[Gronis]

How would this work if I have multiple devices (with different private keys). Will only a specific device have access to the private message feed? I guess this is the case and it is not ideal.

[cblgh]

@Gronis yes you are correct, that's basically the limitation

depending on how we do it, we could support private messages among multiple identities which mitigates this somewhat. the limitation of this approach remains though

[Gronis]

Yea. Most p2p systems with a private key as authenticator have this problem. I have yet to see a good solution.

Maybe the user identity and the device key should be separated somehow, and then, different device keys can be added or removed to the user identity by signing from a device which already is associated with the same user identity, while also providing a secret. It would be a p2p 2FA system kind of.

Anyways, I'm kind of off topic here. Good discussion anyways.

[okdistribute]

Delta chat accomplishes this by transferring private keys across devices with an Autocrypt Setup message

[hackergrrl]

Hey y'all. I reviewed this code and here are the next steps I see:

• Finish writing the kappa view
  • Decide how we want to store indexed PMs. We could store them in plaintext (faster to fetch), or only store the msgIds and decrypt them on fetch (slower, ensures that the plaintext only exists in memory -- but does this matter?). (The current code that writes to leveldb in this view is old copypasta.)
  • Write kappa view API for fetching private messages. I think an API that mimicks the Messages kappa view API would be best, so that cabal-client can do similar logic. (The current code under api: is just old copypasta.)
  • Emit events as new PMs come in. (You index your own msgs too though, so we'd need to decide if we want to emit for our own messages (does the Message view do this?))
• Write end-to-end tests that show you can PM someone, and then use the kappa view's API to read that conversation history out.

After the cabal-core implementation is done, we can figure out the API that will be exposed on cabal-client and implement it there, before threading it up into clients. I really like the idea of having an API that mirrors the existing messages API as much as possible, presenting PM convos as much like channels as makes sense.

[okdistribute]

Awesome @noffle ! Very exciting!

Re:

Decide how we want to store indexed PMs. We could store them in plaintext (faster to fetch), or only store the msgIds and decrypt them on fetch (slower, ensures that the plaintext only exists in memory -- but does this matter?).

I think that on-disk encryption can be useful for some communities, but Cabal isn't billing itself a 'security-first' app to high-risk users. Since it's still very much a beta project I think that storing them as plaintext on the device is sufficient if it's easier to implement (also the better performance is a plus of course!)

[hackergrrl]

@okdistribute: I think that on-disk encryption can be useful for some communities, but Cabal isn't billing itself a 'security-first' app to high-risk users. Since it's still very much a beta project I think that storing them as plaintext on the device is sufficient if it's easier to implement (also the better performance is a plus of course!)

I agree!

[hackergrrl]

Tests are green! I'll merge soon if there's no issues.

Do either of you have spoons to review @cblgh @substack?

[cblgh]

@noffle :0 :0 :0 :0

AWESOME!!!!! i'll try to do a review pass rn! gonna get like a pot of chamomille lol

[cblgh]

🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉

🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉

i have some suggestions adding comments and stuff, github should make it possible to batch the ones you think are good additions & you can discard the rest. also left my lil thought trail cause hey why not

NICE JOB KIRA!!! 🖤 💜

[cblgh]

WOOOOOOOOOOOOOOOO 🎉 🎉 🎉