32
Agoral
3262343f8f41cb35bc642f7d378c707be52989ed5934f952ba4810ab366c5d59

What if briar like procotols become the only option to communicate?:)

Replying to Avatar Colby Serpa

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

There are many protocols that allow for secure community chats...we dont have to go far for a firt solution...you can for example utilize private nostr relays..

When it comes to decentralized way how to verify that the chat/database is in sync with other nodes (your example of some1 deleting msgs as you stated in your example) its tougher

You have to hash the current consensual state of the database into an immutable decentralized database (hello BTC) and client-validate the state of that database to the hash created during the last "consensual tick"

Again there are multiple ways to solve this problem but we think that so far the best solution is provided by RGB a 2nd layer of BTC...every community is a smart contract stored ofchain...evry invited participating node is a co-contract bearer reaponsible for creating consensus on about the current state and client-validating other participating nodes

Anyway the protocolar solution to you mentioned problem is somethin we are inherently working on with our agora project that i told you about before

Earlier today i went trought the github page...censors work fast :D

Love it! Colaboration is crucial and is oftenly disincetivized across many fields (academia, coding, governance, etc.). Humanity lacks a communication standard that would incentivize colaboration within and across communities in the whole infosphere (be it physical or digital realm)

Thats why we are working on a protocol which we among ourselves like to label as "coop tool" so i dig your approach❤️

Can you elaborate why exactly?