Problem description
I thought a lot recently about the Asynchronous Private Messaging problem, which is the same as your cell (=DHT) not being lively enough, particularly for small groups.
I mostly was thinking in terms of short-lived, mobile nodes (assuming that Holochain will one day be native for mobiles) with messaging (Kizuna, e.g.) or other apps where you’ll have smaller groups (digital pantry? 
).
If you use a Holo port, this probably won’t be a problem (since they normally have high uptimes - but they’re not really trusted themselves, so there is the thing about decrypting them only in the browser).
The only option (?!) in this case is to accept an untrusted agent with high uptime in your network. Untrusted, because you don’t trust him reading your data.
Solution 1:
Expand your cell(=DHT) with one or multiple servers, i.e. agents you don’t trust to read your data, but have a high uptime. This could include incentivized joining i.e. you pay them to be part of your cell. For this, you would need to encrypt all data/messages on the DHT using End-to-End Encryption (E2EE). This would effectively make a group inside the cell, where everyone in the cell has the encrypted data, but a subset - ‘the group (of friends)’ - also can decrypt the data.
Actually, to make larger cells with consequently higher livelihood, multiple groups could co-exist in one cell. If you don’t have the keys to a group, then you’re acting as a server to this group…
Solution 2:
You use 2 cells/DHTs. The first only consists of the group participants, so since this is a separate network, messages don’t even have to be encrypted. When it seems that the cell is not lively enough, e.g. the redundancy factor (as an absolute number of agents) cannot be reached, then the messages are encrypted and put into another cell (with much more - untrusted - agents or ‘servers’).
This has the benefit of reducing storage overhead for servers when everyone in the group is online. On the other hand, then has to be determined which message is already received by everyone, otherwise you would end up still putting everything on this second, encrypted cell. (I just realized this might become too complex, messy)
Furthermore, this might not be implementable with the Holochain core as it is right now?
Conclusion
In all cases (both + using Holo), some form of E2EE would be needed. As posted here on the forum, a Holochain dev is looking if x3dh is adaptable to a P2P environment.
I’m not a cryptography expert, but I’m really triggered about the problem, and it seems that there are already some algorithms using x3dh as their base. I found: OMEMO, (meg)olm and draft in progress: MLS.
If I understand correctly (no security expert!), there isn’t yet an E2EE that works in P2P, but these protocols work on a centralized and/or decentralized, federated environment.
The silver bullet would thus be an encryption scheme which allows asynchronous group communication with possible multiple devices(=agents) for each person, working in P2P.
(Is this all? See for example future comparison on OMEMO website)
Feedback
The core team and Kizuna probably have thought a lot more and harder on this…
This is only my attempt to summarize what I think I understand.
@Kizuna, is solution 1 how you’re seeing things?
@holochaindevs, I read somewhere that there is ‘work being done’ (if I recall) to reduce problems with small cells. Is this in essence not the only way too really do this? (adding more agents)
Discussions:
- Mailbox - #6 by tats_sato
- Private by Default
-
vanitasvitae’s blog is really helpful to understand OMEMO and/or (meg)olm if you’re not an expert
I take the liberty to ping a few people to see if my understanding is correct and if this is the way Holochain/Kizuna is developing… : @tats_sato @pauldaoust
.
, thank you all for bearing with me