[0x457]

That's close to what I was thinking. I guess a message here could be just a bag of bytes, and then you can plug listener side into `tower` stack.

Can't exactly wrap my head around access control here. In this example, let's assume I'm using a proper policy and not `TrustEveryonePolicy`. What's stopping someone from using this route: route![(TCP, "localhost:3000"), (TCP, "localhost:4000"), "echoer"]; in this example?

I see that Worker has `is_authorized` method and even before that method executed `Mailbox` also uses, so I see how to avoid issue from above. However, middle node would forward any traffic without any questions unless https://docs.rs/ockam/latest/ockam/struct.Context.html#metho... is used? Then I'm curious if middle node will be able to use https://docs.rs/ockam/latest/ockam/access_control/struct.Ide... given that it doesn't know much about the channel?

I'm just working on something that could use this, but right now, we use wireguard + nftables + convoluted routing policies + TLS. I would go far to not use TLS and manage X.509 infrastructure and hopefully avoid double encryption.

[mattgreg]

would you like to schedule some time with us to dig into this further. This sounds really interesting and pretty close to things we've seen others do before.

To move this off of HN and to a channel that we look at more regularly, I'd like to suggest a couple alts: 1) GitHub Discussions: https://github.com/build-trust/ockam/discussions/categories/...

2) We can schedule a zoom call: https://www.ockam.io/contact/form