Skip to content

ConsenSys-Academy/Machu-Picchu

 
 

Repository files navigation

Machu-Picchu

Vu Tien's github stats stats tool courtesy Anurag Hazra

Top Langs

General presentation. The ConsenSys Bootcamp 2020 Final Project of Vu Tien Khang is here.

Why Machu Picchu?

Machu Picchu is the beginning of a collaborative open source initiative. It aims to use the Ethereum blockchain to share “Data as a Public Service” among all the humanitarian organisations that provide support and benefits to the persons-in-need. These persons remain owners of their data and receive a micro-fee from every entity that retrieves this data. Like when you give your data to the GAFA to obtain map guidance, news, entertainment suggestions, taxi services etc. But here the data are accessible to all, including startups. The business model is explained here in Medium.

The need to share data among humanitarians is recognized. The addressable market is huge: Cash and Voucher Assistance programs alone totalled $5.6bn in 2019, quote the joint Danish Red Cross/Mercy Corp/HiveOnLine report of November 2020. And wait, there are more aid and relief programs than that: risk sharing, credit rating, gender equality, health practices, education, mother and child care, civil governance etc.

In my Final Project of the ConsenSys bootcamp, I'll initiate Machu Picchu with Pepito, a simple dApp. It will take form of a game where users are able to build a character with components of its face: hair, eyes, nose, mouth, clothes, accessories). Then the user will record it on the blockchain where all other users may see. Here is the Medium description. It's a gamification of a person-in-need's real life record, targeted at helping the staff members of humanitarians demystify blockchain away from cryptos, dark nets and speculations. Target look. Credits: the React library of Fang Pen Lin

After the bootcamp, I'll make it grow in complexity and in useability by adding IPFS and OrbitDB or textile. It will be the theme of my participation in future hackathons. The project is open source and collaborative. Let's make it happen together. Spread the word.

OrbitDB is a Document Database, like MongoDB, instead of being a Relation Database, like MySQL. Document Database is suited for our purpose because we need no complex relation tables. The database contains JSON objects describing a person in need and his/her virtual personal secretary (actually a wallet and various data that can be used to optimise social relief programs). The final purpose is to make this tool and its data available as open source to all international organisations providing benefits to disinherited people: refugees, microfinance customers and in general all beneficiairies of aids etc.

why this name Machu Picchu?

  • Remember how centralised was the Inca empire? -- it was very centralised
  • Remember what happened to it? conquered by only 168 men, one cannon, and 27 horses

Advantages of Machu Picchu

  1. This will make "Data as a Public Service". Data collected by any social relief organisation are available and usable by others. Having the data on blockchain makes it trustable, open to the public and at the same time allows each person in need to remain owner of his/her personal data, taking advantage of IPFS and of the virtual personal secretary.
  2. Using blockchain tokens allows "Cash & Voucher Assistance" programs --USD 5.6 Bn in 2019-- to do micro-payments in full trust and reduced risk of corruption and theft, while at the same time avoids the high banking overhead when distributing small amounts of cash.
  3. Using blockchain DEX allows persons-in-need to collect, exchange and bundle tokens from a number of cooperating helper organisations into a significant sum, that can be redeemed as fiat with the lowest overhead possible, and used to buy medicine, education, tools etc.

Specifications of project Pepito, December 2020

The project is here. The dApp offers 3 actions in its current stage: create disguise, read disguise, update disguise (more to come)

  • Create disguise: mainly in React.js, the dApp assembles a disguise from the choice of components, creates a JSON for each disguise and stores it on-chain
  • Read disguise: the dApp goes through the array of addesses of disguises, retrieves and displays the data of each disguise
  • Update disguise: the dApp searches for a specific disguise and displays the pairs key-value for update and records the update

Roadmap of Machu Picchu

Contributors can develop independently and contribute as a distinct project.

Other contributions are welcome and could be:

  • a data management system to on-board, list and modify the persons in need, using OrbitDB and IPFS, with decentralised data schemas
  • a management system of helper institutions, n-to-n connected to persons in need
  • modify the cost-free person-in-need on-boarding, using meta-transactions paid by helper institutions
  • progressive improvements. See White Paper (FileCoin can be added at any stage).

Vision of Technical Stack

A vision of the complete Technical Stack that can be used for Machu Picchu is, in December 2020 and if we have 2-3 M$ immediately available :-) Technical Stack

Contributing

Feel free to open new issues or submit pull requests for Machu Picchu. If you'd like to contact me before doing so, feel free to get in touch (see Contact section below).

Before opening an issue or submitting a PR, you may want to follow these usual guidelines:

Issues

  • Please state whether your issue is a question, feature request, or bug report.
  • Always try the latest version of Machu Picchu before opening an issue.
  • If the issue is a bug, be sure to clearly state your problem, what you expected to happen, and what all you have tried to resolve it.
  • Always try to post simplified code that shows the problem. Use Gists for longer examples.

Pull Requests

  • If your PR is a new feature, please coordinate with me first. Someone else may started the same idea.
  • Any PR should contain only one feature or bug fix. If you have more than one, please submit them as separate PRs.
  • Always try to include relevant tests with your PRs. If you aren't sure where a test should go or how to create one, feel free to ask.
  • Include updates to the README when needed.
  • (Future: Do not update the package version or CHANGELOG. I'll handle that for each release.)

Contact

email: kvutien.yes@gmail.com

License

MIT

About

Final Project ConsenSys Bootcamp

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • JavaScript 84.7%
  • Solidity 12.5%
  • HTML 1.5%
  • CSS 1.3%