pull down to refresh
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:
- 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.
- 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.
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.
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.
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
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.
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.
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.
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.
I might add: consider making the UI for DMs unthreaded. Under a threaded UI, long chains of replies are hard to read because of the max depth. This makes sense in a free-for-all discussion, but not so much for a 2-person text chain.
I'm fairly opinionated on that point. I think they should be threaded. I've been stewing on my detest of bolt-on DM systems for years.
If our threads aren't good enough, they should be made better - improving both DMs and threads alike. That assumes the deficit isn't fundamental to DMs being ordered as trees though. But, the average DM UI are lists of messages and lists are trees with only a trunk/branch so we can probably just improve how we display trees in certain situations and get the best of both worlds.
Yeah, makes sense to keep them threaded under the hood. I think it's more of a display hack for detecting what kind of message tree you're in (maybe some node count / max path thing).
My main point is that for a long chain of direct replies, some of the UI features of threading, like indented blocks and max depth, may be UX-reducing
Yep, we just already need that display hack for comment threads too.
I made a GH proposal long time ago: add hidden comments, revealed only with a payment.
You and Car have the same problem: you've been on SN so long and given me so many ideas that I don't have enough time to implement them all!
Hahaha no man I don't want to overwhelm you with work. I am even retain myself of not adding more issues on GH with "feature request" because I know that is not so easy to do all of them at once.
Do it on your own pace, I am just reminding you.
how i'm imagining our MVP of DMs will work