A developer’s vision of Qubic
The full article was originally published by Agentpx on Medium. Read the full article here.
Disclaimer: The information below is my own personal understanding of Q. This article is written to convey my ideas about how Q could be implemented from a developers mindset. Please feel free to discuss, improve upon and work with me to generate ideas and develop solutions. Also please bear with me because English is my 2nd language.
Way-back 2010, I started developing apps to share with the world. But during those times, the tool and framework available does not cater my requirement to execute and complete my ideas.
In fact, I was reluctant to embrace open-sourced framework back then. As I always thought, doing all of my app feature/capability from scratch is the best approach.
But when I began using open-source software, it made my life easier and helped me allot focusing on doing only the core part of my application and concentrate on solving the problem specially process flow.
As I continue my journey to create life changing apps (wow), I discovered lots of helpful frameworks and standards. I will list some of it down below as it is related to what I am trying to convey.
As you can see from above, it’s all about metadata. The first one being a standard for specifying concrete object schema and related schemas that make up a hierarchy of data in a complete tree structure.
The second one is about validating those metadata so that when a payload or metadata get submitted to a server, all validations required for the data to be valid can be handled on client side, which saves time and avoid inconsistent data to store on the back-end.
The third one is just my personal preference for displaying such metadata so that given an object, I will not have to do UI manually but instead data gets rendered in the UI automatically in a neat fashion and fluid ways. (see image below)
Now what’s all these have to do with Qubic?
Let me start with common information about a Person.
images above uses fields [username, name], [email, email address] both contain similar information but aliased differently.
Using my own terminology. We will create BITs, CUBEs (qubics?) and BLOCKs
Let’s call each of these raw information as BITS (i.e. username bit, email bit, etc…)
a) E-mail address + name are often used in a sign-up form.
b) Full-name + Mobile no. can make you a contact information form
I) BITS is a single information about an object or an attribute like age, gender, etc..
II) CUBES is group of bits formed to create set of information based on the context of it’s usage.
For example, Let’s group together a number of BITS and call it CUBES
Above are Mail Info Cube (left image) and Contact Info Cube (right image)
Click below to view plain JSON as Form input via JSON-editor
A sample json-schema
Qubics + Smart Contract (Oracles)
In early days without DLT (decentralized ledger transactions), what we do to save these data is from client side to post it to the server then on the server side, save it to a database.
In a centralized manner like that the trust is important. How will users trust your service if all of their information is in your server? Here’s how DLT or probably Qubics come into play. The number one rule? Data doesn’t have to be stored on our server!
How? Let’s say your user own a bank account and for obvious reason it needs those data to stay on the bank stored and secured. But your service requires bank information so you can proceed to validate if indeed a user has account balance or so.
What I imagine Qubic can do for us is channel request to a bank service by using some sort of metadata directive or reference to users bank account information.
Assuming one Smart Contact named BankOracle has been published by a bank. And this Oracle houses a BankQubic with a purpose of expanding the data within when requested. Now on your end. All you need to have is just a reference to that BankQubic.
So if you need more information regarding that secured bank account information. Your metadata or payload should submit what i call Blocks containing the said BankQubic.
When you pass bankBlocks to BankOracle, It undestand that it has and expected to receive a bankQubic provided by them. This way the data are truely isolated from the outside world. How you acquire a bankQubic is subject for another discussion. But I know you get the idea.
Blocks are composed of Cubes embedded with actionable items.
If we expand bankQubic it might contain the following action items.
To give another example of Qubic and Oracle work in tandem like cascading events to get and acquire information from different Oracles, see below.
Please note that this is just a pseudo code and not perfect in a sense but I made it just to get a glimpse of what we can do in the future to share data across servers and build quorum by participation of different actors.
Qubics and Oracles in action!
More actors…Oracles, Qubics…
For ‘trust to occur’ a taxOracle, truckingOracle and inspectionOracle can be added and has to know and trust you together to form a quorum making your qubic valid.
I have a number of apps waiting in line which fits IOTA tech. Sadly after years of iteration, some are still in development stage because I went freelancing and employed on and off. I do startup thing on my free time to do little by little, probably God planned all of this so I can integrate IOTA to my apps. Yey!
Just in: A quote from Eric.
!tip agentpx <amount> 😀
One more thing, I’m planning to release an opensource repo based on the outlined thoughts above. Currently, it’s a private repo hosted in GitHub.
But the name would be WDX and WAW. Cheers!!!