Hi all, our application is deployed as a private network of libp2p nodes exchanging data with each other.
We have a use case where - on certain circumstances - a node in a network needs to exchange messages with a node the other network. In practice the request node needs to open a stream to a node on another network. In our requirement, even if node A can open a stream to node B, node B may not be allowed to open a stream to node A.
It looks like nothing out of the libp2p box can help.
We’re looking into the go-libp2p-circuit as a starting point and think on how to extend it; but also considering to solve the problem at the application layer - basically spinning two “special hosts” and copying the traffic across.
As we’re quite new to libp2p we’re yet unsure on how best to tackle the problem and any pointer or direction is really appreciated.
If using Go, https://github.com/libp2p/go-libp2p-gorpc provides possibilities of adding authorization for services (stream would be open but node B may refuse to allow the request).
I’m not sure you can disallow streams without disallow connections (they are data multiplexed over a single connection). And disallowing connections would be akin to not being able to exchange any data with the other node (more like a traditionall firewall). I am not sure how libp2p circuit plays here, would be interesting to hear your ideas.
After having looked more into the relay code, a relay node (say R) opens outbound connections to two separate nodes (say A and B) and allows streams to be relayed across. But if A and B are part of different pnets, there’s no way for R to connect to A and B. R is built with one protector, so it’s either part of A’s pnet OR B’s pnet (or none of the two).
To implement this new behaviour, R should be constructed - somehow - with two protectors and configured to decide what protector to use to what network.
This is definitely new behaviour… I don’t know whether this could be seen an extension of the current relay spec or a totally new component.
And I still don’t know whether this should be solved “within” libp2p or at the application layer.
I guess once connectivity is established, the gorpc module can provide authorisation at the application level as you suggest.