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'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.
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.
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.