RightMesh Technical Roadmap — the Next 6–8 Months and Beyond

Jason Ernst
RightMesh
Published in
8 min readAug 16, 2018

After taking feedback from the RightMesh community, it is clear that we need to move faster towards mainnet deployment. Our previous high level roadmap had mainnet still quite far out in the future, with a developers SDK beta release slated for earlier in plan.

We have decided to shift priorities somewhat in light of this feedback. It is also clear from community feedback that stakeholders want more detail, particularly with respect to our plan for the technology. While we would have loved to share this update with you sooner, we needed to ensure our team thoroughly understood the new plan and all its implications and were in full alignment before we shared externally.

However, we also want to make sure we are not launching prematurely and risking RMESH tokens. To balance these competing priorities, we are now pleased to share our solution which we are calling a “Soft Mainnet Launch”. We look forward to community feedback.

What is a “Soft Mainnet Launch”?

The reason we are calling it a soft launch is because the RightMesh data packets will not use mainnet tokens yet — they will continue to use testnet tokens. However, in order to operate a RightMesh Superpeer or act as a “data seller” you must have a fixed amount of RMESH tokens (exact numbers still to be determined). Your next question may immediately be: “Why the hell would anyone participate only to earn testnet tokens?”. The answer to this is that the soft launch will incorporate a competition in which participants will have the opportunity to “win” a significant amount of RMESH mainnet tokens.

The full details of the competition are still being finalised, but the concept is that a pool of RMESH tokens will be made available for the RightMesh Superpeers and another pool of RMESH tokens will be made available for RightMesh “data sellers”. Superpeers will compete with each other to see who can facilitate the most data transmissions. This will be dependent on:

  1. where they are in the world
  2. where the traffic demand is
  3. how fast their Internet connection is
  4. how good their payment channel balancing algorithm is.

Similarly, RightMesh “data sellers” will participate in a competition with each other. These users will be accumulating testnet tokens attached to sharing their data. The users who share the most data, will accumulate the most testnet tokens. Similar to the Superpeer operators, the “data sellers” will have the opportunity to “win” mainnet RMESH tokens based on how much data they have shared.

The RMESH tokens for each competition will be distributed at the end of the competition period based on how many testnet tokens the users have accumulated during the competition period.

The objectives for the mainnet soft launch and competition are:

  1. it allows us to encounter inevitable scaling problems without people losing real tokens
  2. it allows us to limit the number of RMESH tokens that are lost in the event something catastrophic occurs
  3. it allows us to run on the mainnet with our staking mechanisms.
  4. crowd sourcing development of better payment channel balancing algorithms

In conjunction with this post, you will find updates to our roadmap on the website. Over the coming days and weeks, more specifics about the roadmap, including trackable progress on each aspect will be available (we are drawing inspiration from the excellent roadmap from singularitynet). I will also write follow-up posts in the coming weeks with more details about each of the technical bullet points below so our community can understand what we are doing, and why.

Preparations for RightMesh Mainnet Soft Alpha Launch (6–8 months)

The goals to achieve before we are ready to proceed with mainnet soft launch are:

  1. RightMesh must provide support for multiple RightMesh Superpeers. To do this, several protocols and mechanisms must be built. This will allow the community to run RightMesh Superpeers and will help the RightMesh network scale and become more decentralized.
  2. RightMesh must implement autonomous connectivity. To make testing easier, users must currently manually set what role the devices play in the network. Autonomous testing will allow the RightMesh software to automatically pick whether it should be a hotspot, client, router, both at once. RightMesh will also choose when to use Bluetooth, Wi-Fi or Wi-Fi direct. The user will always still be able to override this.
  3. RightMesh has the tools to measure performance, and determine where scaling issues are occurring. Some baseline of performance will be achieved before launch, such that we are confident a small scale global network can be launched.
  4. The functionality to support staking on the mainnet must be built. Since data packets will be using testnet tokens, faucet functionality must be added to the testnet to supply Superpeers with appropriate testnet Ethereum and testnet RMESH to run automatically with little user intervention. The competition itself must be tested and some basic tracking pages created.
  5. There must be two or three RightMesh apps which people will be willing to use as “data buyers”. These users will not actually have to pay for data, but will depend on people participating in the competitions to supply free data for the competition period. The apps must be good enough and have sufficient value to end users that will keep them on their phone and use them.

In order to achieve this, the following is a breakdown of the high level technical tasks that need to be accomplished in order to achieve these goals.

Code re-organization

Automated testing, performance evaluation, bug & crash reporting

Encryption and security improvements

Autonomous connectivity completion

Multiple Superpeer support

Superpeer staking & Superpeer installation process

Token / Ethereum utilities & tools

Scalability troubleshooting

