Ideas to allow personal access control / bandwidth limit rules to work in a mesh?

[Xetera]

First off wow, I've spent a bunch of time recently searching for an open source overlay network that can allow a group of friends behind NAT to communicate with each other's locally hosted services and your project isn't exactly that but it's incredibly well-made and almost perfect for what I want. I just have a few more requirements for what I'm looking for like not blindly accepting requests from everyone connected to the server and bandwidth control.

I was originally going to fork your repo and work on whatever I want for myself, but I noticed you have something in your road map "preshared clients - controless p2p" that I thought might be similar to what I'm looking for but I wasn't totally sure. I'm curious if any of this feels compatible with your vision of connet on the off-chance I can contribute any of my changes upstream.

I think your intentions with this project was to allow the connet server owner to expose services on their device to 1 or more people, and not function in a mesh where a group of people connect to each other selectively. There might be extra work that needs to be done here to allow bidirectional connections or even specifying which user's service to connect to since that doesn't seem to be a thing. Either way, I totally understand if you're not interested in my ideas here since they might not be the direction you want to go.

---

My original goal was to work on something that makes it easier to do mutual backups on your friends computers but when I got started, I immediately ran into a roadblock with wireguard and the lack of NAT traversal. None of the popular tools out there like tailscale and what not solve this problem in a decentralized way without the explicit blessing of the network owner who controls everyone's access rules. Connet is almost a perfect base to build this on top of except for a few things which is certainly closer than anything else out there. Please let me know if I got any of these wrong.

Exposing services to specific sources.

It doesn't seem like there's a stable identifier that can be used to tell one source apart from another which from what I can tell would make this difficult to implement in its current form. Maybe the user's token could be one of those things but it doesn't seem like a great idea.

I'm thinking the user could explicitly choose to share their service with a specific person in a group this way. If you're not the intended source you don't get any ports forwarded.

[client.destinations.serviceX]
url = "tcp://192.168.1.100:8000"

[[client.destinations.serviceX.sources]]
some-id = "token123"

I see some potential problems with this of course. It would be much nicer if instead of tokens there was something similar to wireguard's public key that can be used as the token, but I don't feel like that fits in nicely with the existing architecture. I would just like to be able to share my identifier with someone and not have another person be able to gain access to the their services by copy pasting my identifier and impersonating me.

Bandwidth control

I think this would be a useful feature regardless of the access control changes. If you're exposing local services it's possible you're on a laptop using a hotspot so limiting bandwidth to not use up all your internet quota could be very helpful.

Maybe a config setup like this that allows optional upload/download bandwidth limiting that's also optionally adjustable per-source could be nice.

[client.destinations.serviceX]
url = "tcp://192.168.1.100:8000"
bandwidth.down = "50mbps"
bandwdith.up = "5mbps"

# optionally combined with the previous feature
[[client.destinations.serviceX.sources]]
some-id = "wendy"
bandwidth.up = "50mbps"

[[client.destinations.serviceX.sources]]
some-id = "joy"
bandwidth.up = "10mbps"

Sorry for the huge wall of text. Curious to know if any of these seem interesting or if you had something different in mind

[ingon]

Thanks for the kind words. A few thoughts:

Controless p2p

The controless p2p was meant for cases where you don't want to depend on a third party (the control/relay server) and one of the peers has a public (or easily routable) address. I'm still thinking about how I can approach this, but at the same time I'm trying to see if/how I can minimize control/relay role in the current architecture for them to become mostly optional.

Bandwidth control

That sounds useful regardless, so I'd be happy to have that integrated. Will add it to the backlog, feel free to experiment yourself.

Destination ACL

As for the rest, paraphrasing in connet terms, you want destinations to control which sources have access to them, without control server being involved. Based on your use-case description, in addition, these destinations are unique (probably, to identify different targets), so you also wouldn't want one destination to impersonate another one (even if they guess the destination name). This kind of feels like you want mutual TLS/encryption - in the current architecture if the destination exposed an encrypted endpoint for which only the desired source has the keys, only they could would be able to talk to the destination, even if technically any of the sources could connect to it.

Ideally, of course, connet will support this natively, and one of the ways to achieve this might be to exchange the peers TLS keys based on some additional condition. One option is to encode this as part of the protocol, but then you put even more trust into the control server behaving properly. Or the peers could be filtering the incoming keys and only exposing/using a subset of them (if we've embedded identifying info in the keys). Or, maybe we could exchange encrypted TLS keys for which only the peers have the key to decode. Many options, to consider here.

Anyhow, thanks for reporting this. Lemme know if I understand what your scenario is like.