pull down to refresh

100 sats \ 8 replies \ @optimism 11h \ parent \ on: Stacker Saloon
no one but sender and receiver can view the thread [..] future versions will be encrypted

I think that encrypt later will cause you problems with:

  1. defending the "no one but sender and receiver", because it means no one but sender, receiver and people with db access. As long as you're based in the US and there is third party doctrine, this will be a honeypot.
  2. implementing the encryption because for that you need key management, which is the hardest part

Also note that I'd love to have a little setting to switch it off completely until that future encryption-enabled version, to reduce the temptation of misuse by people, including myself, that want to use DM but then inadvertently doxx themselves in the most awful ways thinkable without having any cryptographic backstop.

write
preview
100 sats \ 7 replies \ @k00b 6h

I agree. This is the reason I've given for why we don't have DMs yet and I was capitulating.

I'm probably overestimating how hard it'd be to build a e2ee PoC.

reply
100 sats \ 6 replies \ @optimism 6h
I'm probably overestimating how hard it'd be to build a e2ee PoC.

Assuming you're not going to build your own cryptography, it's easy to overestimate. Assuming you plan to roll your own, probably you're properly cautious.

reply
100 sats \ 5 replies \ @k00b 5h

MLS in a browser. How hard can it be? lol

I found someone giving it a shot already at least: https://github.com/LukaJCB/ts-mls

reply
100 sats \ 4 replies \ @optimism 4h

It's even listed on the "official" MLS implementations page, great process on the PR /s, and the author of that ts lib opened a pull request for it despite writing in the readme:

This library has not undergone a formal security audit. While care has been taken to implement the MLS protocol correctly and securely, it may contain undiscovered vulnerabilities. If you plan to use this library in a production or security-critical context, proceed with caution and consider conducting an independent security review.

Make of that what you will. If I personally were to integrate a standard and there would be no audited, non-solo developed libs, I'd probably write and have audited my own lib. So in either case we're kind of back to "you're right to fear it", sorry, lol.

However: that implementation still isn't the hardest problem. The hardest problem, even if you write a ts mls lib yourself, is still key management.

reply
100 sats \ 3 replies \ @k00b 3h

I'd hope we can reuse the encrypted "vault" that we use for syncing send wallet creds, but there's a lot more state in these protocols and having one key to retrieve it all may defeat their purpose.

reply
0 sats \ 2 replies \ @optimism 3h

Yeah I thought about that. I think that the distinction is that all the data in the vault can be reset and reconstructed but messages cannot.

reply
100 sats \ 1 reply \ @k00b 3h

It's perhaps naive but I was thinking we would hold the messaging keys in this vault as a backup of whatever we store on the device. Then there's at least some redundancy if the vault needs to be reset or the device gets wiped.

reply
100 sats \ 0 replies \ @k00b 2h

Maybe the reverse makes more sense. Wallet sync could be done by sending messages to other devices which only have on-device keys.

Anyway, I started out of my depth and went deeper. It should be a fun tab to keep open with Chat either way. Thanks for the motivation!

reply on another page