Introductory Videos

[mrinalwadhwa]

Hi Everyone,

We started creating short introductory videos to introduce some concepts and how to use the various Ockam implementations.

I started with Elixir and added videos that introduce Workers, Transports and Channels.
https://www.youtube.com/playlist?list=PLRt7oUP96htaXntHYO0kW6O6HVZ0nf-i9

Would love to get some feedback, from everyone here, on the format, content and ways to improve.
Let us know. 🙏

[hollyfeld]

• I personally like the focus on shorter, concise videos versus a single video with multiple topics.
• The content seems adequate for introductory usage.
• Consider including some basic assumptions in the video descriptions for expected audience knowledge.
• Consider investing in a higher quality microphone and keeping consistent levels across videos.
  Disclaimer: I can be a bit of an audio snob ;)

[mrinalwadhwa]

Consider investing in a higher quality microphone and keeping consistent levels across videos.

I'm an recording novice 🤓 . Will work on a better audio setup.

Consider including some basic assumptions in the video descriptions for expected audience knowledge.

That is a great idea and easy to add, will try to add some shortly.

[jjscheel]

@mrinalwadhwa, for a first pass on videos, I gotta say you're doing a great job. I found the videos to be quite informative and a helpful introduction to some key concepts. Here are my comments on ways to make your videos even better.

FWIW, audio quality and levels are ALWAYS a problem. One tip is to use a tool like Audacity to try and adjust levels consistently once you've recorded. This can get tricky because it often means recording audio separately and re-merging. You might also investigate your video editing tooling to see if it allows for audio level adjustment: most do.

As for presentation format, I would only make one suggestion: consider using software that allows you to record yourself speaking and place that in the upper right corner. This just personalizes the video and makes it feel more "welcoming" in my experience. One tool you could consider using is OBS Studio. It's VERY flexible (perhaps a bit too much, to the point of being a bit difficult to learn) and can accomplish this using the concept called a "scene" (IIRC) where you can define your layout of precisely where you want the desktop and where the local camera goes.

Final suggestion, consider providing an overview video up front of the basic concepts. Most of them were in the channel video, but it would be helpful to understand the pieces of the flows and the goal (pictures are good) before you drop into the remaining videos and do the demos. If you were to do pull some of this content into an introductory video, it would have the side effect of reducing content in your third video. A general rule of thumb is to try and keep things to 5 minutes which I know from experience can be hard.

But, seriously, well done, especially for a first attempt. You're a natural!!!

[mrinalwadhwa]

@jjscheel thank you! that is very helpful feedback. I attempted using OBS once but got scared by the number of options 😄 I think its time to give it another go.

[jjscheel]

Heh, understand completely! Here's an example I did a couple years ago just to give you a feel. DrJava Debugger Breakpoint & Step. If you get stuck, let me know and I'll do my best to help.

[lessless]

Great stuff @mrinalwadhwa ,

In transports video I noticed that initiator's worker address is not included in the message and the responder doesn't have all the necessary credentials to send a reply back. I guess it was a consciously made design decision. Can you please give a bit of a context/rationale around it?

The second question might deserve a separate thread, but still, here it is - what are the options/approaches to let workers auto-discover each other? Say in a mesh-style network.

[mrinalwadhwa]

To your first question, as you may have already discovered, it's possible to set the initiating worker's address in the return_route field of a message.

To your second question, I think there will be several discovery mechanisms ...

1. The simplest one is a configuration parameter that is delivered (through some other means) to the initiator of the communication.

   • We are thinking of an enrollment protocol that can deliver such config securely https://github.com/ockam-network/proposals/tree/ml/enrollment-key-agreement/design/0006-enrollment
   • one not so obvious aspect is that a while the worker addresses in the example videos were random looking hex strings.. they don't have to be ... they could instead be human readable, easy to remember names/slugs.

2. We also have a Registry component planned for the system that will aid in discovery of workers that provides a service.

I think there will be other mechanisms that will emerge over our basic building blocks.

[gabhijit]

The videos are quite good. So I have a related question, For onward_route is it required to know the complete route to the destination (not simply the worker node Address) and if so how can that be achieved? It's fairly straight forward in the said examples because we know the addresses and can copy paste, but not sure how is it possible especially when multiple transports are involved.

[mrinalwadhwa]

@gabhijit great question!

1. In recent versions .... address, instead of being generated, can be provided to workers when they are created and they can be readable utf8 strings. This allows us to have persistent named destinations which eliminates the need for discovery in many scenarios.

2. We plan to have route discovery as a feature, using Ockam Registry as on possible mechanism ... but we think it should be layer on top to keep the concerns of discovery and routing separate ... any hop along the path of message could discover and tweak onward_route and return_route.

[gabhijit]

That means only the payload needs to be opaque to the intermediate nodes, other parts can be visible (in fact can even be altered!) Got it. Thanks.

[mrinalwadhwa]

Yes, exactly! An interesting nuance there is that a routing message could itself be an end-to-end encrypted payload of another routing message. In which case it cannot be altered and its integrity and confidentiality is guaranteed by the Secure Channel protocol. This allows some very flexible tunneling throw secure channels ... since the secure channel protocol is pretty light weight it gives us control over which parts of a data flow can alter routes and which parts can't.

[mattgreg]

Here are a couple more videos:

Specifically , we have several from our monthly community calls:

https://www.youtube.com/channel/UCvIHPuSfG4-vpsNFHZZaI8Q/playlists