I've been idly wondering if we can do something to facilitate more P2P connections (and require rooms/pubs less) by doing all the right NAT traversal things.

That's about as far as I've thought about it.

Can you do NAT hole punching without some kind of rendezvous server?

@Matt Lorentz (phone) Maybe not, but if there's at least one open peer, it could suffice.

I'm learning that I need to read a lot more...maybe about how BitTorrent works...

Thanks for humoring me as I throw around words I only just learned and probably run into the ground topics that have already been explored ad nauseam.

1. DHT to map hash of SSB identity to network addresses. Hopefully this enables something of a wider broadcast discovery. Maybe some of us have public nodes but not registered domain names or static addresses. Maybe some of our phones are only occasionally publicly accessible when they're on certain networks. Requires a few well-known nodes as a starting point, but they could be lighter weight than even rooms. I have no idea the realistic bandwidth or performance of likely DHT candidates, but if it works for BitTorrent, I assume it can work.

2. Make lots of nodes support room-style tunneling. Already doing this in Tilde Friends. If you can connect to a random stranger, you can likely connect to some random stranger neighbors, too, who might be behind restrictive NAT/firewall setups and otherwise inaccessible.

3. Try to upgrade every tunnel to a direct connection using whatever NAT hole-punching works. Add some new RPCs as necessary. No loss if it fails, because you still have the tunnel.

My thought is that this could be bodged together using existing components, this doesn't adversely affect non-participating clients, and if it all works, you can just "see" more people.

1. Stick nicknames and hashtags in the DHT to be able to look up nodes other ways?

@Just Simmonds I can see the value in going that way, but I'm wary of the size and scope of integrating such things. Maybe I shouldn't be. But maybe the answer is to eventually support 'em all?

My plan / current whim is to stick this into Tilde Friends as an option and see what happens: https://github.com/jech/dht.

I keep learning that things are less magical than I would like. Here's a new plan:

• Add some options to Tilde Friends, both defaulting to off but easy to turn on:
  • Connect to internet strangers?
  • Encourage internet strangers to connect to me?
• Add a new MUX RPC call to do BitTorrent-style peer exchange. Nodes keep a list of connections with health/recency/privacy information and can pass them around. We respect node preferences to be announced.
• Run a few Tilde Friends nodes in a mode where they will only accept connections and participate in that peer exchange, no room or pub whatsoever.
• Put some DNS TXT(?) records up somewhere on a boring domain with connection strings for those nodes and anyone else who asks (could include existing open rooms?).

This is all in support of wanting to encourage new users to be able to find connections but not wanting to force or even strongly encourage anyone to use the existing tildefriends.net room. I think this benefits from what works for BitTorrent clients these days. This doesn't solve anonymity, but you don't have to use any of this and can still be a first-class participant.

So I did a very rough first pass of this. There are some new settings in Tilde Friends. One enables peer exchange with internet strangers, which by default hits seeds.tildefriends.net for a list of open SHS addresses, mostly a list of open rooms I'm aware of. I'm easily influenced if there are others that ought to be included/excluded!

One or two of them are Tilde Friends instances with all but peer exchange enabled. They make an attempt to remember who has connected recently and requested peer exchange and continue to advertise them for a bit. This part is far more shaky, but there are other moving parts I need to fix before this part because practical, first.

@Cory ~😎 I'm curious if these different approaches require users to be online at the same time for a user to first get boostrapped to the network when they first sign up?

Its for this reason that I still prefer pubs to rooms as a solution to the nat problem. Having to join the network at the same time as another person seems like a complicated first coordination, and is not an issue with pubs.

although maybe I'm missing something?

@notplants I don't think you're necessarily missing anything.

I think if you're looking for to connect directly to an exact person, this doesn't help much, but for a new person trying to establish contact with anyone at all, it offers some value.

And the more people who behave like pubs, replicating accounts they encounter along the way, the more chance you'll get updates from someone you're trying to keep up with, even if you're not online at the same time.

But for now I can stick some open rooms and pubs in the list? 🤷‍♂️ It's an experiment.

@Cory ~😎

thanks for the explanation!

all for experiments and supporting all the kinds of replication, I keep noodling on the question at the root of your thread too

and also was thinking about it because I just gave some room invites to a friend who was making an account again, and I was curious if it was going to work for them, or if they would have trouble getting started just from that

I talked to adz at DWeb camp and they said they are using libp2p for p2panda. I think there were a couple other projects using it who seemed happy with how it worked. It says it does NAT hole-punching on the tin. Maybe worth looking into (surely this has already been discussed somewhere?).