> CJDNS
I need to research more into that. Great pointer, thanks!
> IPFS
Yup, definitely, it's on the radar. It's still not production ready though, I'm unsure whether it will/can (I mean this particular project/implementation, not the concept).
> payments
You've definitely thought this through, maybe developed already on e.g. blockchain?
Note that my initial idea, for a neutral human communication medium/protocol, dates back before bitcoin, blockchain, etc. My "system" was designed thus works without those. The inspiration was another 'bit' network: bittorrent.
Later on when I found out about bitcoin etc., I researched the tech. While I ignore the 'currency' aspect of blockchain for this project (because 'currency' is an application; and I'm merely concerned with the protocol beneath all applications), I did find interesting ways to integrate the blockchain paradigm itself (the idea of a database that can't be tempered with, and may be distributed).
My system remains independent of its database implementation though, it should work with simple txt files, or more typically some postgres.
The naive architecture is simpler than you might think, it relies on tried-and-true enterprise-inspired models and implementations. Simple things. Where we do the magic is precisely in the execution, to make it extremely efficient (eg target the lowest viable solution space; have a "concurrency-driven design" for scaling, modularity, distribution). And as of 2019, we have incredible computing resources in the hands of half the population, so 'efficient' is 'enough'.
So there's no payment at this level. It's a protocol, a language we agree to use, and one application may be human communication, but I may be wrong about that part. The protocol stands nonetheless. We are fundamentally not far from XMPP conceptually, although we integrate much deeper (XMPP could probably be a high-level API of a node in this system).
However there's this simple equality rule: "for every bit you ask the network to process n times, you too must process n bits for the network in return". Take some, give back some.
So nodes come a la "BYOR" (Bring Your Own Resources: CPU, RAM, storage, GPU, sensors, whatever), and each node is both server / client; like bittorrent or Tor you simply receive and serve continuously.
This puts the burden of scaling entirely on users individually (remember, it's decentralized: there's no central anything, no 'final' or 'higher' authority) and you'd expect the biggest traffic producers to also be those who make a business out of it (and I'm sure there would exist many applications on this system to let users charge/pay e.g. content or merch etc). Note that "sharing" should probably mean you are willing to 'seed' said shared content, thus fairly distributing load in viral cases.
Note that the network should guarantee anonymity of all accounts (each of your chosen 'persona' is derived but your core account is never exposed and can't be compromised by misuse, only theft in-real-life).
> mesh
It's a hard problem though, I'm aware of that. The MVP may definitely 'cheat' by using regular internet to bridge the gaps (it will be necessary anyway between cities). But one primary goal is that whenever possible (i.e. within range), two devices should never communicate but through an ad hoc LAN between them. Why go to Google's server when I just need to serve a file that's locally cached in the next room, or maybe just next house?
Baby steps...