Can we split this up into several RFCs that solve a single problem?

1. Overcoming NAT
2. Enabling my Box to work with my devices behind a network that is disconnected from the internet ?
3. Supporting several libp2p client languages (JS/Go) ?

@gitaaron
Oh sure, the reason i gather them, is the solution that tide them to gather in libp2p is Peer Routing.
but you are master of the divide and conquer so help me untie them.

I am not sure how peer routing can help with the offline use case? Would mdns be a better candidate for establishing connectivity with the Box in an event that the client can connect to Box, however, the subnet they are on is not connected to the Internet?
…
On Wed., Jun. 1, 2022, 9:13 a.m. Farhoud, @.> wrote: @gitaaron https://github.com/gitaaron Oh sure the reason gather them is there solution are tide to gather in libp2p Peer Routing. — Reply to this email directly, view it on GitHub <#113 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAFDZ2H2G55H54HWSXCDSTVM5OXXANCNFSM5XNMWO6A . You are receiving this because you were mentioned.Message ID: @.>

If you look at this. you can see that the mDNS is part of solution for peer routing in local networks.

If you look at this. you can see that the mDNS is part of solution for peer routing in local networks.

My bad I thought peer routing was limited to only helping with address resolution over DHT. Makes sense to have an abstraction that covers both.

But i think i can decouple components and implementations.