I had this idea a long time ago of how to connect and route between mesh networks potentially scaling through the entire globe, but I'm thinking here only about physical links and a new internet:
quoting naddr1qq…smcd
a way to do an open and permissionless mesh network
I don't have much experience with that so maybe this is all a stupid nonsense, but I think routing in mesh networks (by which I mean all the software that exists out there for creating smallish mesh networks and the real-world projects that use them and effectively have a community of people that connect to each other in some geographical area or a virtual network that uses the underlying internet) is never scalable. It basically always requires all the nodes to keep a full view of the network in order to route packages -- and often there is no incentive for them to do that either. And then the thing is easily spammable but either that problem doesn't happen because the mesh never gets big enough or it has a central committee that decides who can join.
The biggest example is, of course, the big ICANN-controlled IP network, that gets all the negatives of being centrally controlled while weirdly getting also all the negatives of being a kinda-decentralized peer-to-peer ad-hoc network between indepent ISPs.
A good solution that makes kinda-decentralized (at least open and permissionless) routing possible and replaces node addresses with pubkeys could get make it possible for us to get rid of ICANN. Once that is done, ad-hoc peering would become more seamless and ISPs wouldn't have to be so big and clunky, they could slowly split, and non-comercial entities could join the party too by basically just plugging a cable or pointing an antenna to the correct place.
What is it?
One very dumb solution that came to my mind that has a chance of working is one in which each node as a keypair and to be reachable by others they announce their address -- for example, using some kind of DNS (on a [spacechain]?) or by directly communicating their address through some other means -- as their public key plus some "routing hints".
The routing hints are just pubkeys of other nodes known to be routers. Known to whom? Well, this would require some schelling points to naturally appear and the network would be ordered around them, but you are never forced to use them, you have to include as many routing hints as required to ensure that all the people you want to connect to you will eventually be able to, but nothing is ever 100% guaranteed.
Such network could probably work with a pure onion routing scheme with all its privacy benefits in some cases; degrading to a trampoline onion routing scheme otherwise, which means it will just be slightly less private the more trampolines you have to use. And every node has to keep track of just a set of routes from them to a bunch of known routers (or trampolines, which in my mind are mostly the same nodes, but are slightly different roles).
Example
Suppose A is trying to connect to B.
A is a home computer in the city of Évora, Portugal.
B is a home computer in the city of Udine, Italy.
There is a route (we, the narrator, know) between them that goes like this:
A--Ev--Li--Al--Ro--Sm--Ve--Ud--B, in which Ev means the node of an ISP in Évora which directly serves A, Li means a big node in Lisboa, Al a node in Algiers, Ro a node in Rome, Sm a node in San Marino, Ve a node in Venice and Ud a gateway node in the mesh of Udine to which B is connected.
There could be many other routes, but we'll ignore them for now.
B could have published his address as
<pubkey-B>?hint=<pubkey-Ud>,<pubkey-Ve>,<pubkey-Sm>,<pubkey-Ro>, which would mean A would only have to know a route from Ev up to Ro.If Ro is known to be a big router, A could easily have a route cached there, and could discover other routes by asking around every now and then too. It wouldn't take a lot of space to have routes cached to some thousands of different known big nodes like that. Then A can just wrap an onion with all the coordinates and the message inside and hand it to Ev and it would reach B. Inside the message she would also include the full route for a message to be sent back.
However, even if A doesn't have a route to Ro, it could still hope that Li would have, then she could make a special "trampoline" onion that goes Ev--Li and then when Li receives it it sees a request to forward the next packet to Ro, so Li has the freedom to choose a route from itself to Ro (as long as it knows Ro, of course) and from there A's message continues.
The same trampolining can exist on B's side, if B doesn't have a route from Ud to Ro, but knows Ro is likely to have one up to Ud -- or if B feels it's not worth including so many hints when most big nodes will have routes to Ud, for example, it can publish his address as
<pubkey-B>?hint=<pubkey-Ud>*<pubkey-Ro>meaning that one should find a route up to Ro and from there ask Ro to trampoline it up to Ud.Or, if B doesn't expect Ud to be very well-known, but Sm yes, then it could do
<pubkey-B>?hint=<pubkey-Ud>,<pubkey-Sm>*<pubkey-Ro>. Again, this is just one hint, in practice it would have to have a lot (maybe 10, 20?) other hints, in a tree structure that this querystring syntax isn't very suited for encoding:Ud Tr Pu Za Li Sm * Ro Ba Mi La Ge * Mo Tu(Remember, we're using city name abbreviations here, but each of these would be a specific node, with a specific public key, supposed for the example to be in such a city, but nothing prevents them from being in different cities or that multiple nodes exist in the same city.)
Summary
Basically packets go from node to node, in a sequence established by the sender -- with optional trampolines in between -- until they get to the target. Target responds in the same route. Nodes can be anyone. Focal points form around big nodes, but they can be replaced easily, the receivers just have to stop using them in their hints, so the network is flexible and open.
I have no idea of how bad this idea is, because I couldn't find anyone to criticize it or any other idea to compare it to and I have zero experience with any of this.
As far as I know all the mesh networks in the world are sadly much less ambitious than I want: they're all happy to just be a local thing. And in some cases they clearly state that their routing algorithms don't scale at all (they're either based on a centralized supernode, or nodes flooding the network with packets, or on everybody keeping a routing table of the entire network locally).
Projects like Meshtastic are just a stupid psyop. They get people to be excited about a completely useless thing, thinking they are contributing to creating a new decentralized internet, and that their stupid toy is actually a step towards that, but in fact it can never be more than that toy.
What I wanted to see was an actual meshnet project that employed some routing algorithm capable of easily adapting to new nodes joining freely, but also adapting to a new mesh network being connected by some new node, and then some other mesh connects to that, and so on, until you're able to route a message to someone a thousand miles away.
I think my method above works, and it is not magic because it has this important tradeoff: you can't route only with keys, i.e. your address can't be just your key like all these other projects do, you also need route hints in the address. It's like using an nprofile instead of an npub.
My method needs a lot of flushing, though. All the details are unspecified. And it would probably not work with any existing base network software, as it wouldn't deal with IP addresses at all (addresses would be much bigger than even IPv6 can support). It also needs a name, then we would have to adapt TCP and UDP to work on top of it (the name is important so we can call it TCP/<name> thing). I also didn't think about the incentives for routing at all.