Apple app developer news Android app developer news

Mobile mesh networking apps via new SDK from RightMesh

How mobile mesh networks work and how they can benefit developers in their future applications.

SDK 17,001 VIEWS
10/18/2017 11:02:56 AM
Mobile mesh networking apps via new SDK from RightMesh
Posted Wednesday, October 18, 2017 by Richard Harris, Executive Editor

Mobile mesh networking apps via new SDK from RightMesh
A big hurdle for software developers is how to reach the estimated 4 billion people, who currently lack Internet access. Without an Internet connection, huge swaths of potential users are unable to discover, download, and use their applications. The majority of these unconnected people live in developing countries, but approximately 96% of the global population live in range of a 2G mobile signal. 

Developers who build mesh-powered applications have the potential to connect with 4 billion offline users and provide life changing applications for these communities previously disenfranchised from the mobile device resources the majority of us take for granted. 

RightMesh is currently accepting applications from application developers for its public beta mesh networking protocol SDK which allows developers to start retrofitting existing applications and building new applications directly on the RightMesh Developer Portal. The more developers building mesh applications, the more nodes, the denser the network, and the more scalable the platform will be.

We spoke with Jason Ernst, RightMesh Chief Networking Scientist, to gain a bit more insight into the platform and mesh networks generally.

ADM: What is a mobile mesh app and what are the advantages of building on app on a mobile mesh network?

Ernst: A mobile mesh app is an app that communicates with other devices in a slightly different manner than we are accustomed to seeing for inter-device communication. Most of our apps now transmit data from the phone, to the cell tower or Wi-Fi hotspot, to your ISP, to some servers, and then back down a similar path in reverse to your friend who may be right beside you. A mobile mesh app can send data directly, in some cases (only a single hop), if the person is next to you. If the recipient is in the next room, or across campus it may travel across several phones depending on how far apart you are from the recipient, but it ultimately tries to take the most efficient path. Sometimes that will still be through the Internet, sometimes it will be several hops across phones.

There are several advantages to building an app on a mobile mesh network. First, developers do not need to know how to connect phones with Bluetooth, Wi-Fi or Wi-Fi direct. Anyone who has worked with these APIs on Android knows that it can be painful at times. In addition to making the development easier, mobile mesh platforms also solve some of the hard problems for you, including routing across multiple paths and reliable communication despite connections that may frequently drop as people move around.

Additionally, you don't need virality of your app immediately to get the benefit of a dense deployment. As more developers adopt mesh networking, there will be more and more nodes available. Our solution, RightMesh allows devices to communicate through other phones between the sender and receiver's device, even if those other phones don't have the same app installed. As long as they have some app using RightMesh they can participate in the routing.

Lastly, we're working on ways to reward users who share their data, provide forwarding capabilities, storage space on their phones, processing power, or even mobility (if they physically move to help deliver data). Typically this has been a big blocker to mobile mesh adoption. We think these features will cause end users of your apps to want to keep your app on their phones so that they can earn money for providing mesh service.

ADM: RightMesh is accepting applications for their mesh SDK. What is the goal in providing the public beta mesh networking protocol to selected developers?

Ernst: At the moment the early access to the SDK is to help us receive feedback from the community about the process of working with our developers kit. Until now, we've been focused on building internally with our teams in Vancouver and Bangladesh, and so this is our opportunity to gain insight from fresh eyes. We're also interested in some larger deployments so we can find out where and how the process of building new apps and retrofitting existing apps to the RightMesh platform will be strained. We've been building some tools that will allow us to measure bottlenecks in the network that help us improve our protocols.

ADM: How do you build a mesh app? Is there sample code?

Ernst: The first step is to sign up on our developers portal at Once you verify your account you will have access to documentation about how to get started, some reference materials that explain step-by-step what all the pieces of an app are, and our javadoc API. We have also begun to release some public git code samples: These include a "Hello Mesh" app that shows how other peers are discovered and how to send and receive data. We also have an app called "Ripple" which shows how traffic is routed in our mesh. Compared to some other mesh libraries, we choose to construct paths between devices rather than sending the same information to all devices. This should result in a more scalable network as more and more devices come online.

