Anurag Gupta | WebAssembly Based TypeScript Wrapper For Ockam Protocols In Rust

[Anurag5086]

Hey, I'm Anurag Gupta, a pre final year software engineering undergrad. I have been working on Rust and its web frameworks(Actix Web, TIde) for last 3 months and have really been impressed with the Rust ecosystem. I also have experience in Typescript, Javascript, MongoDB, React, Nodejs, C++ and have built projects to production.

I'm really interested in exploring the concept of web assembly. Web assembly could be the new way of building web applications as it allows the native code to run on web browsers which makes the web app blazing fast and compact. Looking forward to having a discussion and working under the Externship for Ockam. Thanks!

[Anurag5086]

@mrinalwadhwa @antoinevg I was going through the documentation and I really loved it. I had a doubt in this step , after creating the 2 workers with echoer and h1 as their addresses, we are sending the message through the [“h1”, “echoer”] route, so the message which is being displayed at the h1 worker is not the message which was sent initially which in this case is Hello Ockam! but it's printing out Any Message.

So, is it like the end receiver worker in the route defined will only receive the message or the workers all along the route will be able to read the message?

Thank you!

[mrinalwadhwa]

@Anurag5086 thank for going through the documentation, I'm glad you're enjoying it.

In simple routing the intermediate hops can read the message - the display of "Any Message" is simply because we don't try to convert the message in the Hop worker to a displayable string.

Later when you get to the secure channel step ... data received by worker along the route is encrypted and cannot be read by intermediate hops.

Great question!

[Anurag5086]

Got it, thanks! 👍

[Anurag5086]

About me

Github | LinkedIn | Dev.to | Twitter

• I’m a pre-final year software engineering undergrad from Delhi Technological University, Delhi.
• My expertise primarily revolves around JavaScript, Typescript, React, MERN, Web Development, NextJS and developed an avid interest in Rust & Blockchain development.
• I have been exploring and working with Rust for over a couple of months. I have built several projects and microservices in Rust using the web frameworks like Actix web and Tide. Comparing Rust with other low level languages like C++ which has a manual memory management and Java which has a garbage collector, Rust solves it all which makes it a king when it comes to memory safety.

Technologies which I currently work on are -

• Typescript/Javascript
• C++
• Rust
• Actix Web.rs/Tide.rs
• ReactJS
• NodeJS/ExpressJS
• NextJS
• MongoDB/MYSQL/Postgresql
• Docker/DigitalOcean

My Experience

Worked as Full Stack Developer Intern at Progarten using the stack NextJS, Typescript, MongoDB and developed code for production. Things i worked on -

• Developed an admin dashboard from scratch using Strapi CMS and integrated it to the main website using MERN Stack with NextJS and Typescript.
• Developed a site tour guide for the user dashboard using ReactJS and integrated a Chatbot using DialogFlow.
• Developed a landing page using NextJS(Typescript) for running ads on Google Adwords.

Worked as Software Developer Intern at Kootlabs. (Link to project)

• Built an open source Decentralized Identity Demo, myPass.ID using ReactJS, Typescript, Web Sockets(Socket.io) and SCSS.
• Developed the complete frontend interface using Typescript and ReactJS which interacts and sends data using web sockets to the mobile and vice versa.
• This demo is a step by step demonstration of how a decentralized identity product would work in the real production scenario.

Worked as a Backend Developer at Uptone.

• Built a backend express server using Typescript and used MongoDB as a database for a Music sharing social media platform.
• Created a REST API for the user posts, user comments on the posts, public and private profiles of the user.

Open Source Mentor at CodeTrophs for GSSOC 2021

• Mentored the participants for their contributions by helping them out by getting along with the codebase and held regular discussion on how we can improve our project.
• Reviewed over 25 Pull requests from various contributors.
• Tech Stack - NextJS, Javascript, SCSS.

My Open Source Contributions -

Contributed to FreeCodeCamp

Solved issue #43427
Link to PR - #43429

Contributed to Signoz

Solved Issues - #453 , #421
Link to PRs - #458 , #503

Contributed to Codetrophs

