Make active reservations more visible to the host

[drHuangMHT]

Currently there is only one way to know which peers have made a reservation to the relay, which is by listening on events emitted by the behaviour. It's too much of a hassle so I wonder if we can provide a method on libp2p::relay::Behaviour to access active reservations.
This feature is small and nice-to-have. The main motivation is that I want to make peers that have made a reservation(listening on the relay) be able to advertise themselves through a protocol hooked up to the relay protocol.

[dariusc93]

That might be a nice to have, though may vary from use-case to use-case, however if im understanding your motivation correctly, you could possibly do this on your part by using the events related to a new listener (eg SwarmEvent::NewListenAddr while polling swarm or FromSwarm::NewListenAddr within your behaviour) to track successful reservations (you would be looking for addresses containing the p2p-circuit protocol) and from there you can do what you intend to do.

[drHuangMHT]

That was the plan. I just think it's simpler to implement at library level. Yes, it is a nice to have feature, and I can definitely live without it.

[thomaseizinger]

It's too much of a hassle

Can you expans on this? I am happy to add APIs if a certain usecase is unsupported at the moment.

If you can achieve your usecase by doing some more state tracking outside the Swarm, then I'd say that is the way to go. One of the main reasons for an event-based design is because it is not oppinionated on what you do with the data and thus serves more usecases whilst keeping maintenance low :)

[drHuangMHT]

Yes, I can make it work by listening on events. However it does take more than 5 lines of code on the library side. Just asking whether it's possible. Another day another reference counter......

[thomaseizinger]

Can you share some code on what you are currently doing and also what code you'd like to see in the library? But overall, the reason we emit events is so that users can build their own stuff on top :)

[drHuangMHT]

It only takes three lines of code to get active reservations:

pub fn reservations(&self)->Vec<PeerId>{
        self.reservations.keys().cloned().collect()
}

While for my application I need to handle event listening, pattern matching and tracking, which is a bit more complicated than above. I haven't written application-side code yet because I realized this issue when the idea of advertising peers occurred to me yesterday and I found that there is no direct way of getting the peer list. Honestly, my plan was working on the relay protocol to get peer advertising working on the relay level but obviously I would bite off more than I can chew. If I were to call relay_server.reservations(), I would set an interval to get the list.
Yes, I do see the benefits events bring about. Internal states shouldn't be easily available, and other things like API changes, decoupling, all that jazz, I get them. So I'm just exploring the possibility.

[thomaseizinger]

If I were to call relay_server.reservations(), I would set an interval to get the list.

If you integrate on an event-level, you get notified immediately without having to wait for the timer to fire again! :)

Yes, I do see the benefits events bring about. Internal states shouldn't be easily available, and other things like API changes, decoupling, all that jazz, I get them. So I'm just exploring the possibility.

We are always happy to discuss possible changes to make use-cases easier. In this instance, I think there are numerous benefits to using events:

• Less code to maintain for us
• You can directly optimise for your usecase
• Pushing instead of polling allows you to immediately react to state changes, making your application more responsive

Perhaps https://github.com/libp2p/rust-libp2p/blob/master/swarm/src/behaviour/external_addresses.rs can be of some inspiration, how to modularise such functionality.

I'll close this for now, let me know if you get stuck somewhere or when you learn more about your usecase that might have us reconsider this. Thanks!