Sure; but distributed mesh networks feel like another area where Sybil Attacks [1] can rear their ugly heads. This is a fundamentally hard problem to solve in all distributed systems without a coordinating authority.
The blockchain approach basically bootstraps said authority, and comes with tons of additional baggage. It's the only one I'm aware of that has real countermeasures to Sybil attacks though (in a sense; 51% attacks can also look a lot like a Sybil attack with the right glasses on)
i agree about the blockchain, though now possibly there are multiple viable approaches under that rubric now that ethereum has abandoned pow
there are a lot of possible approaches to the problem, though
hashcash for announcing new destinations is one possible measure
reserving most of the bandwidth for established connections to which both parties are indicating their continuing enthusiastic consent is another, and one which the circuit-switched pstn does implicitly, which is why your phone calls wouldn't drop or skip when there was a commercial break in prime-time tv. reticulum seems to do this by reserving 97% of bandwidth for non-announcement traffic, though i might be misunderstanding
the agorics 'digital silk road' paper from 01995 (unrelated to the later darknet market) describes another approach: include a source route and postage on every packet, with each network provider deducting however much postage it feels like deducting, and keeping track of bilateral account balances with each peer network (postage sent minus postage received). if the postage runs out, your packet gets lost, and the sender can choose to try resending it over the same route with more postage or routing it over a less expensive network. periodic cash settlement between network service providers zeroes out any persistent imbalance in cash sent and received: http://www.cap-lore.com/Agorics/Library/dsr.html. i don't think this has ever been implemented, though current nsp peering agreements do resemble it to some degree. the original paper suggested using eft for the periodic settlements, but nowadays you could very reasonably do it with something like ether
you can supplement the established-connection-prioritizing mechanism with a granovetter-diagram introducer mechanism: if alice has an established connection to bob, and bob has an established connection to carol, bob can dedicate some of his bandwidth on those two connections to passing messages between alice and carol. he can do this either completely at the application layer, with no support from lower layers of the network, like an irc server or turn server, or potentially with support from the network layer to find a more efficient and reliable route. (reticulum seems to support this; bob can pass alice's destination to carol or vice versa, which the manual seems to say eliminates the need for the announce mechanism, though i don't yet understand how the protocol works.) this allows bob to prioritize such connection requests using information that isn't available at the network layer, such as whether alice and/or carol have passed a captcha and/or are paying him, who they were introduced to him by, who they've introduced him to in the past, and what valuable data they've sent him. if bob repeatedly introduces alice to people she doesn't like talking to, she might cut off contact with bob, or at least look on his future introductions with a jaundiced eye and not allocate them much bandwidth
The blockchain approach basically bootstraps said authority, and comes with tons of additional baggage. It's the only one I'm aware of that has real countermeasures to Sybil attacks though (in a sense; 51% attacks can also look a lot like a Sybil attack with the right glasses on)
1. https://en.wikipedia.org/wiki/Sybil_attack