Last weekend I participated in a 32-hour BCH hackathon in Amsterdam. It was an amazing “learn, innovate and share” kind of environment with 80+ participants and 13+ teams with brilliant ideas, great mentors and organisers :).
Participating teams came up with many creative ideas to make use of blockchain, especially for micro-payments. At the end of the hackathon, teams showcased working prototypes to judges and audiences.
I worked with a small team as a developer to explore the possibility to own the personal feedback data on blockchain as part of transactions using OP_RETURN.
Why feedback on blockchain? As a team, we discussed and tried to address the below question.
Question: “Is there any data which is about us, belongs to us, good for us but we don’t own it?”. First thing came into our minds was the work reference and feedback we collect while working with others. When we start a new role we provide references and periodically our colleagues and leads provide us feedback about how we are performing, where our skills stand on the scale 1–10 and which behaviours to focus on in next few months. When we switch job we have to start over again from 0. There is not a single place where I can see an overview of how and if my skills are improved over the last 10 years of professional life.
Our solution: To address this issue we decided to create a very simple but working proof of concept application. Next question was, where to store that data? We can store the application data on a server but who will own the server? A centralised entity? You need to create an account and share all of your personal data with that entity. What next? Misuse of data, targeted advertisement and influencing opinions. Rings a bell??
What if we store data on the blockchain. No one owns blockchain and no identity information is attached to data.
We developed an application, essentially a “Personal Data Wallet”, where user login using the private key and without providing personal information. This application composed of three sections
From left feedback request section, reply section and feedback view section
- Feedback Request section
- Feedback Reply section
- Feedback View section
So here’s is the application flow
- Feedback requester logins into the application using the private key.
- Feedback requester initiates a request by making a transaction to feedback provider’s data wallet address with few cents, we call it “Dust”. Before making the transition requester selects few questions which are attached to the transition.
- Feedback provider logins into our application, checks and response to the requests by making a transition back using provided “Dust” as the transaction fee.
- Feedback requester can see the received feedback by simply providing his address or list of address to the data wallet (no need to log in).
If the requester doesn’t want the feedback provider to view previous feedbacks he can simply send each request from a different address or even from different data wallet.
So, how do we verify the providers address? Individuals and Companies can publish the dedicated feedback providing data wallet address on websites, social media or they can verify it on request.
How the feedback providers verify who exactly they are providing feedback to? Data wallet can provide the requester a unique URL redirecting to application’s feedback reply section, this URL can be shared with the feedback provider directly using some known medium of contacts like email, SMS, WhatsApp or some other better method. Only feedback provider will know the requester’s address, no one else.
Point of the application was to permanently hold our useful data without attaching personal information to it.
Next question, which blockchain to use? To be honest any blockchain platform can be used which allows micro-payments and allows some data to be attached to the transaction. We were in BCH DevCon with brilliant mentors from the BCH community, therefore, we decided to use BitCoin Cash ;) .
Let’s discuss the data we want attach to the transaction, we don’t want to store tons of data on the blockchain, so we used a simple protocol for our data.
For request: ProjectPreFix, FeedbackType, RequestType, QuestionsId
example: pdw, req, personal, q1, q2
For response: ProjectPreFix, FeedbackType, RESP, QuestionId:Score
example: pdw, rsp, presonal, q1:5, q2:8
We defied questions with ids on a specific blockchain address :
example: pdw, def, q1:teamwork_skills, q2:communication_skills
We managed to successfully build and showcase our proof of concept personal data wallet with transaction on test net within 32-hours of hackathon using Nodejs, Bitbox and React. As a team we really enjoyed whole process.
We received lots of good feedback on our project specially positive acknowledgement from different people that the problem we tired to solve is a genuine issue.
Now, what is stopping blockchain based projects like this and others from the hackathon go mainstream and viral. Well, Cryptocurrencies have not been able to reduce the cost of transaction fees for micro-payments yet! Below are few main hurdles
Scalability: In late 2017 CryptoKitties dApp project clearly highlighted the ‘scalability’ issue of the Ethereum blockchain. Other blockchain platforms are no different. Scalability is a serious issue on the blockchain. Mass adoption won’t happen if blockchains can’t scale, simply because most people will not accept slower applications than they’re used to just for the sake of decentralisation. Working is in progress in this domain.
Usability: Payment solutions, wallets or other blockchain based application should be usable by common users, not just techies. My grandmother should be able to send and receive micropayment or share data using blockchain without worrying about long ugly hex addresses, high/low tx fee settings and n confirmations. Startups like money button and Card stack are working on this challenge.
Interoperability: We witnessed a wave of different blockchain platforms with different consensus algorithm**,** tech stack and architectures with the focus to solve main issues like ‘scalability’. But wait! too many blockchain platforms. Imagine that we are in a world where different blockchain platforms can co-exist, let’s say at least 5. If we develop a dApp on one selected platform, it means this dApp will be accessible only to community members engaged with that specific blockchain platform. To reach the wider audience, we will end up creating separate dApps for each blockchain platform. That would be a nightmare to maintain.
Now imagine each of these blockchain project forks!!!
There is no way developers are going to continuously create and manage different copies of blockchain application based on different tech stacks used by different blockchain platforms. Have we not learned our lesson? We tried to create hybrid development platforms to avoid android and iOS native development.
Clearly, interoperability between different blockchain platforms is really important if we want to take blockchain to the mainstream. Well, few tech gurus saw this coming and they are already on the case
My biggest takeaway was that the big disruption in the fin-tech industry is coming as lots of smart people are working to remove the above hurdles and, with blockchain tech combined with AI, this industry is full of opportunities and there will be multiple winners.
You can be a winner too, but to be a winner, you must plan, execute and most importantly try.
A nice click from the Residence Inn by Marriott Amsterdam :).