Max Inden

As discussed in the open maintainers call today, @nazar-pc can you research whether you are behind an _endpoint indepedent_ or _dependent_ NAT?

For others to follow along, grant proposal: https://github.com/filecoin-project/devgrants/issues/1421

> @mxinden What do you think? Do you have any historical knowledge on this? No historical knowledge beyond what is posted above. I am fine with either direction. Preference for...

_@dirvine sorry for the delay. Thanks for starting this conversation._ > Much of the paper seems to make sense and I belive the go impl has made strides in this...

https://github.com/libp2p/rust-libp2p/pull/4756 implements solution (1), more specifically tail dropping in the `ConnectionHandler`. @divagant-martian [raised concerns](https://github.com/libp2p/rust-libp2p/pull/4756#issuecomment-1784927518) with this approach. After syncing with @divagant-martian, @jxs and @thomaseizinger, here is a rough summary. ###...

> * Publish messages > * Subscription > * Control messages > * Forward messages The goal here is to reduce the memory footprint. Subscribe and control messages are tiny...

I don't think a priority queue, e.g. https://github.com/rmcgibbo/async-priority-channel, is the simplest solution to the problem at hand, namely to prevent `send_queue` from becoming very large. Say that the priority queue...

> > Say that the priority queue is full. It has a limit of 10 messages. 5 of these messages are forward messages. Say that the local node wants to...

> Meanwhile, while trying to implement the channels solution, the smoke tests fail with timeout, this seems to be because as the `NetworkBehaviour` doesn't return `NotifyHandler` when polled and directly...

I would guess @MarcoPolo has opinions here given his related work on https://github.com/libp2p/go-libp2p/pull/1833.