/r/incentivizedmesh
In incentivized mesh networks participants work together to route data to it's destination and are paid by other participants to do so.
Mesh networks have the potential to provide cheaper and more robust internet both in developed and developing countries by having the devices that use the network form the network themselves. Yet they are not in widespread use anywhere in the world.
Mesh networking tends to be difficult to setup, nontrivial to maintain, and most importantly only maintainable through charity. The goal of incentivized mesh networks is to turn that reality on it's head, by making it profitable, secure, and easy to participate building a competitive network for the users by the users.
A series of GO scripts designed to allow the user to create a series of paid networking bridges. An independent and payment unaware mesh is then run on top. Currently prototyping, see /r/altheamesh
A series of modifications to Batman-V designed to create a secure payment aware mesh. Currently somewhere in between conceptualization and prototyping, see /r/hocnet
An attempt to create a multi function billing daemon. Essentially a universal interface for paid meshes that may work dramatically differently under the hood.
IRC: #incentivized-mesh on Freenode
Matrix: #incentivized-mesh:matrix.org
/r/incentivizedmesh
We've been having trouble finding routing metrics that are verifiable. Verifiable means that there is a way to correlate the metric as propagated by the routing protocol with the metric as measured across an end to end route. For instance, the Batman V protocol uses an algorithm called Minstrel to get throughput estimates. This may be hard to run end-to-end over a route because it is an algorithm that is designed for use from one radio to another.
I still think that it should be possible to have a verifiable packet success metric that can be used in Batman or a protocol like it. But this difficulty got me thinking about not using mesh protocols.
It should be possible to having routing provided by a service or services. I send them my metrics and some money, and they send me good routes. If I don't like their routes, I switch.
The service can then use a variety of protocols, best practice, and manual techniques to keep from having their routes corrupted by cheaters. If I don't like the job they're doing, I can get routes from someone else.
The payment layer would work the same as it does with a secure routing protocol, requiring no changes.
We're still probably going to continue on trying to secure mesh protocols, but this is a direction that could always be possible and maybe good for a quick MVP.
So /u/rusticscentedmale and I have made this subreddit as a neutral space to talk about what we're calling incentivized mesh protocols, or any mesh network where people are paid to participate.
You can look at the sidebar for our respective projects and some channels to collaborate in. Our hope is that by getting together and working together we can avoid duplicating work and help each other solve problems, even if its just with rubber duck protocol design.
To that end we announce the Scrooge project, which has the goal of providing a mesh agnostic way to handle payments and other incentive related protocol components.
There isn't entirely a clear vision on what that means yet, but this is born out of Rustic and I noticing that our plans for payment where more similar in their requirements and restrictions than they where different, with the real differences fairly easy to put behind a layer of abstraction, hopefully letting us save some work and maybe even keep a single familiar interface for users of both of our protocols in the future.