“* Clients have to store decrypted messages somewhere on their end as keys get useless soon”
Even when not sharing messages, solving this other disadvantage^ you pointed out with the answer above seems secure… rather than storing all those messages locally.
It just becomes a matter of good key management after that, which #nostr already needs to deal with anyway. If you have the key, then you can see.
Problem is we need ZKP based hardware acceleration to unlock this. ZKP-based hardware acceleration would also help cryptocurrencies.
2 birds with 1 stone… 🦅
Applying zero-knowledge proofs to LLMs so that 3rd parties hosting the LLM could prove to their customers which model they are running, while also preserving the privacy of the customer with end-to-end encryption. This could create a decentralized marketplace without an monopolistic oligarchy. Customers could pay to switch between LLMs without needing to self-host expensive LLMs or trust the 3rd parties hosting the currently selected LLM.
I like the ART (Asynchronous Ratcheting Tree) of MLS. It indeed can handle larger scale group chats better than Signal and the like. I've been hunting for a suitable option to decentralize Discord.
There might be imperfect ways to solve the two disadvantages.
Clients have to store decrypted messages when keys become useless as new ones are created. This creates a risk of data loss since the data is stored locally, not decentralized across relays. You can't put the decrypted data on a relay because then the relay could read the messages.
One solution could be taking all your decrypted messages and encrypting them with a new key, one that's not part of the ART. This key would be unique to the user. Then, the user could encrypt all these decrypted messages with that new key and store the encrypted data archive on relays. That way, even if the user loses their device, the encrypted messages would still be on relays, provided they've backed up that single key.
To tackle the other disadvantage, we can piggyback off the solution to the last disadvantage. New users joining the group chat could ask the people who invited them to the group chat for a copy of their encrypted archive of decrypted previous messages. The inviters could delete messages they don't want to share, but the user could request a copy from multiple group chat participants to mitigate this risk. If all older members do this “sharing” for newer members, then the newish members should still be able to share the oldest messages with the latest joining members. nostr:note1qyqzzmz5etpzkwlgsarrkrm0wdrq0ury5lerkay8rswduthpt0pqy9r68d
We’ll be ready!🔮
Trust-minimization is the foundational philosophical pillar among all other principles… if trust is required, everything becomes fragile.
🐝
Relays running our software will also run a Git server. These two programs will talk to each other. Once our pieces our released, we can recruit anyone who wants to help with mapping each git action to our UI and storage system. Until then, our team will be coding! Any grants are of course welcomed and appreciated. 💜
"There are decades where nothing happens; and there are weeks where decades happen."
Once the code to these 3 pieces are complete, we will release all of it. I want the first bit of code we release to be functional, even if it is an imperfect alpha build. The first desktop client users can test & feel will work like Dropbox, for generalized off-chain file storage on relays.
Plugging the Git server into these 3 pieces🧩 will be a tedious challenge that the communities of #nostr can hopefully help us with. We were going to do this part ourselves, but devs are encouraging us to open-source sooner — so we will.