Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File Transfer over end-to-end encrypted secure channels #1624

Closed
jdspdx opened this issue Jul 28, 2021 · 4 comments
Closed

File Transfer over end-to-end encrypted secure channels #1624

jdspdx opened this issue Jul 28, 2021 · 4 comments

Comments

@jdspdx
Copy link
Contributor

jdspdx commented Jul 28, 2021

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.

@dvermd
Copy link
Contributor

dvermd commented Nov 18, 2021

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

@mrinalwadhwa
Copy link
Member

@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 docs: messaging architecture #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 Implement Rust pipes #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
Copy link
Member

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.

@thomcc
Copy link
Contributor

thomcc commented Nov 18, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants