Oh yeah, mesh nets are another great thought. We definitely need our own pipes. CJDNS is beautiful (I love that addressing scheme), but lacks incentives for people/corporations to build infrastructure for non-ideological reasons. The OpenLibreNet whitepaper had the incentives theoretically correct, but didn't go anywhere. I honestly haven't kept up on this space, but I still think about it a lot.
My biggest question is how to handle payments. Bitcoin can't realistically handle the micropayments for this purpose -- I'm not waiting for a block to hash before my website loads, nor do I want to pay miner fees for every request. The best proposal I'm aware of is that nodes keep track of balances to neighboring nodes, and when you want to establish a new connection with an unknown node you need to send them an up-front payment for X amount of data in advance. (The price of data wouldn't really be per byte of course, it's bytes multiplied by the arbitrary node-selected edge-costs all the way to the actual source and back through the cheapest/fastest path as selected by the end user.) Then when you're approaching the limit you pay more in advance, aggregating the micropayments. This means the inital connection still has to wait for a block to be hashed, and it's annoying from the perspective of a user trying to find valid peers once it's profitable enough to launch malicious fake nodes that eat up-front payments and refuse to forward packets. The initial connection time issue might be mitigated by allowing a Zahavian signal worth of coins to be sent to a burn pile, like an address that is just all zeroes, since a user who was willing to burn a pile of coins covering X+Y data Z hours ago probably isn't trying to rip you off for X data now even if they haven't successfully made a payment to your specific node yet. I'd like to believe that something like IOTA could probabalistically work well enough for micropayments that we don't have to worry about that, but I'm not convinced. Ideally a connection could be established quickly enough that vehicles passing along highways/oceans could route traffic as they go, breaking apart and reforming as necessary.
IPFS is worth googling too, if you haven't seen it already.
I'll send you an email before the end of the month!
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?
My biggest question is how to handle payments. Bitcoin can't realistically handle the micropayments for this purpose -- I'm not waiting for a block to hash before my website loads, nor do I want to pay miner fees for every request. The best proposal I'm aware of is that nodes keep track of balances to neighboring nodes, and when you want to establish a new connection with an unknown node you need to send them an up-front payment for X amount of data in advance. (The price of data wouldn't really be per byte of course, it's bytes multiplied by the arbitrary node-selected edge-costs all the way to the actual source and back through the cheapest/fastest path as selected by the end user.) Then when you're approaching the limit you pay more in advance, aggregating the micropayments. This means the inital connection still has to wait for a block to be hashed, and it's annoying from the perspective of a user trying to find valid peers once it's profitable enough to launch malicious fake nodes that eat up-front payments and refuse to forward packets. The initial connection time issue might be mitigated by allowing a Zahavian signal worth of coins to be sent to a burn pile, like an address that is just all zeroes, since a user who was willing to burn a pile of coins covering X+Y data Z hours ago probably isn't trying to rip you off for X data now even if they haven't successfully made a payment to your specific node yet. I'd like to believe that something like IOTA could probabalistically work well enough for micropayments that we don't have to worry about that, but I'm not convinced. Ideally a connection could be established quickly enough that vehicles passing along highways/oceans could route traffic as they go, breaking apart and reforming as necessary.
IPFS is worth googling too, if you haven't seen it already.
I'll send you an email before the end of the month!