Opened and review issues and PR's - Visit issues

Contributed to CodeforCause

Solved Issues - #104, #79
Link to PRs - #105, #97

My Projects -

Codedigger - An Open Source Competitive Programming Platform (Github Repo | Hosted Link)

• An online open Source competitive programming website which has a curated set of questions from various websites like Codechef, Codeforces, Atcoder, UvA and Spoj. Introduces several features such as friends, mentors, ladders, problem list and upsolve.
• Built using ReactJS, Javascript, Bootstrap and integrated REST API’s, Docker, CircleCI.
• I’m an open source developer and maintainer at codedigger and currently we have around 12 Stars on our project. We are constantly improving and building this project.
• We have over 2500+ registered users.

MyDesk- A virtual organisational tool (Github Repo | Hosted Link)

• Web application where students can store all their work related to college and personal documents all at one place in an organised manner.
• Technology Stack: ReactJS, ExpressJS, MySQL, Cloudinary

Talkie - An audio tool to start recording your audio (Github Repo | Hosted Link)

• An audio recording tool made using React. Generates a blob link for the recorded audio.
• Tech Stack - ReactJS, Javascript

Started learning Rust and its ecosystem and have built a few small projects based on Rust.

Dino CRUD API using Tide (Rust), Postgresql (Github Repo)

• A basic Rust REST server built using Tide, a rust web framework and integrated the database using Sqlx (Postgresql).
• In this project I learned how we have to use traits, how to use macros like json! (from serde_json) or query_as or query macro, serialize and deserialize the struts to use them during data manipulation, etc.

Building a Rust web server using microservice architecture using Actix Web, Postgresql, NATS, Docker, Kubernates. (Github Repo)

[Anurag5086]

First of all, thank you for creating an amazing documentation. I'm really inspired by how a well documented project can make it easy for new developers to begin with.

Starting of with I tried out the Alice and Bob example -
So, the way I understood is that Ockam provides a secure way of communicating on the internet avoiding the unwanted, unsecure pathways which the request flows through on the free internet. So when data or information is being passed(handshake) between 2 machines over the internet the data flows through an unwanted and unsecure pathway to reach the destination machine. This path involves a lot of data centers, message queues etc.

So ockam makes the communication very easy by just communicating over an ockam cloud node through TCP protocols with cryptography for safe and secure authentication of the sending and the reaching machines.

So trying out the Alice and the Bob example -

• What we aim in this example is to create a remote connection between the 2 systems and make them communicate with each other using the cloud ockam node with a TCP address of 1.node.ockam.network:4000 hosted on ockam hub.
• Initially we are creating a Secure channel listener which in this case is Bob, looking at the code firstly various struts/attributes/constants have been imported into the bob.rs file and then a struct Echoer is created which has a simple description that it will print what ever message it received and then sends it back to its returning node.
• Then the main function creates a TCP network using the context which is present throughout the program. Moving on, we have used the Vault method to store the secret keys which are generated and will be used to verify the network protocol between the 2 computers. And then using the TCP constant and the TCP address of the cloud node the forwarder is being generated, followed by printing out the address of that forwarder in the cloud ockam server.
• And at the end we start the worker Ecoher with an address of ‘echoer’, this worker stays inside the node which is being created.
• Now at the end of Alice, the similar setup happens but Alice acts as the one which transmits messages, so now the forwarding address is entered at the Alice computer, and the route of the message flow between Alice and Bob will be route![(TCP, "1.node.ockam.network:4000"), forwarding_address], Alice -> Cloud Node -> Bob and back. This thing runs on a loop.

Building this example made it clear how ockam focuses on the key aspects like security, privacy, integrity between the computers which are communicating over the internet by providing its own gateway to bypass the traditional flow of message passage.

I had a question -

• While creating the secret keys, usually a public/private pair is generated. So in this scenario the private key is getting stored in the vault and the public key is being displayed as the forwarding address right?

Please correct me if i have understood something wrong or have missed out. Have tried out other examples as well, will be putting out my learning soon. Thanks!

[Anurag5086]

My understanding for the example - Build End-to-End Encrypted and Secure Messaging Channels