ADM: Connecting Bluetooth and Wi-Fi is really easy. Can't I just build this myself?

Ernst: To most users of Wi-Fi and Bluetooth it can be quite easy sometimes; however, to get phones to connect without user intervention is quite difficult. For instance, consider when you pair your phone with a rental car the first time. Usually it doesn't work because the car already has too many phones saved. Once you put your phone into discover mode, you can usually pair. Imagine this on a wide scale in which we try to connect as many phones as possible, and users don't need to enter pins or Wi-Fi passwords. On top of this, the single-hop connection is the easiest part. The tricky bit comes when you try to link together multiple hotspots, or link a bluetooth network with Wi-Fi networks and repeat this pattern. Other libraries that attempt this typically have no mechanism for discovering peers and routes from one side of the network to the other so they can generally only scale 20 to 30 devices on one mesh. We've tried to design our mesh to support many hops with many devices, and are still working to to determine the limits of the technology.

ADM: How does it work? Can I access the Internet through other people's data plans?

Ernst: Currently it is not possible to access what we call the "general purpose Internet" with our mesh. So you can't just open your browser and go to a search engine through other people's phones. However, if you have one mesh which exists in Bangladesh and another in Vancouver, and at least one person in each mesh has an Internet connection it is possible to link the meshes together through the Internet. This can be done with data plans (although it's up to the user to share it or not). It can also be done through existing Wi-Fi networks at homes, offices, and coffee shops. We should be able to extend the effective range of all of these networks.

In the longer term, we have already been planning about how to make general purpose traffic also work on our mesh, so it is just a matter of time before this happens. Of course using a non-mesh app on the mesh won't get the benefits of the intelligent communication to your friend beside you, so it's better to use a mesh version of your favourite apps instead.

ADM: What's the difference between broadcasting, single hop, and multi-hop?

Ernst: First let's start with your home network where you probably have a Wi-Fi router somewhere. All of the devices that connect to the Internet at your home are one hop away from the Internet. Data goes from your phone to the router, which is generally connected directly to the Internet. If I connect my smartwatch to my phone, because maybe it only has bluetooth, and then send data to the Internet, that's two hops. If data travels from the watch, to the phone, to the router, and then the Internet, that this is multi-hop. The mesh we are building is multi-hop, but sometimes only two hops are needed.

Now imagine you have other devices in your home network like your TV, laptop, and your friend's phone. Suppose you wanted to send a message to your friend's phone. If you send a broadcast message, all of the other devices in the network would also receive the message, including the friend's phone, the TV, and the laptop. Even if your friend didn't have the appropriate app to view the message, the message would still be delivered. This is the strategy many other meshes take because it guarantees that if we send the data to everything, and the next device does the same, it will eventually reach the intended person. While this is a very simple structure to implement compared to finding a proper route and minimizing the number of other devices that receive the message along the way, this is how most mobile mesh libraries work today.

ADM: How is RightMesh different from other mesh SDKs?

Ernst: RightMesh has distinguished itself from other mesh network platforms in a number of ways. First our target market is the developing world. These are the places where affordable connectivity is still a real problem. Most people have low-cost Android phones but cannot afford to use the Internet like people in North America, Europe, and Australia might be accustomed to. In some cases, when they can afford it, the infrastructure itself is at capacity. We understand the power of using the resources that people already have in their possession (ie. mobile devices) to connect billions of presently unconnected people. The opportunity to make a difference in the world by increasing the number of people with access to mobile device resources led to our decision to focus first on supporting Android 4.x to 6.x (with some limited support for newer Android like 7.x and 8.x).

Our strategy with connectivity is to try to always make connections without user intervention. We know that people won't use mesh apps if it is difficult to get the phones to connect. Currently in our developer kit, we allow the developer to set the connectivity manually for testing, but we have a version of the library that can autonomously form connectivity using Wi-Fi and Bluetooth, and are adding W-Fi direct to it.

Another major distinction from other SDKs is that RightMesh has no dependency on the Internet anywhere in our library. The meshID of the device is generated locally based on an Ethereum account that is created on first launch of a mesh app. There is no required registration with a server for users, so meshes can form completely offline and only use the Internet if they wish.

Finally, we are about to launch a tokenized system for incentivizing the mesh. There are very few meshes that support this, and even fewer that support it on a mobile phone-powered mesh. Tokenization is much easier with hardware, but we've outlined our plans for achieving this with mobile phones in our white paper and technical white paper.
Jason Ernst talks about RightMesh

Audio commentary from
Jason Ernst, Chief Networking
Scientist, RightMesh

ADM: Doesn't forwarding packets for others use more energy and kill my battery faster?

Ernst: Forwarding packets for others does use more energy compared to using single-hop Wi-Fi, but if you compare using Wi-Fi and Bluetooth to using your cellular network, there is likely some sweet spot in terms of number of hops where you can actually use less energy. 4G LTE uses 23x more energy than Wi-Fi, and 4G uses 10x more. Bluetooth likely uses even less. Of course, operating as a hotspot likely consumes more than operating as a client, but we are investigating this further with real measurements about what to expect in terms of battery life in a variety of scenarios. Ultimately, we think that incentivizing packet forwarding could make people more willing to have a device operating in a role where they are providing infrastructure to the mesh.

ADM: Are mobile mesh apps secure? If my data is going through other people's phones, what's stopping them from intercepting my data?

Ernst: Mobile apps can be as secure as most other apps, and RightMesh gives appropriate tools to developers to make their apps secure. We support end-to-end encryption using the Open Whisper / Signal library, but have modified it so that it doesn't require the centralized server. We allow key exchanges between peers, and have a way to notify the developer if this key exchange occurred a single hop away or farther, in which case it could have been susceptible to a man-in-the-middle attack if some devices were compromised. In the future we plan to spread the key across multiple paths so that malicious users would have to compromise multiple devices on multiple paths making interception much more unlikely. Wherever possible, we have a policy of using encryption (on our websites for example), and are always investigating ways to build more security into the platform. Also, we are actively hiring in this area if people would like to apply, check out

ADM: What is the future vision for RightMesh? Will it replace the Internet one day?

Ernst: In the short term, RightMesh will not replace the Internet, as we presently require Internet and some infrastructure to support the tokenization side; however, when phones become more powerful and can easily run full Ethereum nodes without using too much memory and killing the battery too quickly, this may change. Furthermore, we rely on the existing infrastructure to do things like get through NATs and firewalls so that separate meshes can communicate and find each other. Eventually all of this can potentially move directly on the phones.

I think, in the long run, we will see something akin to a parallel network to the Internet, one that is more efficient. It doesn't make sense to send data all the way to the Internet and some far away servers when you just want to reach your friend directly beside you; however, when you can make use of the Internet, and there are fibre optic cables and high speed non-congested links at your disposal, it can make a lot of sense to use it, particularly if your friend is many, many hops away on the mesh.

At the same time, the mesh can help the Internet. In places where the existing networks are congested and expensive, the mesh can be an option for people to have some basic level of connectivity. It can function when the cell phone towers have collapsed after an earthquake. It can also function when a government has decided to disable communications. Apps in the future will likely default to a mesh path as long as it is shorter than a certain number of hops.

For end-users I think mesh technology will lower the cost of access by increasing competition. At the end of the month people will no longer "lose" their last 300MB on their data plan, because they'll have the option to sell it back to someone else. People who can't afford large amounts of data will be able to purchase small affordable pieces. People who can't wait to get to their vendor to buy another 1GB plan because they are stuck in traffic might be willing to pay more to send a message to their boss about coming in late. Many new opportunities will be created as mesh networks are adopted, and both the Internet and the mesh will complement each other.

Subscribe to App Developer Daily

Latest headlines delivered to you daily.