[IoP] Fermat presents the Internet of People App Token

  • Who is Fermat?

    We are a group of hardworking people driven by our vision and collaborating to change the path to another future. We are pioneers, developers, inventors and dreamers, discovering new paths, trying to change the world.

    We are neither a corporation or company, nor driven by any third party economical interests. We don’t believe in concentration of power because we think that in the wrong hands it could lead humanity to a catastrophic failure. We believe in freedom and the power of technology. We believe in people. We are happy to use our skills to recreate over the internet the same level of private person-to-person interactions that we have to protect outside the internet.

    Fermat’s Vision

    We have been living inside an ongoing trend towards centralization of power and control. In present time a handful of entities (giant companies or conglomerates including some states) dictate with the control over politicians and military what a huge percentage of the world population can or cannot do. In this current scenario it is not difficult to predict that fights between such interest groups are likely to happen and someday in the future some entity may try to control it all (in a devastating big fail).

    Anticipating that future, we envision a world where people can freely interact electronically without unnecessary third party interferences. Both for social and commercial interactions. No spying, no censorship, no taking a cut on private transactions between individuals, no mining of self-defined private information, no unnecessary middlemen. A world where people are more important than entities like companies and states, a world where people have the choices and the means to interact directly between each other. This is the Fermat project vision and to reach this goal we first have to build the Internet of People.

    What is the Internet of People?
    What we need to enable now is direct device to device communication, with data being stored at end user devices and apps built to interact with each other directly over the Internet but without going through the web or requiring any service from any company or institution. We need P2P Apps that can run independent of any entity.The Internet of People is a set of P2P networks, designed to enable direct device to device P2P communication using P2P apps. The main purpose of the network is to allow my device to connect directly to your device without using any service of any company in the process of establishing the connection or during the interaction.
    One of this P2P Networks is a blockchain that runs the token system needed to incentivize operators to run all the components of other P2P networks that form the Internet of People.
    We call our token the IoP and its existence is what we are announcing here today.

    IoP Token Fact Sheet

    Name: IoP [Internet of People App Token]

    Official Ticker: IoP

    Blockchain Type: Fork of bitcoin 0.13.x

    Max Supply: 21 M

    Pre-Mining: 10%

    Pre-Mining Beneficiaries: Angel Investors (2 rounds over 2 years, 650K USD total invested). Founders, early contributors received pre-mined tokens as bounties for their contributions.

    Project Running Time: 27 Months. (Started Aug 2014)

    Available Supply: 2,109,000 approx. minus 525,000 time locked at the blockchain level. Time locked tokens redeemable in 1, 2, 3 and 4 years counting from Oct 2016.

    Target Block Reward: 1 token for miners / minters every 2 minutes. Zero to 1 token for Approved Contribution Contracts every 2 minutes (voted by token holder via the blockchain. Think DASH)

    Current Block Reward: 1 token for miners every 10 minutes. There is a schedule to get to the Target Block Reward after hitting several software development milestones. You can find this schedule here under the title “Token Issuing”.

    Target Consensus Mechanism: Randomized PoS / PoW hybrid. We expect to implement our own ideas on a PoS / PoW hybrid model. You can find more details here under the title “IoP Token System” .

    Current Consensus Mechanism: Pre-Authorized PoW. Until we develop our own consensus mechanism we are running a regular PoW with participation in the mining restricted to developers and community local chapters. Once our consensus model is in place, permissionless mining will start.

    Halving Rules: The same as bitcoin, every 4 years.

    Token holders will be able to:

    • Propose projects to be funded by the blockchain after being approved by token holders.
    • Vote for projects to be funded by the blockchain.
    • Run IoP nodes and participate in the mining reward proving their stake on IoPs.

    Tokens in small quantities (micropayments) are also needed for:

    • End Users need them to pay Profile Servers to host their profile at the IoP Network.
    • End Users need them to pay for other IoP Network services like Proximity and Reputation.
    • Funding their online identities.
    • Connecting to other people.

    ICO, Crowdfunding Market Value and Exchange
    We are not planning an ICO. We have no plans of a crowdfunding campaign either. The project is not holding tokens. We are and want to stay independent. Our development funds were secured by our early token sales to angel investors of pre-mined tokens.
    We are, however, planning to take the IoP token to the market soon – after this announcement. We expect a market value of $12 per token since that was the last price contributors received during this early days of the project.

    Project Status
    The project is 27 months old. The first year a handful of people joined forces to forge the vision and design the system architecture. The second year more than a hundred people collaborated to prove the concept was viable. We are now at the beginning of the third year, already producing production quality code. Over the course of the next 12 months we expect to release all the Internet of People components (there are many, and it is a technically challenging project). From there we will move on to bootstrapping the P2P economy, creating tools and client-side infrastructure to easily develop device to device P2P Apps.

    We are currently funded by early token buyers (angel investors). During the next 12 months we transition to a DASH-like Contribution-Voting-System paid by the blockchain with the issuing of new tokens (issuing go to miners and a significant part goes to contributors approved by token holders voting over the blockchain). We enter the market with our App Token in Nov 2016.

    On our website you will find the following resources:

    • Article that will explain you the Internet of People in the context of Bitcoin and Ethereum.
    • Links to all available IoP wallets.
    • Links to important documents like:
    • Internet of People whitepaper.
    • Software Requirements Specifications document.
    • Fermat long term vision whitepaper.
    • Internet of People presentation document.
    • IoP Token Explorer can be found here.
    • Internet of People’s vision presentation.

    Github Repos:

    Call to Action
    We recommend you reading the following documents in this order, to have a better understanding of what we are doing:

    • The home page of our website. Our current featured article will give you the needed context of the project. Also you will find there links to the press coverage that can tell you how journalists interpreted our work.
    • The script of our presentation. This will show you step by step in plain english what we are building and why.
    • Internet of People’s vision presentation. This will give you an idea on what a world with the IoP will look like.
    • The Internet of People whitepaper. It will give you some more technical details. Expect a technical overview the project.
    • The Software Requirements Specifications document will get to the technical details needed to actually implement the code of each component. Also will give you some sense on where we are now and the current problems being discussed.
    • The Fermat long term vision whitepaper will give you an idea of what is beyond the Internet of People.

    Unless we are heavily spammed, we will keep the door open for you to comment on any of the Google docs.

    We encourage you to ask questions here in this thread regarding anything you read about Fermat.

    If you like our project and want to support our vision, you can either join or build a Fermat Local Chapter (with possibilities to mine if you wish) or buy IoP Tokens once they reach the market (soon).

  • Hi there,

    thanks for posting our announcement here in this nice board.

    Could you please correct the tag Fermet to Fermat? Thank you!

  • @marmai

    Thanx for notify, Now we change the tag

  • Today we present you additional Blockexplorer financed by Chapter Swiss!


  • WALLETS Version 3.0.0. for TESTNET
    Please update ASAP

    Install guide MAC

    At the moment we only provide instructions to build your own copy of IoP Core. If you have absolutely no idea about programming, please follow the Laymen's Guide. If you know your way around the terminal and want to control exactly where files are placed, follow the second guide.

    You will need Apple's XCode (Command Line Tools are not sufficient). For Mac OS X 10.11.5 or higher, it is provided for free via the Mac App Store. If you are on a lower Version of Mac OS X, you need to manually download Xcode from the developer homepage. For this you need to register for a free Apple developer account on http://developer.apple.com

    Building IoP Core on Mac OS X for Laymen

    • This guide is made for people who have no experience building their own software. As the IoP wallet software is still under heavy development, difficulties may arise. Please report all issues and be patient for an actual release or an updated guide.

    • Update you Mac to the newest version available (at least 10.11.5)

    • Install the latest XCode Package from the Mac App Store and run it. Accept the License Agreement and let it install components.

    • Open the Application Terminal and paste the following lines one by one, pressing the return key after each one and then waiting until you are prompted for input again.

      /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

      brew install automake berkeley-db4 libtool boost --c++11 miniupnpc openssl pkg-config homebrew/versions/protobuf260 --c++11 libevent qt5 This will take a while.

      git clone https://github.com/Fermat-ORG/... ~/Documents/iop-token

      cd ~/Documents/iop-token

      git checkout beta

      ./autogen.sh && export CXXFLAGS=-std=c++11 && ./configure

      make && make deploy

    If everything goes well, you can find the disk image IoP Core.dmg in your Documents Folder under iop-token. Mount it by double-clicking and drag the Application IoP Core onto your Applications Folder.

    Building IoP Core on Mac OS X

    • Install XCode and run it. Accept the License Agreement and let it install components.

    • Install homebrew via the terminal (Terminal.app) with

      /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
    • Install dependencies with

      brew install automake berkeley-db4 libtool boost --c++11 miniupnpc openssl pkg-config homebrew/versions/protobuf260 --c++11 libevent qt5

      This will take a while.

    • Use the terminal to clone the git repository to your favorite location with e.g.

      git clone https://github.com/Fermat-ORG/iop-token.git ~/GitHub/iop-token
    • Change to this location using cd ~/GitHub/iop-token or equivalent.

    • Make sure you are on the beta branch: git checkout beta

    • Run ./autogen.sh

    • Add compiler flags via export CXXFLAGS=-std=c++11

    • Run ./configure

    • Run make && make deploy. You might get some warnings about deprecated functions. Ignore them. If everything goes well, you can find the disk image IoP Core.dmg in ~/GitHub/iop-token. Mount it by double-clicking and drag the Application IoP Core onto your Applications Folder.

    Some Notes

    At the moment, the GUI does not show or generate QR Codes.

    Your wallet and all data will be stored in ~/Library/Application Support/IoP/. To backup your wallet, copy ~/Library/Application Support/IoP/wallet.dat to a secure location. Although there seem to be no problems, you should use this wallet file only with the Mac OS X version of IoP Core, as the Mac version is compiled against Berkeley DB 4 instead of Berkeley DB 5 and data files might be incompatible. To migrate your wallet between Operating Systems, we recommend using dumpprivkey.

    A note for experienced users

    You can use berkeley-db (v6.1.26 as of 2016/10/08) instead of berkeley-db4 to compile IoP Core, but data files might not be fully compatible between different versions of BDB, so it is recommended to migrate wallets between versions and/or operating systems via dumpprivkey. You also need to configure with ./configure CPPFLAGS="-I/usr/local/Cellar/berkeley-db/6.1.26/include -O2" LDFLAGS="-L/usr/local/Cellar/berkeley-db/6.1.26/lib" --with-incompatible-bdb

    Install guide Linux

    Installing IoP Client

    At this early stage we don't provide other packages than for Ubuntu Linux. But you can find other community packages on the community repositories

    For a little help building IoP Core on OSX see INSTALL_OSX.md

    We will provide Windows, MacOSX and other Packages after the beta phase, please be patient.

    Installing Ubuntu Packages

    To install IoP the first time on Ubuntu, add new repository to /etc/apt/sources.list.d/IoP.list with your editor (here "nano"):

    sudo nano /etc/apt/sources.list.d/IoP.list

    In the editor you do this

    for Ubuntu 14.04:

    deb [arch=amd64] http://repo.fermat.community/ 14.04 main

    for Ubuntu 16.04:

    deb [arch=amd64] http://repo.fermat.community/ 16.04 main

    Save and exit editor.

    Import the key that is used to sign the packages:

    gpg --keyserver keys.gnupg.net --recv-keys 0CC9EB6DA69C84F4

    gpg -a --export A69C84F4 | sudo apt-key add -

    After that you can install IoP tools as any other software package:

    sudo apt-get update

    sudo apt-get install iop-blockchain

    After installation is complete, start the IoP wallet by running IoP-qt from the command line.

    IoP-qt ... and have fun! :-)

    Now you should have a working IoP blockchain deployment.

    Upgrading Ubuntu

    If you have already installed and want to upgrade to the latest, please follow this way:

    sudo apt-get update

    sudo apt-get upgrade

    Troubleshooting in case of IoP Package error

    If you run into problems with the package versions, then you could try following:

    sudo apt-get remove iop-blockchain

    sudo rm -fr /var/cache/apt/archives/*

    sudo apt-get clean

    sudo apt-get update

    sudo apt-get install iop-blockchain

    ** if you are in trouble you should always backup your wallet.dat file!** After that empty the .IoP folder despite the wallet.dat - then start the IoP-qt again.

    Windows, MacOSX and Other Packages

    We don't support offically other packages (yet). Nevertheless, there are unsopported community build packages where you can even find Windows packages.

    Using the blockchain tool

    Until we have official documentation you can follow the Fermat IoP Wallet Guide:



    Compiling from source

    First you have to grab the source code, you can just clone our GitHub repository. Assuming you work on Ubuntu and don't have git installed yet, you can have our initial release (tagged version beta-1.0.0) with:

    sudo apt-get install git

    git clone https://github.com/Fermat-ORG/...

    cd iop-token

    git checkout beta

    Now comes the hard part, you will have to install the whole build environment which means an awful lot of tools, libraries and headers.

    sudo apt-get install g++ make automake pkg-config libtool libboost-all-dev libssl-dev libevent-dev libqrencode-dev libprotobuf-dev protobuf-compiler libqt5gui5 qttools5-dev qttools5-dev-tools

    We still need the BerkeleyDB library to support wallets. The code assumes wallets built with 4.8 by default, but this version is now outdated and not accessible from the default repositories. If you insist on using backwards-compatible wallets, you have to get the library from a custom archive repository as described here https://github.com/bitcoin/bit... (look for add-apt-repository). We simply suggest using a recent libdb version instead.

    sudo apt-get install libdb++-dev

    Now you have to generate the build configurator files.


    Now you have to generate makefiles that fit your environment. This will take a lot of time. If you are using backwards-compatible wallets with libdb4.8, you can remove the option from the following command:

    ./configure --with-incompatible-bdb

    Finally, you can compile everything. This will take a very, very long time. Note that if you have a lot of CPU cores in your computer, you should use the -j option to compile with multiple threads, e.g. -j8 for eight compiler threads.


    If you want to run the compiled binaries directly, you can find them in directory src, e.g. src/IoPd or src/qt/IoP-qt. Otherwise, you can deploy them as usual with

    make install

  • Contributions Governance System Road-map

    Fermat governance is divided in two halves. The first one is about the governance of mining, the second one is about the governance of contributions. Today I will focus on the second half.

    Contributions Governance System

    These days we are releasing version 1 of our contributions governance system. This version is good enough for the next phase of the project. Any community member can contribute using the newFermat Contribution App to submitContribution Contracts to the system. Anyone using the new Fermat Voting Appwill be able to vote if they want that contract to be executed or not. We are innovating here in many aspects since as far as I know, no other crypto-project has a governance system exactly like this one. During the next months we will collect feedback on its usage and monitor it for abuses. I expect that after some months we will upgrade it with changes based on feedback.

    As we move forward towards a large decentralized organization, this version 1 will become obsolete. That is why we are already thinking about a version 2, with the following improvements:

    • Reputation Based: Version 1 is about voting power based on token holdings. This is fine for the current phase of the project, but as the project and its ecosystem grow, it will start attracting the attention of bigger players with huge financial resources. Before that happens, we need to move forward to version 2, were besides token holdings, reputation is also used to compute the voting power. The most advanced research we found so far in this area was produced by Backfeed and you can learn about ithere.
    • Accommodating Diversity: Version 1 fits the current stage of the project very well where even though we will have Contribution Contracts, we don’t expect hundreds of them in the very short term. But once we grow, it will be natural that the community starts separating themselves into different interest groups. Version 2 should be flexible enough to accommodate for diversity and allow these groups to thrive and self govern in their own context.
    • Rewarding Spontaneous Contributions: Version 1 is more about projects. Project proposals are submitted, discussed and later voted. If approved, a Contribution Contractis executed and the payments are distributed by the blockchain towards the beneficiaries. This is fine for this phase because we are heavily under construction. At some point it will make a lot of sense to reward spontaneous contributions based on the perception of the community of their value. In this category fall bug fixes, good ideas, or any small-medium action in general that adds value to the project.

    We are currently in open talks with the people at backfeed, and we might collaborate in the implementation if we end up using their protocol. In a few months they will be releasing a reference implementation of their protocol on Ethereum branded asDAOStack.


    The road-map of our Contributions Governance System is:

    1. Deploying Token Server v.3.0.1 (IoP Core): Currently underway. Project executed by Rodrigo Acosta with the help of Matias Furszyfer.
    2. Deploying Android Contribution App: Version 1 is ready, waiting for the IoP Core v.3.0.1 to be a clear majority on the mining network. This app was entirely developed by Matias Furszyfer.
    3. Deploying Android Voting App:Version 1 is ready, waiting for the IoP Core v.3.0.1 to be a clear majority on the mining network. This app was also entirely developed by Matias Furszyfer.
    4. Security Audit of IoP Core: We expect to receive proposals from specialized cyber security firms to audit the work done at the blockchain level to processContribution Contracts. We understand that this is a very sensible part of the whole system and must be audited extensively.
    5. Professional Redesign of UX/GUI:We understand that the apps developed don’t have a sleek user experience design and user interface yet. They are just a reference implementation. We are happy to receive proposals for a professional redesign of both the user experience and user interface, together with the implementation of the changes or the implementation separated in a different project. This new redesign must accommodate the results of our Marketing Strategy Plan that is currently under development.
    6. Implementing iOS Contribution App v.1: This is an open project which won’t involve the current core devs. Anyone in the community can submit a project proposal for the development of this app. My recommendation is that you wait for a while until the corresponding Android app is used and real life usage feedback is incorporated on it. Also, it should come after the professional redesign of the UX/GUI.
    7. Implementing iOS Voting App v.1:Exactly the same situation as 4). Open project for anyone to propose.
    8. Android Contribution and Voting Apps v.2: In version 2 we convert both apps into IoP Apps (they upload profiles to Profile Servers and communicate with each other directly) and we eliminate the usage of a centralized forum. This project depends on the IoP SDK to be released. Open project for anyone to propose.
    9. iOS Contribution and Voting Apps v.2: Same as 6) with the iOS apps. Open project for anyone to propose.

    Thanks to Amado Charlé for the editing.


    Luis Fernando Molina

  • Fermat Core Values

    It is not robots,

    It’s not machines,

    It’s not algorithms,

    It is not things,


    It is not companies,

    It is not states,

    the most important is people,

    people like you and me.

    * * *

    In a world where jobs are stolen,

    by AI agents and automation,

    we empower humans beings,

    so that they can become the center.


    Companies have us trapped on the web,

    and private social networks of people,

    even things now have their own Internet,

    we fight back with the Internet of People.

    * * *

    State mass surveillance is widespread,

    before we end up in desperation,

    We propose a new idea:

    device to device communication.


    Some of them had grown too big,

    and their power became a risk,

    you just need one crazy guy,

    and we might all just disappear.

    * * *

    We are not against companies,

    we are not against states,

    we understand they are important,

    but sometimes, they are just a middlemen.

    * * *

    We give people the freedom to choose,

    whether to use fiat or cryptocurrency,

    whether to store it at a bank or by themselves,

    that’s how we help in this story.


    We give people the chance to interact Person to Person,

    over electronic means,

    but just like in the old days,

    any business we do, stays just between you and me.


    We give people sovereignty over their data,

    they can sell it if they wish,

    we provide a global marketplace,

    they just need to sit and wait for the money to come in.

    * * *

    At the Internet of People we run our servers,

    we store our data and run our apps.

    If you are thinking about spying us,

    All I can tell you is good luck with that.

    * * *

    If a company wants us to consume their ads,

    They have to pay us.

    If a company wants mine our data,

    They have to pay us.


    If we want to find some people,

    It is free for us,

    If we want to connect with someone,

    It is free for us.

    * * *

    We stand for decentralized mining,

    and a democratic blockchain,

    where all stakeholders are considered,

    and the rewards ease all their pains.


    We don’t care about hashing power,

    we don’t waste precious energy,

    we don’t use specialized hardware,

    our miners are humans beings.

    * * *

    The revolution already started,

    so you’d better choose your side,

    either you are with machines, things or entities,

    or you are human as I am.


    In our future we are the rulers,

    and machines are to serve all men,

    things, states and companies at our service,

    as it always should have been.

    * * *

    We are building the Internet of People,

    we are enabling the Person to Person Economy,

    we will create a better future,

    we don’t care if you think we are crazy.


    Thanks to Amado Charlé for the editing, Jeremy Epstein for the guidance and the broader Fermat Community for the last minute review.


    Go to the profile of Luis Fernando Molina

    Luis Fernando Molina

  • Mining Governance System Road-map

    Today I am going to describe the official road-map of the first half of the Governance System. Fermat governance is divided into two halves. The first one is about the governance of mining, the second one is about the governance of contributions.

    Mining Governance System

    At the Internet of People, tokens are mined by human beings. They do it with their regular computers, or at least that is the intention. We already have a Mining Licensing scheme version 1 running and it proved to be successful so far. Each license was given to people in Fermat Local Chapters who add value to the project. No need for specialized hardware or energy waste. The mining licenses can be obtained by running local accounts of social media, running local meetups, building a local website, and so on.

    Our philosophy is to be highly inclusive. In this first phase blockchain enthusiasts are the ones participating in IoP mining. Early adopters, mostly geeky people. Once we consolidate this target audience, we will move forward to the next one: researchers. After them, we will allow entrepreneurs to mine, and like this, more stakeholders will be joining.

    There is a so called round-robin mechanism which allows one block to be mined by chapters, the next one by researchers, the next one by entrepreneurs, and so on, until the point where there are no more stakeholders, and its start again with chapters.

    As of today, the IoP system is not mature enough to engage non technical people in mining. At the same time, the project is already demanding research work in different areas. So one way to stimulate research efforts is by opening the mining to researchers.

    The research network is similar to the chapter network, but instead of chapters we have Research Labs and instead of chapter members we have the Lab Members, typically students lead by their teacher, the Lead Researcher. The requirement to qualify for mining with a Fermat Research Lab is to have a research project approved by the Contributions Governance System. That enables a Research Lab to mine for one year, independently of the duration of the approved project (with some minimum TBD). Labs that get funds from grants or similar for their Fermat / IoP research project, can profit from a higher mining cap.

    The current state of our Mining Governance System is that an Administrator activates Mining Licenses of people believed to be doing a good job. With more than 70 chapters and a dozen of possible tasks to do to acquire the licenses, we are close to reaching the limits in terms of what can be managed manually. At the same time, we need a version 2 that removes the administrator and allows each chapter to audit the others. The specification of the systemneeded to accomplish this is already finished, waiting for reviews. From that document we can see that such a new version will require several different individual projects. All of them are listed below as part of the official road-map.

    The road-map for our Mining Governance System is:

    1. Defining Interfaces: This project is needed to define the interfaces between the three major components that are needed as part of version 2 of the Mining Governance System:
    • Minting Server (IoP Core): Our current Minting Server needs to be upgraded in order to understand who can mine at any moment based on a totally new set of rules.
    • Chapter Network State Machine: A virtual layer on top of the blockchain that tracks all chapter activities in order to recreate the current state of all Mining Licences, automatically resolving potential blockchain forks.
    • Fermat Chapter App: An Android / iOS mobile app to manage chapters, their membership and licenses.

    2. Sequence of Projects and Milestones on the Minting Server (IoP Core):

    • Round-Robin Mechanism: This project defines and implements the round-robin mechanism that will enable the mining to be done by different networks of people, each block minted alternately. The mechanism will automatically activate a new stakeholder type once it recognizes license activations for that stakeholder made by the administrator. This means that each new stakeholder type will start with a system managed by an administrator, like today’s Chapter Network, until the automation of their network is implemented.
    • Research Network Mining (version 1): This is not a project but a milestone. It is achieved when we start allowing researchers to mine IoP tokens. Initially they would enter into a very similar scheme were chapters are today, where an administrator would activate the mining licenses of the first set of research labs.
    • Chapter Network Mining (version 2): This project will replace the current scheme where the Minting Server reads the blockchain to calculate who can mine and who can not, and it will interpret the state of Mining Licenses from the Chapter Network State Machine.
    • Business Network Mining (version 1): Same situation here, this is a milestone hit once we allow entrepreneurs to mine.
    • Business Network Mining (version 2): This project implements the necessary changes to interpret the state of Mining Licences from the corresponding State Machine.

    3. Implementing the Chapter Network State Machine: We are analyzing the possibility to adapt Blockstack to be used with our blockchain and provide Fermat with three of the four layers they define as:

    • Blockchain Layer: We already have this, and it should integrate well since they are working with the bitcoin blockchain.
    • Virtualchain Layer: This is whereState Machines run, they have only one so far, for recording a unique name on a blockchain. We might need that as the set of services the Internet of People provides to Person to Person apps, but what we currently need is the possibility to create a second State Machine, in this case to keep the state of the mining licenses, endorsements between chapters and their members, etc.
    • Routing Layer: I am not sure we need this right now, it will be determined by a deeper analysis, but for sure is needed for the use case of recording names on the blockchain.
    • Storage Layer: Same as before.

    4. Developing the Fermat Chapter App: This is the app that would replace the current version 1 of the Mining Governance System and allow us to move forward to version 2. This app will be developed both for Android and iOS at the same time. Note that this project has as a dependency the IoP SDK version 1, which includes connectivity to PRO SRV, CAN NET, LOC NET, STN SRV and TRN SRV. The IoP SDK version 1 is part of a different road-map.

    5. Designing the Research Network State Machine and App: This analysis & design project is needed to define how this is going to work. It will be executed after gathering on the field experience about Fermat Research Labs. It includes the interfaces between these two components and between the State Machine and the Minting Server.

    6. Implement the Research Network State Machine: We will add to the Virtualchain Layer another State Machine. At this point we will already have experience doing this, so we should expect this not to be so difficult.

    7. Implement the Research Network App: This will likely be an adapted fork of the Fermat Chapter App. We will initiate this project after polishing the Fermat Chapter App with feedback of usage collected on the field.

    8. Designing the Business Network State Machine and App: This network is made up of entrepreneurs or business people in general connecting their Apps to the Internet of People. The idea is that whoever brings critical mass to the project, should be able to get rewards by mining IoP tokens. The mining cap in this case must be proportional to the active users they are adding to the Internet of People.

    9. Implement the Business Network State Machine: We will add to the Virtualchain Layer yet another State Machine. This state machine will have to compute the active users of each App connected and by doing so, calculate the mining cap and state of each Mining License.

    10. Implement the Business Network App: This will allow each entrepreneur / businessman / app developer to manage their mining licenses for the apps they connect to the IoP.

    I leave this road-map up to here for now, although I know it continues. We are open to receive Contribution Contracts proposals on any of these projects that are already in the global strategy.

    Thanks to Amado Charlé for the editing.


    Luis Fernando Molina

  • Profile Server Road-map

    Currently we are alpha-releasing the Profile Server. It’s technical documentation can be find here.

    Here I present the list of features, security improvements and optimizations that can be done on the current implementation of the Profile Server. We open all these project ideas to the Fermat community to propose these features through our Contributions Governance System. The following list was taken from here. Meanwhile we will focus on the next server to design and implement: the Proximity Server.

    So I say it again: if you are a dev, dev team or dev company you can submit any of these projects to our Contributions Governance System and get paid in IoPs!

    Features Not Yet Implemented

    Some of the following features are going to be implemented, others will be considered.

    Network Simulator LOC Support

    The network simulator is a tool that allows developers to run multiple instances of the profile server on a single machine and create a testing network, in which various scenarios can be analyzed. Currently, the network simulator implements a dummy LOC server, which simulates a basic functionality of a LOC server. We need to improve the network simulator to support real LOC software, to help us testing LOC functionality within the simulator as well as the integration between the profile server and the LOC server.

    Multimachine Network Simulator Support

    Currently, the network simulator can only run on a single machine, which limits the size of the simulated network because of the simulator’s demands on hardware resources. It may be possible to extend the functionality of the network simulator to support execution on multiple machines, which would allow it to simulate large network environments on just a couple of testing servers.

    Profile Changes Notification

    Some end user IoP applications may be interested in being notified every time a certain profile is updated on its profile server. Currently, there is no system of offline messages, so it is expected that the notification could only be provided if the interested application has an open connection to the profile server that hosts the monitored profile. However, such an implementation could significantly increase the resources consumed by the profile server, if the number of watchers is high.

    Hosting Plans and Invoicing

    Currently, the profile server does not charge anything for its services and everyone is free to register and use it, unless the profile server hits its configured limits. A system of hosting plans is intended to limit the free use of the profile server by introducing various quotas on each functionality the profile server offers. It is expected that each profile server will offer a very limited free hosting plan that will allow new network users to join the network free of charge, as well as to offer paid plans for users that are able to provide monthly payments.

    Invoicing is the intended system of payment requests delivered to the clients to ask them to pay for the profile server services, to its wallet.

    Backup Node

    To prevent losing an access to the network when a client’s hosting profile server is not available, a system of backup nodes can be created. A backup node will contain up to date profile information about the client, but it will not be used until the client requests it due to problems with its primary hosting server. The backup node will then replace the role of the client’s hosting server until its primary server is available again. In case of permanent unavailability of the primary server, the client is expected to fully migrate to the backup server, or another profile server.

    Admin Interface

    A special interface for the administrator of the profile server should be implemented to allow easier management and change of profile server settings without a need to restart it, as well as to provide various statistics about the profile server’s operations and performances.

    Regression Test Mode

    Once the admin interface is ready, we can implement a regression test mode that will allow developers to create new kinds of tests of the profile server.


    DoS and Sybil Attack using Neighborhood Initialization Process

    Currently, there is no verification whether an incoming profile server that requests uploading its profile database is authorized to do so. Mitigation of this problem depends on design decisions to be made about the final definition of the server neighborhood.

    Regardless of the neighborhood design and definitions, there is also the possibility of spawning a large number of servers within a certain location. Mitigation of this should probably be done on LOC level with IP subnet based limitation.

    Also currently, there is no limit on a number of attempts for the Neighborhood Initialization Process if it fails. This allows the attacker to perform a DoS attack. To mitigate this issue, we can introduce IP based limits.

    DoS Attack Using Search Queries, Profile Updates, and Other Requests

    Currently, there is no limit on a number of search queries that a single identity can send to the profile server. Sending a search query is a cheap operation for the client compared to the amount of work that the server is potentially doing.

    Similarly, there are currently no limits on other requests such as profile updates.

    To mitigate this issue, we would need to introduce identity based or IP based limits on search queries and other requests.

    Sybil Attack on Profile Hosting Registration

    Currently, there is no limit on a number of profiles that a single IP address can register on the server. A single attacker can occupy all free slots the profile server has for hosting identities.

    To mitigate this issue, we would need to introduce IP based limits on hosting registrations.


    Updates Between Neighbors

    Neighbor servers share their profile databases and keep their information synchronized. The initial database upload to a neighbor is efficient, but individual updates that follow are somehow inefficient as we currently use a new TCP TLS connection to the target neighbor, verify our identity and send a single update of a single profile even if there are more updates to be done.

    As the number of neighbors is potentially high and the frequency of changes in the hosted profiles is low, reusing a connection does not seem to be a good option unless it is used by both peers. Such optimizations should not be done until the final design of the server neighborhood is decided because, it is currently uncertain whether any optimization is needed.

    Making batch updates instead of individual updates would save resources but it would potentially affect the UX as the profile search feature would greatly suffer.


    Luis Fernando Molina

  • IoP Wallets Roadmap

    User Experience is a critical aspect of our products and is directly tied to the success of the project. Bad user experience introduces adoption barriers that can have very serious implications on the rate of adoption of whatever we create.

    So far we have deployed only wallets. Very soon two mobile apps which are part of our governance system will be added to the list. In the case of wallets, we have two different target users:

    1. Wallet Users: This target audience in turn consists of two different sets of people:
    • Mobile Wallet Users: Usually very inexperienced users, in many cases not familiar with cryptocurrencies.
    • Desktop Wallet Users: We can assume that desktop wallet users are bigger token holders, and have more incentives to learn something complicated. This group is also divided into two groups: a) Investors with no to little idea of cryptocurrency, and b) Technical geeks with knowledge on cryptocurrencies.

    2. Miners: Our miners are not necessarily going to be technical guys. In fact we expect a wide range of people to be able to mine.

    So far, to mine you have to be a tech geek, because it involves installing the software, configuring it, and getting your public key activated for mining. This process in its current state, is at a minimum of user-friendliness. In the case of wallets, the perception for regular users is that this is very complicated, and that is a very strong entry barrier.

    We inherited many of these problems from the software we forked. But that doesn’t mean we should leave it there. This roadmap is intended to work towards very user-friendly software that can be used by a broader audience. There is quite a lot of work to be done on this topic. All the projects listed here are expected to be proposed as Contribution Contracts and approved by the community.

    The IoP Wallets Roadmap is the following :

    1. Mobile IoP Wallet UX: This includes two projects:

    a. Android Wallet UX re-design: This UX redesign must consider the newly planned functionality for the Android wallet version 2. This new version is about having the wallet connected to the IoP to follow the strategy described here. The new user interface should focus on being the easiest, most intuitive, people first user experience possible. This is a project that can be submitted as a Contribution Contract.

    b. Android Wallet v.2. Implementation: This project is about connecting the wallet to the IoP and enabling device to device communication for the exchange of crypto addresses. It also includes removing addresses from the user interface and searching for other users on the IoP with different criteria.

    c. iOS Wallet UX re-design: Same approach as for the Android wallet. This is a project that can be submitted as a Contribution Contract.

    d. iOS Wallet v.2. Implementation:Same approach as for the Android implementation.

    2. Desktop IoP Wallet UX re-design: In this case we need to add to the desktop wallet a user interface for three different types of users.

    a. Bitcoin / Cryptocurrency / Tech People: It is basically the same user interface that we have today, untouched. Only an initial screen is added that allows end users to choose the interface they want to use, and an option at the menu that allows end users to switch from one to the other. This is not a project per se, but something that is needed as part of the whole UX redesign work.

    b. Non Tech Wallet Users GUI / UX:This is a project to create a new user interface, as simple as possible, for non-technical users. This should only include the most basic functionality a wallet can have, and leave all the advanced features for the tech-mode.

    c. Non Tech Wallet Users Implementation: This is the equivalent project of 1.b, but with the desktop wallet.

    d. Non Tech Miners: This should be a one-button start mining interface. It should automate everything of what is done today to start mining, and include a super easy to understand monitoring screen with the very basic and most useful information. This is a project that can be submitted as a Contribution Contract.

    At the end of this roadmap we will enable a bigger user base to use our wallet and to mine our tokens, making the IoP more accessible to everyone.

    Thanks to Amadeo Charlé for the editing.

  • Use Case: Virtual World

    This is a wonderful use case for the Internet of People since it solves several problems at the same time and it showcases many of the possible uses of the infrastructure we have created.

    The context is the following: A virtual reality company has a product that allows their users to create 3D objects and assemble with them 3D spaces. Users can later immerse themselves into those spaces with their avatars, and interact there with other users. These interactions are mostly about chatting but not limited to that. Additionally to this, users can sell their 3D models / objects on an internal marketplace.

    The virtual reality engines run on the company’s servers and they have a client on every OS, including mobile and browsers. Client apps are mostly for visualizing the virtual environment.

    Then, which are problems this company might have?

    1. No Cash Out: They use an internal digital money with no possibility for end users to cash out. By being a global company, allowing end users to convert in-game digital money to fiat would put them on a difficult situation from a regulatory point of view.
    2. Weak Copyrights Industry Wide:The marketplace for digital objects and models is restricted to their own community. In this industry it’s common to see people buying models inside one system or community, exporting those models, and selling them on the open market or in other similar communities without the consent of the rights’ owners.
    3. Communication Requires Infrastructure that grows linearly with User Base: Communication between client apps for chatting requires company servers to relay the messages between clients. The same situation occurs when communicating position and events in general. This means that if for every 1,000 users 1 server is required for these purposes, then a 1,000,000 user base would require 1,000 servers.
    4. There is no connection with the real world: Users are trapped inside their virtual world. Everything that happens there has no connection whatsoever with real life.
    5. Limited Revenue Streams: The company would like to expand their business model beyond the fees they charge users for using their system or running the digital assets marketplace.

    The Internet of People has several components that can help this company solve those problems:

    1. No Cash Out: Replacing the internal digital money for a cryptocurrency make sense for this company. Cryptocurrencies can freely flow between internal users and when they need to cash out, there is already a global infrastructure that allows cryptocurrencies to be converted into fiat currencies by specialized regulated companies. This means that by using a cryptocurrency this company can focus its efforts and resources on the core of their business. IoP has its own cryptocurrency token, the IoP.
    2. Weak Copyrights Industry Wide:Digital assets recorded on a blockchain can solve the issue of ownership of 3D models. A company respecting the rights of authors can get into a competitive advantage over competitors, attracting the best talent to their platform. With time, the industry could adopt the standard and solve the industry-wide problem. Once in place, the marketplace of digital objects and models could be expanded industry wide.
    3. Communication Requires Infrastructure that grows linearly with User Base: If all clients are connected to the Internet of People, specifically to Profile Servers, then while a user is immersed in the virtual world, the client could be locating nearby users of the virtual world at the Internet of People. For every user located, the virtual reality client app can use the Profile Server to acquire a device to device connection to the PC of the other virtual user. Once the connection is established, there is no need for clients to use the company’s servers for relaying chat messages or events messages, like a change in position or others. The effect of this is that the system now decouples the growth of the user base, from the growth of the infrastructure needed. This means that with less servers the company can have more users resulting on a cost reduction and a competitive advantage in their market.
    4. There is no connection with the real world: The Internet of People will be populated by profiles of people uploaded by different apps. Chat apps will upload profiles of people who are able / willing to chat. One half of the Internet of People infrastructure are standardized protocols. These protocols allow for interoperability between apps of the same type. For instance two different chat apps can interoperate because they speak the same IoP Chat Protocol. The same is true for dating apps, taxi apps, in general for every type of app. The virtual reality company can take advantage of all this to expand their user experience allowing them to interact with people or services outside the virtual world. For instance, the company could run virtual bots and instead of running their speech functionality with AI, they could connect through the IoP to real people using chat apps, and by doing so allow their virtual users to interact with people outside the virtual world. Imagine a virtual space for online dating, where the people to be contacted by virtual visitors don’t even know they are inside a virtual world. Or imagine the avatar using its virtual smartphone to run a taxi app that requests a real taxi through the Internet of People. All this is possible since the only requirement is that the client app implements the IoP Chat Protocol, the IoP Dating Protocol, and the IoP Taxi Protocol. By learning that it can incorporate these use cases into the virtual world, since the profiles of chatters, daters and taxi drivers are publicly accessible at the IoP network in a permissionless way, it doesn’t matter which app is used to establish the contact with the profile owners, as long as this app correctly uses the protocol in each case, nobody knows or cares if the app is a normal chat, dating or taxi app, or if it is a virtual world client connecting virtual users to real life people and services. As the Internet of People grows in usage and diversity of profiles, updates to the virtual world client app can enable it now more IoP protocols and enable more types of interactions with the real world. Interesting enough is that the opposite route is also valid. If the virtual client defines at the profiles it uploads to profile servers that these users are virtual world users, but also they are available for chatting, it might receive chat communication requests from the real world, from people trying to contact them and they would chat inside the virtual environment, without the chat initiator even knowing or being aware of the situation.
    5. Limited Revenue Streams: Once the company connects its client software to the IoP, then a TCP/IP connection is kept open to the Profile Server where their user profiles are hosted. Through that connection they are exposed to receive different types of requests that could end up in new revenue streams for the company, and for their users. Let’s say for example McDonald’s would like to offer a new hamburger to young men between 15 and 21. McDonald’s with an IoP Marketing App scans the Internet of People and finds these Virtual World Users profiles. McDonald’s’ app (or a bot) enters through one of the open TCP/IP connections at a Profile Server and knocks at the door of the Virtual World client app. They negotiate using a common protocol for this purpose the cost of delivering this advertisement (the new hamburger) to this particular user, after receiving some $0.1 for disclosing the age of the user (personal info can now be sold with the consent of end users and the income going to them). They both agree that a banner is going to be displayed at a virtual park and the virtual user will see it for 10 seconds while he virtually walks there. McDonalds would pay $3 for this which the client app would split 50% for the company and 50% for the end user. McDonald’s sends the first $1.5 in advance, together with the ad’s high quality image and after 5 minutes the client app reports to the McDonald’s app that the user finally saw the banner, and provides some statistics collected, like the amount of time it was displayed on the screen and the virtual reaction of the end user. Finally McDonald’s’ app sends the last $1.5 and the bot leaves the client and continues navigating the IoP searching where to spend the next $3 of McDonald’s’ digital advertising budget. For the first time in the digital era McDonald’s dollars don’t end up in Google or Facebook, but on any entrepreneur creating IoP connected apps and their user base.

    Thanks to Amadeo Charlé for the editing


    Luis Fernando Molina

  • Networks Statistics Road-map

    The Location Based Network, Content Address Network and Profiles Servers have already been released on alpha. So far it is very difficult to collect statistics network wide, since there are no tools developed for this purpose. I can imagine a series of public sites run by different community members to keep track of these networks, collecting statistics and providing insights on their growth, the information that is stored there and many other facts. Also, by being able to visualize them, it will become easier to explain what they are and how they work.

    A Network Statistics Roadmap can include the following projects:

    1. Token Server Visualization and Statistics: A site like Bitnodes could do the work here. With these statistics about our blockchain we can do well for a while.
    2. Content Address Network Visualization and Statistics: A globe could visualize the nodes’ location based on their IP address. Other statistics might include: number of nodes, blocks/bytes stored per node. Up/down bandwidth used per node. Also partner Profile Servers should be discoverable. As in the previous case, statistics about software version, number of nodes and so on should all be recorded and later displayed over time.
    3. Location Based Network Visualization and Statistics: This is a beautiful opportunity to display on a map or a globe the nodes of this network and how neighborhood clusters are formed. Also each local map can be displayed separately with the bubbles that separate colleague nodes between each other. Taking it further, the Profile or Proximity servers that each node collaborates with could also be displayed.
    4. Profile Servers Visualization and Statistics: This site could show you Profile Servers on a map, and individual statistics of each one. Neighbourhood visualizations could also be added plus internal statistics collected by the servers. Another important statistic set is the available Application Services of each profile and information about end user devices connected to Profile Servers.
    5. Proximity Servers Visualization and Statistics: This site might show on a map proximity servers and their neighborhood clusters. Detailed information of each server could also be accessed through this site. A real time display on a map of all activity on a Proximity Server is a must for this site. Different icons might represent different profile types, and the site’s users should see them moving through the map as it happens. Routes should also be visible when available.
    6. Internet of People Social Graph Visualization and Statistics: This site will probably be the most interesting one. Information is collected from Profile Servers and the public social graph of all profiles and their relationships is displayed also in a geo-localized way. You should be able to see here profile clusters of the same end user, and their connections to other profiles of other people as well. It will be interesting to allow the site’s users to play with relationship filters, to discover patterns or other interesting information.

    This roadmap will be expanded as more Servers and Networks are implemented.

    Thanks to Amadeo Charlé for the editing.


    Luis Fernando Molina Inventor of the #InternetOfPeople, Founder of Fermat: A connected but decentralized human species.

  • Fermat Framework Road-map

    The Fermat Framework described in theFermat Whitepaper and located at thisGithub repository, is a client side infrastructure on which we spent a lot of resources experimenting and prototyping apps for more than a year. This work lead to the current Internet of People design and implementation. Now that our Content Address Network, Location Based Network and Profile Servers are deployed, we can connect the Framework to the IoP, resume the work on the apps we were prototyping, and finally release these apps to the public.

    This first set of apps will give us feedback on how to proceed with the evolution of this Framework. The projects involved in this roadmap are the following:

    1. Connecting the Fermat Framework to the IoP: This first project will enable the rest on the list. When this Framework was initially implemented we had a primitive version of a Profile Server. Now we need to upgrade the IoP client used by the Framework to deal with the new set of nodes and servers already alpha-released. The ideal developer to tackle this project is someone involved in the development of the Framework.
    2. Connecting the Fermat Framework to the IoP Token Server: By the time we developed this Framework, we were experimenting with the bitcoin blockchain. It is true that our blockchain is based on the bitcoin codebase, but anyway we need to upgrade the old components to point to our already deployed IoP blockchain. The project should also keep the components pointing to bitcoin, since we have also developed a bitcoin wallet and other apps using the bitcoin network. This project is required before the next set of projects in the list can be worked on.
    3. Wallet Projects: We had already developed three different pieces of wallet software. A bitcoin wallet, an IoP wallet and what we called an IoP Loss Protected Wallet. All these apps need to be upgraded to work with the new IoP Network already alpha-released. This project is required in order to enable the next set of projects on the list. These apps should be compiled as stand alone apps and not run inside a mother app hosting them. Ideally, developers involved in the original prototyping should be part of the team.
    4. Chat App: We had a working prototype of a chat app, based on Whatsapp, ready to be ported to the new version of the IoP network. This app should be integrated with the profile management app and compiled as a standalone app that can be individually downloaded from the Google Play Store. Any of the devs involved in this development can take on this project and put it to work.
    5. Digital Assets: We had already developed advanced digital assets management apps, covering digital asset issuing, distribution to users and redeeming. This project aims to resume mentioned work and implement it with our own blockchain and the different IoP networks. At least some of the original developers should be part of this team.
    6. Crypto Brokers: This project includes several apps similar to Local Bitcoins, however over a p2p network. This project is very important to advance the cryptocurrency movement since it enables anyone to locate brokers in their region that buy or sell crypto-currencies like bitcoin or IoP without running any centralized infrastructure. The project included an app for crypto brokers, allowing them to run the whole business of buying or selling cryptocurrency in their neighborhood. It also included an app for customers of these brokers, allowing them to find brokers, get a quotation from them, and finally executing the agreement. Including developers originally involved in this project in the team is a very good idea, since it would ease the learning curve to put this up to speed.

    We had more plans on apps to build with this Framework, but the logical thing to do is to put all this to work and release all the apps we were experimenting with. Once we are there, and a user base is growing for these apps, we can think about how to resume the other projects on this pipeline.

    Thanks to Amadeo Charlé for the editing.


    Luis Fernando Molina

    Inventor of the #InternetOfPeople, Founder of Fermat: A connected but decentralized human species. ~ We know the future because we are going to build it. ~

  • Introducing the Graphchain

    The Internet of People uses a new type of cryptographically secured data structure called the graphchain. The main difference between a graphchain and a blockchain is that the first acts as a cryptographically secured data structure, in which no blocks or transactions have to be stored.

    At the graphchain the information to be stored concerns either nodes or edges of a graph. The difference with a regular graph is that nodes are identified by a public key and its information is controlled by the corresponding private key holder. Edges represent relationships between the entities controlling nodes and some of these relationships can only be added to the graphchain if they are signed by the private keys of both connected nodes.

    At a graphchain nodes are fully owned by their private key holders and the information stored can only be changed by signing with the respective private key. Edges are co-owned by the entities holding the private keys of the connected nodes. The possible actions they can individually perform on information at the edges is constrained by the relationship type and conditions agreed upon when the relationship was established. In some cases either of the parties might be able to cancel the relationship or change some of its properties. In most relationship types the control resides on the predecessornode.

    The Internet of People’s implementation of a graphchain distributes the data structure across two different sets of computers or hardware devices in general. All nodes and public edges belong to the first group: a set of devices running on top of an open and public p2p network. All private edges are stored at the devices of the entities holding the private keys of the predecessor node. This means that one part of the graph is publicly accessible by anyone and the other part is not. The private part of the graph is fragmented into different devices owned by different entities and external parties can learn about it only with the consent of the owner of that private part of the graph or when the owner privately exposes these relationships to a third party with the purpose of declaring a relationship.

    These two sets of edges, the private and public ones are linked together because the Internet of People allows end user devices to keep an open connection to the public network. Anyone with access to the public network can locate a device associated with a graph node and use that open connection to learn more about that piece of the private part of the graph, if granted permission by its owner.

    The Internet of People’s usage of a graphchain is with the purpose of creating a secure, open and publicly accessible social graph that is user owned and controlled. The end result would be like combining Facebook, Twitter, LinkedIn, Google, and all user databases of all tech giant companies together and expose them publicly on a blockchain-like p2p-network that anyone can use to consume information and create software in a permissionless way. The most important difference with such a combined user database is that end users own and control both their information and their relationships with others across all type of applications.

    Different apps running at end user devices control different sets of private and public edges and nodes on behalf of end users. This means that a single end user can have multiple nodes on the graph and any amount of private and public edges. All of this is enabled just by using IoP apps for different types of social or business interactions.

    Thanks to Amadeo Charlé for the editing.


    Luis Fernando Molina

  • The blockchain/crypto community needs a cartoon mascot . Say hello to IoP Bear!

    Promoting the magic of decentralization to the masses in a fun way!

    Since 2009 when the epic blockchain revolution took off, a few insiders cheered, a few skeptics grumbled and the rest of the masses said “huh?” Now Fermat (fermat.org) has come along with a mandate to transform those “huhs?” into “hoorays!!” by placing workable blockchain based apps in the hands of the masses. And a cartoon bear is going to assist them! Who is this bear with his magical hat of decentralization, his walking cane of privacy and a snide remark for money grabbing middlemen? First a little more about the company he works for.

    The genius of Fermat is that only minimal required knowledge about what the heck a blockchain is or how it works will be needed after we unleash our full suite of location based, privacy focused and p2p commerce utilizing apps. Yes Fermat employs its own token called iopcoin, which is used to grease the wheels of the emerging Internet of People system. But Fermat is not about competition. Any crypto token will be able to ride this system’s digital rails to the glorious destination of freedom. The Internet of People is for everyone everywhere and is being created to bring various crypto communities together. And it is in that spirit that Fermat New York chapter is introducing what we feel is the next step in getting blockchain tech mainstreamed: the concept of FUN!

    Introducing IoP Bear, the mascot for the Internet of People and the international cartoon “spokesbear” for the blockchain revolution. IoP Bear will be presented in many different forms, from posters to comic strips to animation. He will be present at regular crypto and blockchain events, but will also be spreading the word at mainstream festivals, comic book conventions and children’s events. IoP Bear will boldly take the blockchain industry where it has never gone before — to the masses! More soon about IoP Bear and his future endeavors to promote iopcoin, Bitcoin, ethereum, Dash and other great crypto tokens, while introducing the world to the digital highway that can transport them all — the Internet of People. Welcome to the era of whimsical adventure and fun in crypto everybody! Say hello to IoP Bear!

    to donate for the production of IoP Bear comics, animation and educational outreach:


    ethereum: 0x8ab9c6120e457cc55c5ad5c44b53d130fd1c747e

    iopcoin: pL1zv57ZjoxQeCTu7PcPgjQh6DxtCZAcaF

  • IoP Contributors Tutorial

    Alpha Version of the Contributors App tutorial. Honestly I believe there is a lot of room for improvement on the app’s UX. Anyway, here are my two cents on how to create your first Contribution Contract.

    This step by step tutorial will help you submit a Contribution Contract into the IoP Governance System. First of all you need an Android device and with it download the IoP Contributors App from the Play Store:

    Once located, press the Install button to Install the App.

    After installation is completed, use the Open button to run it.

    You might notice that the internal IoP wallet of the app will synchronize itself with the IoP blockchain.

    Choose the Signup link at the bottom of the screen to create a new
    username and password. This username enables you to access the web forum
    where the discussion happens. If you already have a username in the
    forum, you can use it here without signing up.

    After creating your username, login at the initial screen to enter the app.

    The first time you use the app, you will see these following help screens that will guide you through the process of creating your Contribution Contract.

    The first step is to backup your wallet, so that if you lose your device you still can have access to the funds.

    The second step is to top-up your wallets with IoPs.

    Then you can go ahead and create your Contribution Contract.

    After that, you post the contract to the forum. This means that the app
    will create an automated post on your name at the forum which will kick
    off a discussion of what you are proposing to do.

    The community will see your proposal and start a discussion. You defend
    your proposal there until you feel there is enough consensus to approve
    your Contribution Contract.

    The next step is to submit your contract to the blockchain. This will
    formally enter the contract into the system and it will allow the
    community to vote for it. A second automated post at the forum is
    created at this moment

    If your Contributor Contract is approved by the community using the
    voting app, you will start receiving IoPs every block during the period
    of time you specified.

    Once in, you will see the home screen of the App. It is where you manage your Contribution Contracts.

    Remember, the first thing to do is to make a backup of your internal wallet. Go to the Internal Wallet using the left menu, and on the top right menu select backup wallet. Choose a good password and proceed. This will create a file stored on your phone, usually at the external memory. Be sure to copy this file to your computer and later to a pen drive where you can keep it safe.

    Then you need to go to the Internal Wallet of the side Menu and touch
    the QR Code, to later share an address. Send the address to yourself for
    whatever means and use it to send 2 IoPs to the Contributors app.
    Immediately after you do that, you will see at the notification bar that
    the app recognizes the IoPs sent.

    At the main screen of the Internal Wallet, you should see 2.00 IoPs
    available as soon as the transaction was confirmed at the blockchain.

    Now that you are sure that everything is working smoothly it is time to
    send 1,000 IoPs that are going to be used as a deposit backing up your
    Contribution Contract.

    You might see that the 1,000 IoPs initially are unspendable, but after a
    few confirmations at the blockchain they will become available.

    Once you see the 1,002 IoPs are available, you are ready to go to the next step.

    Go back to the home screen of the app, and touch the icon in the middle
    to create your first Contribution Contract. At the first screen you will
    fill all the fields as in the example below.

    Press next when done and at the second screen you have to fill the details of the Contract. There are three periods of time a Contract goes through:

    1. The Voting Period: Starts when you submit the Contract to the blockchain and ends after a number of blocks you choose, or a number of week you can also choose. The minimum amount of blocks is 8,000 which today equals to one week approximately. During this period, the community will vote yes or no and at the end of it you will know the fate of your Contract.
    2. The Vetting Period: Starts when the Voting Period ends and is a fixed period of 8,000 blocks (one week approx.). During this period your CC can be vetted by No votes.
    3. The Execution Period: During this period, if your CC ended the Vetting Period holding more Yes votes than No votes, the blockchain will start paying you at every block the amount of IoPs also defined by you.

    The following screen has two versions, one for experts (not your case) and the second one for beginners called automatic mode. Choose the second one and you will see a screen similar to the one below.

    Fill it with the total amount of IoPs you will like to receive through the complete execution of your CC. The app internally will calculate the IoPs per block, starting block and the amount of blocks needed to complete that payment.

    You might want to leave the defaults calculated by the app on the rest of the fields.

    You don’t need to change anything at the next screen unless you want to add additional beneficiaries for the payments. If so, use the Add Beneficiary button to set more IoP addresses and the amount per block to send to this additional address.

    If untouched, the app will record the internal wallet address as the address to which the blockchain is going to send the IoPs.

    Ok you are almost done. A confirmation screen is reached and the next
    step is to submit the CC to the forum for discussion. Use the provided
    button for that and go and engage in discussing the details with the
    community. Usually you would use the app to create the contract and
    later you would go to the forum and detail all the specifics of your
    contract in new posts. It is recommended that you provide a roadmap with
    deliverables and milestones. If deliverables are digital documents, you
    might want to place the links to them later in new posts so that the
    community can follow up your work at anytime.

    When you are comfortable that your CC has enough support (it has to be voted at least 5 times and Yes votes must be greater than No votes), you can come back to check your CC and press the Submit Contract button to send it to the blockchain. This will initiate the process and start the voting period.

    The cost of submitting a CC is 1 IoP + the regular mining fees. The 1,000 IoP are then locked inside the internal wallet and can not be used until the CC execution is over or the CC is terminated by No votes for example. It is important to note that these 1,000 IoPs never leave the Internal Wallet of the app, so you can not lose them even if your contract is not accepted. What you lose is the 1 IoP paid on fees and the mining fees.

    Once submitted you can track at anytime the status of the voting on your CC coming back to the home screen.

    At the forum, accessed at the menu under Community Discussion you should be able to see all CCs being discussed plus yours.

    The app will include in its post detailed information of the CC like for example the length of the voting period and others.

    You will also find in the same discussion thread the automated post that happens once you submit the CC to the blockchain. Unfortunately the integration between the app and the forum is not perfect yet and the forum still requests you to login again if you want to write new post within the app.

    Thanks to Amadeo Charlé for the editing.


    Luis Fernando Molina

  • Contribution Contracts

    The concept of Contribution Contracts belongs to our Contributions Governance System. The purpose of the system is to allow the community to propose projects and vote for them.

    By definition a Contribution Contract or CC is an agreement between a team or individual and the Fermat project represented by its community. Fermat needs to develop into a global infrastructure. It was bootstrapped by its founders and early contributors until the point where the project can have a new degree of autonomy. Fermat is running an economic model through its blockchain system, where 21M IoP tokens are going to be issued over the course of around 80 years. These are the main resources of the project to finance its expansion.

    We already know that half of those IoPs are going to be mined and the other half are going to be distributed to the community through Contribution Contracts. This means that there is a huge opportunity to become a stakeholder of Fermat by being compensated for a project, while adding value to the Fermat ecosystem .

    The project is currently transitioning from the bootstrapping phase into the autonomous phase. In these very early days of the autonomous phase, Fermat mostly trusts people who are invested in its tokens and assumes that the more invested they are, the more their personal interests are in line with the vision of the project. For proposing CCs people thus need to be invested and hold at least 1,000 IoPs which act as a deposit through the whole lifecycle of the CC. 1,000 is an initial number balancing the need to be invested while not excluding enthusiasts with good ideas. The deposit amount of 1,000 is set as the initial value and will decrease over time , since the IoP token price will raise with demand and 1,000 IoPs could be of substantial value one day. We as a community should research how this number should evolve after we will have collected feedback over the next months and derive a formula that can survive over time. Besides that proof of stake, a fee of 1 IoP is required for each CC submitted to the governance system. This should prevent spamming the system.

    Contribution Contracts need to be voted by the community in order to be accepted by the governance system. The only possible votes are YES or NO. It is expected that the community members debate the CC and finally issue their votes. Currently the most invested community members are the most trusted ones for proposing a CC. Later the Contribution Governance System will evolve to include reputation of the participants and will consider their voting history and outcomes of projects. But we are not there yet, so as of today, to vote it is required to be an IoP token holder.

    As some early contributors including myself are holding substantial amounts of IoP tokens, we need a way to protect minor investors against self-approved CCs. Bearing this in mind, several measures have been implemented:

    1. NO votes are cheaper than YES votes: To issue 100 NO votes you need a deposit of 20 IoPs, while to issue 100 YES votes you need to deposit 100 IoPs.
    2. Vetting Period: After the voting period of a CC, there is a fixed-time vetting period where only NO votes can be issued.
    3. Voting Fees: Each vote cast carries a fee of 1% of the tokens used to vote. This is a strong disincentive to use excessive voting power for subjects that don’t really require them or as a way to avoid an open discussion or democratic participation. These fees are turned into mining fees and collected by miners.

    Approved CCs are paid directly by the blockchain during the CC execution period. In other words, every time a new block is mined, 1 token issued by the blockchain is allocated to one of the miners, and 0 to 1 IoP is given to the beneficiaries of currently executing CCs.


    Deposits serve as a proof of stake of the community members, entitling them to participate in this process. Deposits are checked at every block during the whole life cycle of CCs. If the system detects that deposits have been withdrawn (IoP spent), then it will consider either the CC canceled (if it was a deposit of a contract) or the vote canceled (if it was a deposit of a vote).

    A canceled contribution contract will halt any further payments to their beneficiaries and the system considers this a final state. A canceled vote might or might not impact the outcome of payments. Canceled YES votes might result in less YES than NO votes for that contract and in this situation the CC is canceled and payments halted.


    Voting is pseudonymous. This means that a single person could vote the same CC more than once if he creates the right setup running the voting app with different accounts. In these early days we can deal with that since the size of the community is not too big. It might also continue like this later, depending on feedback collected during the first months. It is important to note that we are deep inside uncharted territory with this type of governance.

    CC Life Cycle

    CCs go through these four phases:

    1. Draft: Once you create a CC,a new post on the community forum is posted. The CC still has not entered the system yet. At this stage the CC is considered a draft. You will notice that the Contribution App requires the deposit even to create a draft. This prevents spam by individuals that don’t really have the means to propose a contract. During this phase the project is debated by the community using the forum. The submitter can defend this position and answer questions, present more material, detail milestones and deliverables and receive feedback. After he feels comfortable that his project is going to be accepted he can submit the CC to the governance system thereby entering the next phase. If the feedback he is receiving is mostly negative and he has reason to believe that his proposal might be declined, he should better forget about this contract and cancel it. He might cancel it in order to lower the amount of IoP tokens requested in case that was a factor for disapproval of his project. All contracts and their voting history are recorded on the immutable database called blockchain and this data will later become the reputation of the different entities participating: contract owners and voters. This implies that it is very important to keep a good track record or else this will damage one’s reputation.
    2. Voting Period: This period starts when the contract is submitted to the governance system, a.k.a the blockchain. The contract owner defines the duration of the voting period, although there is a minimum of around a week. YES or NO votes can be cast during this period. A necessary condition for a CC to be considered active for the next phase is that the sum of YES votes must be greater than the sum of NO votes and there must be at least 5 different blockchain transactions with YES votes, each one with a minimum of 100 votes. If all these conditions are met by the end of the voting period, the CC advances to the next phase.
    3. Vetting Period: During this phase only NO votes can be cast. NO votes also have a minimum of 100 per blockchain transaction. If during this period NO votes are equal or greater than YES votes, the CC is cancelled. If not, it enters the next phase. The Vetting Period is a fixed amount of time of around one week.
    4. Execution Period: This is the phase where CCs are paid by the blockchain. In the CC its owner must define how many IoPs he demands to be paid for every mined block. The amount can not exceed 0.1 IoPs, since there is only 1 IoP per block to pay all CCs, so a single contract shouldn’t take it all. This initial arbitrary value of 0.1 IoP means that there is room for 10 CCs to be paid in parallel if all of them demand the maximum payout. As the token market price increases over time, this number should be adjusted and lowered below 0.1, so that the system can pay for more CCs in parallel. If for any reason there is no room for more approved CCs contracts and the system is already spending the 1 IoP assigned for this, then CCs are placed on an execution queue and they will wait for room to enter into payment mode. All this happens automatically and there is no way someone could prioritize one contract over others. Approved CCs are paid on a first arrived first served bases, that means that it is important to go through the process in a timely manner to avoid payment delays.

    Bad Projects

    If a CCs is executing and being paid and the beneficiary team is not delivering their promises, then people that voted YES for that project can remove their votes at anytime just by withdrawing the deposit. This is the last resource mechanism that allows the ones that participated in the discussion and further voting period to cancel a bad project. YES votes can not be equal or less to NO votes. Also YES votes can not drop below 50% of the original YES votes the CC was approved with. Any of these two conditions will cancel CC and payments are halted.

    Transition CCs

    There are several agreements that individuals or teams have made with me, representing the project since January. All these people are waiting for the governance system to formalize their CCs and start getting paid. The system has no special rules to deal with this situation, so their CCs are going to be submitted like everyone else’s CCs. In these exceptional cases there will be little to no discussion in the forum, since the agreement was already closed and they are already working. All new contracts are expected to be heavily discussed and debated by the broader community. Once these transition phase CCs are posted, I will post a note on the forum thread referring to this section of this post, in order to clearly mark which CCs belong to the transition period.

    One extra difficulty we have to overcome is that many of these CCs exceed a system limit of 120,000 blocks maximum for contract execution. This means that most of these transition CCs need to be split into several CCs to accommodate the amount of IoPs already agreed considering the maximum 0.1 IoPs per block per contract. These CCs are going to be queued one after the other in order to avoid occupying the whole buffer of 10 CCs with 0.1 reward each and keep a free space for new CCs.

    In most of these cases I advanced from my own funds the IoPs of queued Transition CCs because the agreement with beneficiaries was not to receive them so far in time. This means that in order to get my funds back some of these queued Transition CCs will be posted by me instead of the beneficiaries and voted by the beneficiaries agreeing that the system should give the tokens to me to recover my funds.


    There are some more minor details and for sure a lot of room for improvement. It is up to the whole community to improve the system and find possible vulnerabilities. We should all consider this a groundbreaking social / technical endeavor and see how we make it work.

    Thanks to Amado Charlé for the editing.



  • The IOP Marketing Roadmap

    The purpose of this post is to inform members of the Internet of People (IOP)community about the evolution of the marketing efforts for the project.

    The IOP Marketing Challenge

    For some, it may be love at first sight. For others, it may be like a painting by Picasso, Mondrian, or Dali and take a while to appreciate.

    But one thing is common among everyone working on the Fermat Project. There is a passion for it and a belief of how it can make the world a better place.

    The challenge for us is how do we help more people understand the vision and potential that the project represents, while doing it in a way that makes sense to them and (relatively quickly) inspires their passion and ignites their desire to participate in some way?

    That, my friends, is a Marketing (note capital “M”) challenge.

    Marketing, at its core, isn’t about BS stuff like emails, ads, or trade shows. Or even the website.

    It’s about, as legendary management consultant Peter Drucker would say, “knowing the customer so well that the product or service sells itself.”

    Now, a caveat.

    When I say “customer,” I don’t mean “someone who buys something with money.” I mean someone who “buys” the idea of Fermat/IOP and “pays” in some form.

    It could be money..as an investor or an IOP token holder/speculator.

    It could be a developer, an entrepreneur who chooses IOP for his/her business. It could be a chapter member who devotes time, energy, and resources.

    We all choose to what we should pay attention and what we should ignore.

    In a world of billions and billions of channels and a TON of noise, we have to

    1. get and earn the attention of the people who should know about IOP
    2. Convince them that IOP is worth their “investment” (of whatever)
    3. Inspire them to act and help us grow

    These are marketing objectives of Awareness, Perceptions, and Demand Generation and whether you are selling the IOP, an iPhone, or Trump/Brexit/Clinton/Marine LePen, the fundamentals are the same.

    What is different are the specific Objectives, Goals, Strategies, and Tactics (OGST) that will help us achieve Luis’ (and all of our) visions.

    Whatever we do, it needs to take into the account our strengths (we should leverage them), our weaknesses (we should defend against them) and our competitors (however our ‘audience’ of investors, entrepreneurs, community members, etc.) define them.

    This is the process that Luis has initiated and which I am orchestrating with contributions from people like Tom, David, Emma, Bences, Daniel, Adam, Ricardo, Julian, Markus, and Sarah.

    Here’s where we are and where (I think) we will be heading.

    Phase 1: Brand Platform and Messaging

    We have been working over the past month or so to answer a few questions in as clear and concise way as possible.

    We don’t want to (nor can we) dictate people how to talk or think, but we hope to provide a seed of common inspiration that informs how each of us describe the purpose and approach of the project.

    Our first step was to “Start With Why.” Watch this video for more background (it’s great), but what we are trying to do here is answer the questions of:

    1. Why does Fermat/IOP need to exist?
    2. HOW do we help people? (what are our guidelines)
    3. Finally, WHAT do we specifically offer?

    This is the very foundation of the “brand,” but not in a corporate sense. A ‘brand’ represents a promise to the world of what we are about.

    A warning: This process is not simple. It can take a long time. I’ve been through experience that take up to 10 months until we get it right. It’s kind of like having a baby.

    So, why do we need to exist?

    The goal is to fill in this blank…Everything we do is because we believe ______.

    Two working options include:

    1. Everything the Fermat Project does is because we believe in a future where people are more important than machines, companies, or nation-states.
    2. Everything the Fermat Project does is because we believe direct relationships between people are an individual’s most valuable asset.

    We’re close, but we’re not quite there. Feel free to chime in.

    Then, HOW do we do it?

    Everything we build is specifically designed to help people in these ways:

    1. Cut out any unnecessary middlemen and enable a person-to-person economy
    2. Increase trust in others
    3. Provide the right incentives for behavior

    I feel pretty good about this one. Notice how we don’t talk about technology though. That’s important as this isn’t about tech. It’s about people and helping them.

    Finally, what do we offer?

    Now, I know we all know how incredibly innovative the vision is. But my experience suggests that it’s not a good idea to go with radical innovation as the big idea. Why? Because most people aren’t ready for it.

    They need a “same, but different” reference.

    As humans, we have to put things in a box in order to begin understanding. Then, we’re open to a new approach. Without the reference point, we’re lost.

    “Uber for doctors”

    “Star Wars, but underground”

    “Lady Gaga, but with a violin”

    You get the idea.

    So, we have to find the right “same” so we can talk to different.

    So do we offer an “infrastructure,” an “infrastructure as a service,” a “social network,” a “development platform”?

    We know what the BIG differences are though…

    1. Open social graph
    2. A direct access channel to people
    3. Direct device to device communication

    Then, we can put all of that together into an overarching Value Proposition that looks something like this….

    For digital businesses looking to cost-effectively scale globally, the Internet of People offers the world’s only infrastructure (as a service) with an open social graph, direct access channel to people and direct device to device communication.

    Again, these are all works in progress, but hopefully you see where we are going.

    Once we have that, we start to build out the Messaging Platform (access required) that will outline the 3 (maximum) “pillars” that represent the core concepts we want to get across.

    The goal here is to answer the question of “Why should I care?” in a way thatfeels similar regardless of which member of the Project is talking/writing/communicating about it.

    Right now, we have 4 and we have to figure out where to edit.

    The reason we need to simplify is, well, that’s what will increase the odds of others understanding our vision and potential and wanting to get involved.

    As a small project with limited opportunities to make an impression and develop a perception, we want people to hear us echoing a similar story/ideas so that THEY start evangelizing it on our behalf (what you might call the ‘force multiplier’). We can’t afford to waste the opportunities.

    This stuff isn’t easy. It’s really, really hard and takes many iterations. It’s like building a product. We have to beta test over and over again until it looks, sounds, and feels right.

    Once we get to a pretty good point (‘don’t let the perfect be the enemy of the good”), we can start really focusing on the marketing plan.

    I’ll cover that in a future post, but it will basically cover these four things

    What are our marketing objectives?

    1. Awareness: who needs to know about us?
    2. Perception: what (ideally) do we want people to think about us?
    3. Demand generation: what type of activity do we want to inspire?


    How will me KNOW (metrics) that we accomplished each of the objectives?


    How will we leverage our strengths, defend our weaknesses, and position ourselves against competitors so that we can achieve the objectives?


    What specifically will we do, when, and with what measurement?

    To make it real…

    Let’s say your objective is to be “in better shape by 2018”

    Your goals may be to lose 5 kilos, stop smoking, and sleep 7 hours per night

    Your strategies may be to find a friend to go to the gym with you, have a program run that kills your computer and TV power at 2200 each night, and promise your mom that you’ll quit (or whatever).

    Tactics could be a weekly appointment, a time-based program that Luis has the password to, etc.

    Anyway, hopefully this is a satisfactory introduction to the marketing roadmap. We’ll cover more in a future post, as I said, but because our vision is SO big and world-changing, we have to be deliberate about what we talk about, when, and to whom so that we can build the momentum and movement (a key thing for us) to accelerate growth.

    Phase 2 is the beta Marketing plan where we test and learn against our hypothesis. In that phase, we’ll explain what contributions we need so the most talented and passionate people around the world can help us grow. (For more on contribution contracts, see Luis Fernando Molina’s post here)

    Phase 3 will be the a bigger rollout (though with plenty of testing and learning) as well.

    I suspect each phase will take 2–4 months, just being realistic, though we are doing a lot concurrently, because you can never stop marketing!

    With the help of so many people, I am sure we can build, test, fail, learn, and iterate quickly.

    Thank you for allowing me to be part of the journey with you.


    Jeremy Epstein

    CEO of Never Stop Marketing; Executive Director- Decentralized Marketing Network; Mktg team member @ OB1/OpenBazaar & Fermat/IOP

  • Introducing Redtooth

    It is like Bluetooth but with a global range enabling the pairing of devices over the internet.

    Redtooth is the name of our client-side technology that we are starting to build these days. This is the technology that runs on end user devices and facilitates device-to-device connections. It uses the several services of the IoP including the Profile Servers, STUN and TURN servers, LOC and CAN networks, etc. It is essentially an IoP client library that helps IoP connected apps to manage all the low level protocols needed to interact with these services, exposing to apps an easy to use API, locally inside the end user device.

    How is Redtooth similar to Bluetooth?

    • Connect two devices: Both technologies are used for the same purpose of connecting any two devices.
    • No middlemen: Once connected there are no middlemen. Nobody knows that two devices are connected via Bluetooth. The same is true for Redtooth.
    • Multi use case: Different types of apps can use Bluetooth for different purposes. The same holds for Redtooth.
    • Underlying physical layer: Bluetooth uses radio frequency. Redtooth relays information over the Internet. It uses the Internet of People to locate the remote device and establish a direct connection.
    • Pairing concept: People are already aware that there is a procedure to pair to Bluetooth devices, and once paired, the devices remember each other. They also know that one device might require an end user authorization in order to get paired with another device. On Redtooth we keep these same concepts.

    What are the differences between both technologies?

    • Standard: Bluetooth is a widely adopted standard that is usually included at the operating system level. Redtooth was born today and it needs to be packaged as a service to be downloaded and installed, in order to be later used by apps. In the case of mobile, we expect Redtooth to have a similar user interface and accessibility to Bluetooth.
    • Single / Multi Connection: Bluetooth allows one device to be connected to only a single other device. Redtooth on the contrary, allows one device to be simultaneously connected to many different devices.

    What is inside the Redtooth Library?

    If you could look inside, you would find a Token Server client (IoP SPV Wallet), a CAN NET client, a LOC NET client, and a PRO SRV client. You would also find a module to handle all paired devices and a few more things. Every time we release a new IoP Server or Network Component, an upgrade to this library is needed and a client module for this component is added.

    Who uses Redtooth?

    Redtooth is rarely used directly by apps except for low level apps like the IoP Explorer. Instead, Redtooth is used by another library called IoP App Services. This library has a component for every possible use case IoP connected apps. This component encapsulates the IoP Message Protocol for that particular use case.

    Let’s say for instance that a chat app wants to communicate with a remote chat app. The local chat app goes to the IoP App Services and makes a requests to access the IoP Chat App Service. It proceeds to request an App Service Call to the remote chat app. This service uses Redtooth, which in turn establishes a device to device connection. Redtooth on the local device connects to Redtooth on the remote device. Once the connection is established, inside the IoP App Services library, the IoP Chat App Service gets connected to the remote IoP Chat App Service.

    From the Chat App point of view, it is connected to the local IoP Chat App Service and everything else is transparent. From the IoP Chat App Service, it has a local reference to an object representing the remote IoP Chat App Service, and it just needs to execute methods on that object and that is all it knows. This object is passing these messages to the IoP App Service library which in turn redirects the message to the local Redtooth library, which has an open TCP/IP connection to the remote Redtooth library.


    Redtooth is our low level infrastructure running on end user devices. On top of it the IoP App Services implement the different IoP protocols allowing App Service calls. Finally apps use App Services transparently without knowing the underlying details.

    Thanks to Amadeo Charlé for the editing.

    This is a technical post covering some technical aspects of the Internet of People. If you are interested in finding similar technical posts on the same subject, this list might help you:

    1. Introducing the Graphchain. The cryptographically secured data structure we use to store profiles and their relationships.
    2. “Fermat, the Internet of People and the Person to Person Economy.” The Internet of People architecture dissected.
    3. The Profile Server. The cornerstone software of the Internet of people.
    4. The Location Based Network. The geo-located network that help other services to be geo-located.

  • IoP Full Nodes

    Full Nodes are a set of components of the Internet of People
    infrastructure packaged together and run by the Fermat community.

    As of today, an IoP Full Node contains 4 components:

    1. IoP Token Server (IoP Core): The software that processes IoP token transactions and stores them on a blockchain. It also runs our governance system that processes Contribution Contracts.
    2. Profile Server (PRO SRV): The software that hosts the IoP open social graph and stores it on a graphchain.
    3. Location Based Network Node (LOC NET): The software that creates a p2p network of nodes based on their geolocation. It allows other services to be geolocalized.
    4. Content Address Network Node: (CAN NET): This software creates a p2p network of nodes that manages an index of information managed by other IoP servers. Initially it manages an index of Profiles.

    The list of components will eventually grow as we release more of them. In the short term / middle term we should be including:

    • Proximity Server (PXY SRV): This software allows people to share their location and allows other people to find them.
    • Reputation Server: This component manages people’s reputation within the system.
    • Stun & Turn Server: These servers enable device to device connections.

    Until now, we have chapters running only the IoP Token Server in order to mine IoPs. Since we’ve released the other 3 components a few weeks ago the IoP Full node containing all the components is being installed. It is important for the project that every chapter runs an IoP Full node. By doing so we will be able to test the other 3 components on a large scale. There are features that can only be tested once we have more than 100 IoP Full nodes, such as the clustering of nodes into neighborhoods.

    Also, deploying more than a 100 nodes makes us hit a nice milestone and our infrastructure start to be considered by entrepreneurs for connecting their apps to it. Running a full node today will not cause an overhead to your computer as mining do. Most of the time these components will sit idle doing nothing until the day the first apps get connected.

    Later in the future, mining licenses will be active only if a full node with a good reputation is running. You can refer to these plans in the IoP whitepaper. In the meantime we will check this manually. So be sure to install a full IoP Node on the computer or server that you are using for mining. The project doesn’t need chapters mining without running the whole infrastructure provided by the IoP Full Node. The whole mining scheme is designed exactly for this, as an incentive to run the decentralized infrastructure. So let’s go and install 200 IoP full nodes and show app devs that we are ready for the show!

    Thanks to Amadeo Charlé for the editing.


    Luis Fernando Molina

Looks like your connection to Cryptocentral was lost, please wait while we try to reconnect.