Marketing towards possible RightMesh Superpeer operators, RightMesh data sellers, RightMesh app users

RM end-user UI/UX + RightMesh apps

More details for each of these high level technical tasks are provided in the Gantt chart below, which gives estimates for how long granular tasks will take. It also shows tasks dependencies on each other and conveys which tasks may be done in parallel.

RightMesh 6-Month Technical Roadmap

RightMesh Mainnet Prelaunch Competition Period (4–6 months)

The goal of this competition is to experience mainnet tokens being used by having RightMesh Superpeers stake RMESH tokens. Additionally:

  1. We will begin to test, at scale, whether people will volunteer their data into the network for RMESH tokens.
  2. We will see whether people use RightMesh apps and find them useful to communicate with each other.
  3. We will determine whether the data protocols are stable and scalable, and where they are not, working to fix them while the system has users, but before we are at full scale. We will not be working with external developers during this period, except for one or two key partners who we are already engaged with.

Monitoring payment channels, smart contracts, network performance, bug reports, crashes

Implementation of scalability and performance fixes based on above

Experiments with different underlying network protocols, mechanisms

Collecting feedback from early users

Working with Superpeer developers on payment channel balancing algorithms

RightMesh Public Beta Soft Developers Launch (4–6 months)

The goal prior to developer launch is to ensure the network is able to scale well enough that external developer partners will not be disappointed by how RightMesh works within their apps. This should be a polishing of the RightMesh service, APIs and other components based on crash and bug reports by users in the mainnet alpha competition phase. Another goal prior to this is to have a community of developers ready to start using RightMesh. The preparations for this will occur in tandem with the competition.

The goal at end of beta is to involve external developers in limited scope. The challenge here will be ensuring that we work closely with developers to make sure they are building RightMesh apps that scale well and do not strain the young network.

Developer portal relaunch with updated UI

Multicast / broadcast protocol

Proof of concept for decentralized ad distribution

Improved UX and onboarding for users of RightMesh apps

Tooling improvements to support nightly builds, improved versioning, integrations with ticketing, support and other community systems (rocketchat, forums, etc)

Debugging tools for RightMesh developers

Trials at hackathons, developer events

Internal developer feedback from the RightMesh Bangladesh team building apps

Alpha deployment and partnership feedback

RightMesh Public Mainnet Beta Launch (6–12 months)

The goal before we start this phase is for us to be confident that:

  1. tokens are not being lost
  2. there are enough developers using our library
  3. performance and stability have significantly improved (to be defined)

The goal at the end of this beta is have data packets also using mainnet tokens, not just staking any longer. At launch, we will support incentives for the data sellers, and the Superpeers this way. At the same time on the testnet, we will start testing mechanisms to support intermediary nodes to receive tokens as well, possibly through a subsequent competition on the testnet.

Network protocols: multipath tcp implemented with ability to use multiple Internet connections together

Network protocols: delay tolerant data transfer available on the testnet version of RightMesh

General purpose Internet access on RightMesh

RightMesh R&D Efforts (ongoing)

Delay tolerant network modifications

Building tools that allow us to predict where people need more connectivity and at what price

Improving the UI / UX for users of RightMesh so they are incentivized to move to where connectivity is needed

Building simulations and models which will allow us to predict the flow of tokens, behaviour of stakeholders in the system so that relevant incentive mechanisms can be designed to encourage the behaviour needed for system stability

Building simulations and employing real-world experiments to determine where and how the network can be shaped to improve QoS/QoE, save energy, become more efficient.

Expanding into other platforms (compatibility and interop)

Hopefully this post adds some much requested detail to the conversation and helps people in the community understand that we are constantly planning, building and moving forward on our tasks.

We will work to increase the transparency of this process going forward. More details will be added in subsequent posts explaining these bullet point items, how far we have already progressed with them, why we are working on them, and what is still in store. A Gannt chart showing what is parallelizable and what is concurrently being worked on is being prepared.

As always, I am happy to answer questions or comments here or on telegram.

UPDATE: February 15, 2019

Excerpt from Tech update:
We are continuing to move towards the Soft Mainnet Launch during which select operators and users can participate in the RightMesh network; however, data packets will use testnet tokens rather than risking tokens on the mainnet. This will allow us the opportunity to test and trial the platform and protocol and to gain valuable community feedback for planning the network before public launch.

We have realized that our initial incentivization plan for participation in the launch — rewards of RMESH — may not be viable with the current valuation of our tokens and the state of the cryptocurrency market as a whole. We are reviewing this internally and will update our community as we come to a resolution on the timeframe and incentivization. What will emerge from these internal discussions is a delayed launch but a more viable incentivization plan to ensure maximum participation and rewards.

--

--

Jason Ernst
RightMesh

Senior software engineer working on robotics. interested in mesh networks and decentralization