Community Gateways

I have so many other things to write today, but I ought to at least cross this off the list. After all, how can I resist an opportunity to espouse a business model completely unrelated to my own? Inconceivable. At any rate, this should be fairly brief, as it’s fairly simple.

A community gateway is a node that gets its funding from a community pool, turning peer connectivity on and off based on the total content of its bitcoin wallet. It has interesting pros and cons, but ultimately, I believe it is more practical than other mesh funding systems.

Some impractical alternatives, and why they’re impractical.

The whole reason I’m writing this, is because I was getting tired of some folks in IRC espousing monetization designs that have serious drawbacks, or at least serious incompatibilities with the commonly-accepted goals of Project Meshnet.

Dense paid peering

This is a term I’ve made up for someone else’s idea, and hopefully it will be accepted as a fitting one. What I mean by this is as follows: a network in which the majority of nodes charge money for peering (a dense concentration of paid peers). The idea is that everyday joes on commonly-used routes will charge money for access.

DPP sounds great on paper, but in practice, it’s a pretty noxious sort of network. Any cost to peer is a barrier to entry, if for no other reason than it forces you to set up your monetary stuff (we’ll assume Bitcoin) before you can access the internet. If that wasn’t a chicken-and-egg problem, it would still be a highly discouraging step to joining the network, which is a pretty serious adoption chiller.

Also, the benefit to the node admins is pretty marginal. For all the inconvenience of the payment system, the fees will probably too low to be useful to the very people it’s supposed to recompense, because they all have to compete with “free.” This makes villains out of the altruists and beggars out of the middle nodes, nobody really wins except the people who can monopolize communication between specific areas.

Also, this would almost certainly bind us to all the complexities and headaches of microtransactions…

Microtransactions

Microtransactions do work better with Bitcoin, and are probably the only practical method for paying for mesh internet in a mobile-ISP model like DPP. That said, “best option” does not necessarily mean “good option,” and there are a lot of caveats to microtransactions. In fact, I’m going to tear a new one for my favorite microtransaction model.

The best model, IMHO, is small-prepay-with-prorated-refund. This means you pay some small amount - 10 cents, for example - that you can afford to write off if the peer is malicious. When you disconnect, the peer refunds you the unused portion of your money. When you need more money, you can transfer it, possibly in increasing increments. This is reasonably thrifty with transaction count, so you don’t lose as much to fees, with low risk of losing money to “con” peers (which successfully take your money, but never give you internet, or give you access to just a crippled subnet). Note that CJDNS prevents a lot of traditional abuses, so generally, any internet is clean internet.

The biggest problem is that you have to preload your computer with money. The complexity varies, depending on whether you use a single-wallet or multi-wallet scheme. Single-wallet is simple for the user to set up, but the implementation/incantation to transfer money from an offline machine requires a Bitcoin guru to understand; it’s miserable to try to whiteboard, let alone code. Multi-wallet is a lot simpler for everyone to understand, but requires more prep beforehand, since you are basically handing over the private key (and thus ownership) of small wallets, which means you have to create and populate these micro-wallets when you have internet, which is even more squirrel-storing-up-for-winter pain-in-the-ass than single-wallet. Multi-wallet is still the better option, as I see it, but again, this just a microcosm of the “best != good” nature of microtransactions.

Another inherent problem is fees. While SPWPR helps to minimize the number of transactions, the very inescapable nature of microtransactions is they maximize the fee-to-payment ratio of the transaction. This is actually a fair tradeoff - dust transactions crap up the blockchain and are more work for miners, because you ultimately transfer the same amount of money, but divide it into more transactions, and the miner work increases with transaction count (not the amount of money in the transactions). But fundamentally, it’s the most inefficient way you can move money from one bitcoin address to another, and you get financially penalized for it.

Finally, it encourages wait-till-the-last-minute payment by making the payment windows small, which makes connections less stable, which makes it more difficult than ever to do your money preloading (or really, do anything else online, for that matter) while you have internet. This can probably be worked around by turning knobs and implementing grace periods, but it’s still bandaids on an ugly mechanism.

