Store and Forward Vaults across Decentralized Relays for Asynchronous Sharing

[CMCDragonkai]

Specification

Asynchronous sharing means the ability to share a vault to a node that's not online at the same time you are. Right now our node connections means that both nodes must be online at the same time. To do this, an intermediate relay that should be online is used to forward the vault onwards.

However... the original idea was that a gestalt #715 should have multiple nodes anyway, usually the phone node would always be online and that's what we were banking on. However with the focus on PKE atm, and not on the phone, that would mean the need to be an async relay would be useful for UX.

This is the same problem that end to end messaging apps deal with like WhatsApp and Signal. Now dropping an encrypted package somewhere for someone else to pick up at a later date isn't a problem. The problem is perfect forward secrecy. You generally want to ensure that even if the root keys are leaked, this doesn't result in a past log of relayed messages being compromised. And in a similar way a bunch of relayed vaults would be sitting ducks.

This is resolved with the usage of ephemeral keys that's only used for a specific communication session. Signal has some additional protections and I discuss this here: https://chatgpt.com/share/e/68b4a1c5-4e09-492f-aca2-b22833828e06

In the case of #713 we have a similar problem of finding a relay node for when NAT-busting doesn't work.

Store and forward, or delay tolerant networking #89 was being discussed earlier, but never started. In general the design of this system would depend also on how #713 works and also how #715 works. It makes sense that one would rely on a particular gestalt node as store and forward relay first before attempting to use other gestalts/nodes. This is because in a decentralized system you don't really know which node will be online when the other target node gets back online. Furthermore using other people's nodes as relays introduces consumption issues, what incentivises others to play well? Well the same reason why they would work as a relay node in the case of #713. But #713 consumes network bandwidth whereas this would consume storage. Sharing the bandwidth and sharing storage are useful features, and one might do a sort of p2p seeding constraint, you only get to "relay" if you yourself activate relaying ability. But there should be some proof of time supplied for this. Starting to sound like a collective action problem for compute...

Centralized seed nodes can offer relaying functionality by default, but as with #713, we would want to share the effort across the network.

Additional context

• Network Layer (next gen) for Complete Connectivity - this represents a revolution in network connectivity! #713
• Gestalt Synchronisation for ACL Configuration, Notifications and Vault Automation #715

Tasks

1. ...
2. ...
3. ...

[linear]

ENG-404 Store and Forward Vaults across Decentralized Relays for Asynchronous Sharing

[CMCDragonkai]

Also this changes a "pull" to a "push-pull". Because the sharing node has to push the vault to an intermediate relay before it can be pulled.

This might also work as horcrux gossip protocol too.