For better visibility, Luis presented IoP roadmap few days ago. enjoy
Fermat Road-map
Fermat as a project has several dimensions. That means that our technical road-map is not linear, because it includes several paths at the same time. The first path started early 2015 with a prototype of the infrastructure that will run at end user devices. Another path started at the summer of 2016 with the implementation of Internet of People components.
Each component released is a catalyst for many things to happen. For example, the release of our token system enabled people to start mining, and after the concept of mining license and mining cap was developed, that enabled the formation of local chapters. The token system also enabled the governance system, and so on.
I describe here a summary of what has been done up to now and what is next at the core level. Expect on top of this road-map several secondary branches to appear.
The following is the time-line that includes both paths:
2014 — Q3, Q4 — Fermat Vision
The initial Fermat Vision was established. This vision was later refined with time, but its essence remained. By that time I was seeing how Satoshi’s invention was being abused by companies that started the shift from the concept of “be your own bank”, towards “let us be your crypto-bank”. The whole ecosystem started moving towards centralized wallets, centralized payment processors, centralized mining, and it has remained on that path until today.
The initial client-side architecture was designed. This involved a lot of innovations that we don’t talk about today since it is too early, like for example building apps with reusable components that produce a stream of micro-payments to their authors. The original Fermat white paper was conceived by this time. This will later become the foundation of Person to Person apps.
2015 — Q3, Q4 —Fermat SDK Architecture
The initial architecture was implemented. I wrote myself the very first implementation of this architecture, which has been since improved upon by dozens of developers and from my code there is probably not too much there anymore.
By this time the first angel investor round was closed and a programming competition was organized to select the best devs to work in the next phase.
2016 — Q1, Q2 — Person to Person Apps Prototypes Developed
We developed several person-to-person apps, including a bitcoin wallet, IoP wallet, apps for handling digital assets, apps for crypto brokers, etc. We did a wide range of apps to be sure that the conceived architecture was good enough to support any type of use case. Most of these apps were left working but the network infrastructure (what we call the Internet of People) was missing.
Once we release the basic components of the IoP by the end of 2016, we will come back to these apps and connect them to the IoP and release them to the public.
2016 — Q3 — IoP Token Blockchain.
In this quarter we implemented:
IoP Blockchain: This includes the v1 of the Token Server. Modeled on the bitcoin codebase, we inherit all of bitcoin’s benefits. We modified this codebase adding more rules for mining with the aim of preventing a centralization of mining. We introduced the Mining License concept together with the Mining Cap. These improvements allow for mining with regular PCs and enables complex structures to do the mining, like for example the Fermat Chapter Network.
Pre-Mining Distribution Software: This allowed us to distribute the pre-mined IoPs. During the first 2 years of the project IoPs were distributed to contributors and investors. Once the IoP blockchain was ready we needed a software to distribute these pre-mined tokens. This software was used both to distribute immediately available tokens and time-locked tokens as well.
IoP Android Wallet 0.5: For mobile users. We forked the most popular wallet and made it compatible with the IoP blockchain. We still need to come back to it and do some Fermat branding on it, and also upgrade it to be an IoP app (uploading profiles to IoP Profile Servers in order to allow users to find each other and automatically exchange addresses). A very interesting thing is that we shouldn’t do that upgrade only for our wallet. We could merge those changes back in the original bitcoin wallet, allowing all their user base to be on the IoP and solve an existing problem these wallet users have: the exchange of addresses via insecure means like instant messages or email. This is a very good candidate project anyone in the community can propose to be voted in January 2017. But the real beauty of IoP is that it can also be done in all other cryptocurrency wallets, turning all their user base into IoP users!
Mining Licensing Administration Tool: This is the software used by the the license administrator (Markus Maiwald) to grant and revoke licenses. This is a short term solution until the Chapter App is released at Q1 2017, which removes the administrator allowing chapters to self govern.
2016 — Q4 — IoP Servers and Nodes.
In this quarter we implemented:
IoP iPhone Wallet: For Apple users. This was forked from the most popular bitcoin wallet for iPhone. It is currently waiting for Apple approval. Everything said about the Android Wallet applies here too.
Profile Server v0.5: This is an original piece of software implemented from scratch by our developer team. This includes several features up to the integration with the LOC Network. This first release has enough features to start building IoP apps. What is missing at this release is the integration with the CAN Network and charging IoPs for hosting profiles. That means that while we wait for the v1.0 release profile hosting is for free! (That should also help creating a critical mass of users).
LOC Network v1.0: This allows the Profile and Proximity Servers to be geo-localized. This is also an original piece of software implemented from scratch by our developer team. All the expected functionality will be available at the first release.
CAN Network v1.0: This allows the Profile and Reputation Servers to index end user profiles and user reputation respectively. The IoP CAN Network is an extension of IPFS (Inter-planetary-file-system). IPFS was not designed to have client apps, they expected every user to run an IPFS node. We fixed that. Also IPFS doesn’t expect that the seeder of a content might not be the direct owner of the content, and that is our situation since Profile Servers are seeders but they don’t own the profile information themselves. We also fixed that. Finally IPFS had plans to implement an embedded naming system that would allow users to retrieve content information with an immutable key even if the content and it’s hash changes. We need this in order for client apps to remember the public key of a profile owner, enabling client apps to retrieve the profile even when the content itself, like a user’s profile picture for example, has changed. IPFS devs have been discussing this for some time but they haven’t implemented it yet, so we did it for them and offered this feature upstream to be included on IPFS itself.
Governance System: This includes a Contributors Android App, and a Voter’s Android App. The original idea of issuing tokens not only for miners but also for paying for contributions the project needs is credited to the DASH cryptocurrency team. They were the first to successfully implement this and now they enjoy a self-sustainable status as a project. We aim to get to self-sustainable status during 2017 and for that we need our own version of a governance system. We didn’t reuse their codebase, but implemented our own set of ideas from scratch. That includes two mobile apps: One for Contributors, where anyone can submit Contribution Contracts. The second one for Voters, allowing any token holder to vote which Contribution Contract should be paid by the blockchain. This is a major difference with DASH model, since they allow only node operators (usually geek guys) to vote what should be done or not.
2017 — Q1 — IoP Servers and Nodes.
In this quarter we will implement:
Profile Server v 1.0: This includes the integration with the CAN Network and SPV wallet. At this point the Profile Server has all its expected functionality.
STUN Server v 1.0: IoP STUN Servers are a fork of popular open source STUN Servers. Their function is to help two end user devices get connected to each other directly, bypassing firewalls that might be between them. We extend the original implementation to include the incentivisation layer, that allow these servers to get paid in IoPs for the services they provide.
TURN Server v 1.0: When STUN Servers are not enough to get two devices connected directly, TURN Servers must be used to establish a connection. Also here we extend the original implementation to include the incentivisation layer, that allow these servers to get paid in IoPs for the services they provide.
Latency Based Network v1.0: This network helps end users devices find the most appropriate TURN server when needed.
Chapter Network System: This includes an Android Chapter App that will allow us to scale our Chapter Network. This system will remove the figure of the administrator granting and revoking chapter mining licenses. At the same time the system will allow the current chapter network of around 50 chapters, to grow to tens of thousands (including all countries, all states within those countries and all cities within those states). The system includes a mobile Chapter App, that will enable chapters to self govern, self audit and manage their memberships, tasks and licenses in a decentralized way.
Fermat SDK v 1.0: First release of the Fermat SDK. This is the work done during 2015–2016 upgraded to be using the new components of the IoP. This infrastructure runs on end user devices and is the key for Person to Person apps.
2017 — Q2 — IoP Servers and Nodes.
In this quarter we will implement:
Proximity Server v1.0: The Proximity Server is a component we designed and we will build from scratch. This enables a set of use cases or apps that need to find users by proximity. For example a Taxi App needs to allow its users to find Taxi Drivers driving nearby them.
Reputation Server v1.0: This allows end users to submit reputation records of other end users they have a relationship with. People’s reputation is needed in a wide array of use cases and apps. Also in our example App of a Taxi System, end users need to know a Taxi Driver’s reputation in order to decide if they take a ride with them or not.
2017 — Q3 — IoP Servers and Nodes.
In this quarter we will implement:
Minting Server v1.0: This will allow us to manage the minting process properly. Minting new IoP token started in the same way as minting new bitcoins. But in order to keep our system secure and decentralized, we need to improve a lot in this area. Then we need to create a specialized server to deal with the minting and leave the Token Server with the task of processing transactions and record them at the blockchain.
Token Server v1.0: Specialized Token Server focused on transaction processing. The functionality to process transactions and securely store them at the blockchain will stay here. This will allow us to continue innovating in the Minting without affecting the network’s operations and stability. The PoW mining stays here for convenience and to keep avoiding centralization.
Unstructured Network Node v1.0: To be used by the Token & Minting Servers. At this point in time we will also separate the networking features of the bitcoin node used as starting code base into a new network node component that later can be reused by multiple servers.
Taxi Proof of Concept System: We already have all the infrastructure ready to develop the Taxi person-to-person apps, with zero transaction fees. These two mobile apps: the Taxi Passenger and the Taxi Driver apps, will use almost all the infrastructure built so far: Token Server, Profile Server, Proximity Server, Reputation Server, STUN and TURN Servers and the Fermat SDK. The system will be developed by Contributors submitting Contracts to the community and voted by the latter. The contributions will be paid by the issuing of newly minted IoP tokens. By the time of its release, we expect to have a strong Chapter Network to distribute it all over the globe. Later it will be used as a case study to build similar systems for other industries.
As you can see, we have a nice core road-map, full of technical challenges. The future looks bright and we believe we are on the right path.
Thanks to Amadeo Charlé for the editing.