The Troll Solution

Make sure every node is too exhorbitantly expensive for poor people, so we can starve them out and purify the gene pool.

This was not a serious suggestion, it’s just what happens when you try to have a serious discussion in #hyperboria on HypeIRC. Of course, it is an example of the opposite of our sometimes-implicit goals for the platform, and a case against prohibitive endpoints in general.

How does a Community Gateway work?

It has a public bitcoin address associated with it. Money is transferred from this address to the admin’s address on a regular, incremental basis. As long as there is money in the bitcoin account, the node keeps its CJDNS peer connections open. If the money runs out, those connections shut down - probably by simply shutting off CJDNS itself. The “draining” process should be as continuous and regular as possible, so that other machines can use wallet balance as a metric for determining when “the tank is running low.”

While it does not provide any special sort of packet layering, such as a VPN, the “gateway” in the name comes from the expectation that CGs will generally be used (and profitable) at network chokepoints, such as long-distance links, people with over-ISP peers (in the long-term future where these are less common), etc. They are gateways in terms of network graph structure.

Pros

  • CGs can be supported by anyone, anywhere. The cost is voluntarily shared among the people who want to keep the gateway open. Price competition is intensely fluid as a result.
  • The above point perfectly circumvents the seed/leech paradox (who is “providing” bandwidth to whom), because people on either/any side of a CG can pay to keep it open. So there’s no quarrelsome debate about who “upstream” is when upstream-ness is subjective or subject-to-change.
  • It is absolutely free to join a network. In fact, a whole neighborhood can be sustained by a few benefactors. No artificial barrier to entry here.
  • Fosters community spirit.

Cons

  • There is a tragedy-of-the-commons problem, in that when anyone can support a gateway, and no in in particular is obligated to do so, it’s a matter of game theory that determines who ends up paying for it to what extent. However, I do have a solution for this.
  • Seemingly has less benefit for middle-of-mesh nodes.

Solution to the Tragedy of the Commons

The blockchain is a public ledger, recording who has put money into a bitcoin wallet, and from what wallet. It is also trivial to prove ownership of a wallet. Therefor, it is a matter of public record to see who has put money into a community gateway.

I propose that nodes implement speed caps on peers until they provide evidence of donation. A receipt protocol would be fairly easy to standardize, including a hints mechanism indicating which CGs the upstream peer values (and how much). That way, you still get usable speeds for free, but your publicly-visible donation to community well-being can be rewarded with full speed access. Everyone, thusly, is encouraged to donate.

This is also where we get the benefit for middle-of-mesh nodes, although it takes a readjustment of your point-of-view. Middle-of-mesh nodes generally will only get enough money to partially subsidize their own upstream access costs anyways, whether in a CG or DPP system. Saving money on upstream costs is functionally equivalent to making money. A community speed-cap system spreads the financial load of keeping important nodes open, which saves middle-of-mesh nodes money, because they have to take on less of the cost. And as we’ve established, this is functionally equivalent to a realistic DPP scenario.

Another benefit is that this actually does still allow a more voluntary form of DPP for middle-of-mesh nodes, which can also run as CGs, despite not being on chokepoints. While these won’t be in a position to charge as much, and other peers may not ascribe value to such nodes’ CG addresses, you may still be able to earn a bit of money from being in a central part of a neighborhood.

The strength of this solution is that it enables a trade of bandwidth-for-money, without sacrificing the free or paid tier, and giving the transaction a more noble connotation. Combine it with some sort optional add-on that adapts personal hint-list based on network topology, and it seems like you would have most of the theoretical benefits of DPP, with fewer of its practical downsides.

Another interesting side-effect is that you can offer speed rewards for donating to any bitcoin address, not just CGs, so you can support charities or The Document Foundation or whatever you want, by rewarding such donations with higher QoS.

In closing

I think the Community Gateway model best reflects mesh networking realities, is favorable to the vast majority of participants, and is the most growth- and freedom-friendly model we can adopt. It is also, in a few senses, the most flexible, and manages to sound good for both short-term and long-term planning, due to that flexibility.