Building a Node -

• Ockam Node provides an asynchronous execution environment for the ockam workers. Nodes are responsible for directing the messages between the workers on the same node to a remote node. The asynchronous runtime is achieved using the Tokio, which is an asynchronous runtime for Rust.
• So the example begins with creating an Ockam Node. With the help of #[ockam::node] attribute we can inject or add all the boilerplate code for a node to the async main function below. This was just a basic step involving creation of a node.

Adding Workers to the Node -

• Workers run in a Node, have an address, have their own internal state, can receive and send messages on the same or different nodes.
• Creating Echoer worker Type -
  • In the example we are creating a stateless worker but if we have some state we can put those member variables into the public struct which is defined.
  • So now we add #[ockam::worker] attribute on the Worker trait implementation. Echoer worker is responsible for handling the message which is received and then sending that message back through the return route. So therefore a handle_message function is defined which takes in its own mutable reference, a mutable reference of the context and the message of type String and returns back Result. This function prints out the address and the message sent by the App Worker which we will be creating in the next step.
  • And finally it sends the message back through the same route.
• Creating Main App worker -
  • In the app worker we create a Node and start a worker with an address of echoer and type of Echoer we built in the previous step. Now the message is being sent using send() function which takes in the Worker address and the message to be sent.
  • Now we wait for the reply, this has been made asynchronous by using the await keyword as it could take a few seconds in some cases. Finally we receive the message and print it out and stop the node and cleanup.
  • Message Flow - app -> echoer -> app

Routing through a single hop -

• Creating Hop worker Type -
• This would be a simple worker which is created similar to the Echoer worker but the Hop worker has the onward_route and return_route, this could be thought of as a vector of addresses which the message will pass through and has passed through respectively. - Creating Main App worker -
• This is similar to the previous example but in this we just have added a new worker of type Hop with an address of h1 and have changed the route to ["h1", "echoer"] using the route! Macro.
• Message route - app -> hop1 -> echoer -> hop1 -> app.
• The message in the payload remains the same throughout the communication but the onward_route and the return_route keeps on changing at every step.

Routing through multiple hops -

• It's exactly the same as the example with a single hop, here we just define a few more hops and add them to the route - route!["h1", "h2", "h3", "echoer"]
• Message route - app -> h1 -> h2 -> h3 -> echoer -> h3 -> h2 -> h1 -> app.

Ockam Routing over TCP Protocols

• In previous few examples we have been working locally on a single node by creating multiple workers on the same node itself. So, in this example we will look into routing messages between 2 different nodes using TCP protocols.
• We create a Responder and initiator node.
• Responder node is initiated and the TCP listener is running on localhost:4000 to listen to the incoming connections from other nodes. It also has a worker with an address of echoer.
• Initiator node initiates the message and sends it through this route - route![(TCP, "localhost:4000"), "echoer"] , first it connects over the TCP protocol and then transmits the message to the worker with the echoer address.

Routing over two transport hops

• This example is just the extension of the above example and this just has multiple hops, which can be defined in the route as defined here - route![(TCP, "localhost:3000"), (TCP, "localhost:4000"), "echoer"].

Creating an encrypted secure channel

• We create a Responder Node, middle Node and Initiator Node.

Responder Node

• A worker with address echoer and type Echoer is created, followed by a TCP listener at localhost:4000 and then creating the Vault to store the secret keys for Bob for authentication over the network.
• A mutable entity is created which represents Bob. Now a secure channel listen is created for Bob using create_secure_channel_listener() method.

Middle Node

• The middle node acts as an intermediate node which is hosted at localhost:3000 in the example and does the work of routing the messages over the TCP network.

Initiator Node

• This node is responsible for initiating the message over the TCP network with a message payload and defined routes.
• A mutable entity is created which represents Alice, now creating a secure channel listen for Alice with the route - route![(TCP, "localhost:3000"), (TCP, "localhost:4000"), "bob_listener"] , and then the message is sent via the secure through which passes through the route - route![channel, "echoer"].

So this is how a secure encrypted channel can be created and different nodes can communicate with each other over a TCP protocol.