3 ms·
If they solved only discovery, handshake and hole-punching problems and made relay optional, it would be more useful. Also, for relay, if they provided store-an
by vinay_ys 4y ago
If they solved only discovery, handshake and hole-punching problems and made relay optional, it would be more useful. Also, for relay, if they provided store-and-forward and also scatter/gather topologies, it would be more useful.
- mattgreg 4y agogreat feedback!
- mwadhwa 4y agoKey/Route Discovery, Credential Issuance/Presentation, Secure Channel Handshakes and Message Routing that is decoupled from transport protocols have been our main focus. We chose to build the more reliable e2ee strategy first - Relays. UDP hole puncturing is in development right now. However there is extensive research that proves it in only successful in making connections in 60 to 80% of real world networks. This is why Signal does relays for example. Relays provide a highly reliable strategy. So we knew we'll want to support both and give devs and option to choose what is right for their application. Or failover from one to the other. In addition, relays also allow store and forward and integration to other enterprise systems like Kafka. This is how we're able to to move end-to-end encrypted data through Kafka https://github.com/build-trust/ockam/tree/develop/documentation/use-cases/end-to-end-encryption-through-kafka#end-to-end-encryption-through-kafka https://github.com/build-trust/ockam/tree/develop/documentat... Store and forward as a first class feature is in development. Scatter/Gather is a much harder problem since it involves group key agreement and challenges that come with doing that safely. This is in our long term roadmap, but we've not done any development for this yet.