ockam icon indicating copy to clipboard operation
ockam copied to clipboard

File Transfer over end-to-end encrypted secure channels

Open jdspdx opened this issue 4 years ago • 4 comments

There is a tool called Magic Wormhole. It's a great tool to transfer files between machines, via a rendezvous server.

A similar tool could be built easily with the building blocks in Ockam and would make for cool simple demo.

The End-to-End Encryption with Rust guide has all the code need to setup secure channels, we just need to modify it to read a file, break it into chunks and move it over the end-to-end encrypted channel.


If you would like someone to help / mentor / pair program with you as you work on your first Ockam issue, please leave a comment on this discussion.

jdspdx avatar Jul 28 '21 20:07 jdspdx

I started working on this one.

Based on the alice_and_bob example, the receiver opens a secure channel with a forwarder and the sender uses the forwarder remote address to send the file in chunks.

This initial step works fine and I have some questions to make the example a little better:

  • How to cleanly exit a Node from a Worker ? ctx.stop().await? in the receiver Worker seems to sometimes exit badly
  • Would it make sense to re-export the tokio used by ockam alongside with all the tokio features not used by ockam feature gated by some ockam features? This could ensure users will only have a single tokio dependency in their bin.

Sending all chunks as fast as possible and exiting the sender seems to not complete the transfer correctly. That could be because of the size of the Forwarder queue or the different upload/download speeds or the disconnection or anything else but it shows a sync between sender and receiver must be done.

Does ockam provides some sort of transactional messaging or is it left to the application to implement it in its protocol above ockam ?

I'm adding some state machinery to the sender and receiver to make the transfer more reliable

dvermd avatar Nov 18 '21 05:11 dvermd

@dvermd awesome, thank you for working on this!

There is lot work happening right now to make message delivery reliable.

  1. See the design documents in PR https://github.com/ockam-network/ockam/pull/2216
  2. Implementation in Elixir https://github.com/ockam-network/ockam/tree/develop/implementations/elixir/ockam/ockam/lib/ockam/messaging
  3. The beginning on that implementation in Rust https://github.com/ockam-network/ockam/pull/2197

Adding @thomcc, @spacekookie & @hairyhum so they can add more thoughts on your questions above and help as you work on file transfer.

Excited about seeing where you take this.

mrinalwadhwa avatar Nov 18 '21 05:11 mrinalwadhwa

These threads have more information on @hairyhum's work with messaging delivery guarantees and building blocks https://github.com/ockam-network/ockam/discussions?discussions_q=author%3Ahairyhum+

I think reliable File Transfer would be a great test case for these upcoming features. In the meantime, my suggestion would be to do the bare minimum to make a transfer work.

mrinalwadhwa avatar Nov 18 '21 05:11 mrinalwadhwa

Would it make sense to re-export the tokio used by ockam alongside with all the tokio features not used by ockam feature gated by some ockam features? This could ensure users will only have a single tokio dependency in their bin.

This will be simplified in a week or two, some of my current work (building on #2229) is around making ockam usable with different async runtimes, in which case there will be a way to access the configured async runtime (by default, tokio for std, ockam_executor for no_std).

In the meantime, it's probably okay to have two tokio dependencies.

thomcc avatar Nov 18 '21 19:11 thomcc