Replies: 3 comments
-
Some quick thoughts:
|
Beta Was this translation helpful? Give feedback.
0 replies
-
Draft proposal https://github.com/ockam-network/proposals/pull/86 |
Beta Was this translation helpful? Give feedback.
0 replies
-
Architecture documentation #2216 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Secure channels implement a behaviour of forwarding messages from one end to another and have this messages encrypted while they are flowing between secure channel initiator and responder workers.
This is two behaviours (forwarding and encryption) and the forwarding behaviour may be implemented outside of secure channel context.
There could be forwarding workers which deliver messages from one end to another using routes and transports or some other means.
One example of such workers are stream workers, which deliver messages between two nodes using stream API and stream service on the Hub.
And in Rust API draft such workers are called "stream", which is not entirely correct because the stream abstraction is uni-directional and have a indexed access API.
What does this abstraction do instead is using two streams with API workers to provide a forwarding behaviour similar to the secure channels.
I feel like there is a need for some word to describe this pattern, and originally I was thinking of including it in the concept of session. But sessions end up describing a shared (coordinated) state between workers rather then the forwarding behaviour.
Since we already have a concept of Secure Channel, we can generalize the word "Channel" for the bi-directional forwarding behaviour and call bi-directional stream API "Stream Channel".
This would remove the confusion between a stream as a concept from stream processing and the way we use pairs of streams to connect nodes.
The Channel would be the external API, the channel is a worker (address), which is used to represent a path to a destination.
Channels are similar to the transports in the way that transports provide lower-level channels which implement network delivery. Transports also use custom address types, which are not necessary for the higher-level channels.
Higher-level channels may use transport channels.
In case of secure channel over stream channels it would look something like that:
Beta Was this translation helpful? Give feedback.
All reactions