The Slant Protocol v0.1
You are Slant!
We realize that opinion data is one of the most controversial values of mankind. With SLANT, we are creating the foundation of how we and future generations define the value of opinion data, how we form opinion, who has access to it, how controversies and discussions around opinion are structured and how consensus can be found. We want to offer a decentralized open source network and invite a wide range of people and groups to participate in our conversation and efforts to develop the standard in collecting, structuring and organizing opinion data for the next generation of the web.
How to get involved:
To foster the conversation we are using RAWR, our app based on SLANT.
Every time you find blue highlighted text we have specific questions on the highlighted concept. Please let us know what u think and contribute your arguments through rawr’s conversation widgets. It’s really simple. You can also submit and promote your own questions by filling out the contact form underneath each rawr.
If you want to commit new ideas or concepts or help us to decide on the roadmap and priorities of slant, please join the steering committee.
And of course, if you really know your game, please become a committer. Please chat to any of the existing committers and find out how to get involved.
This protocol aims to be the number one standard in scrobbling, structuring and organizing opinion data in the next generation of the web.
We strongly believe that opinion is becoming one of the most valuable assets in online society. However, the web currently is insufficient in organizing access to opinion data, managing opinion data and transacting opinion data. With SLANT we are proposing a blockchain based solution for this problem. SLANT is a key infrastructure of the the internet of value.
Data is our new oil
“The world’s most valuable resource is no longer oil, but data” – the Economist
Throughout the last century, the resource in significant demand was oil. Today, when digitalization has an impact on every aspect of our life, we see a similar situation and similar concerns raised by the internet giants that deal with data. The big players here are Alphabet, Amazon, Apple, Facebook and Microsoft. They seem to be unstoppable and are growing in value every day. This in mainly because of us – the users – delivering masses of data to them every day. Every single post on Facebook, Instagram or every email we send, generates money for many parties, most of which the users don’t even know about.
So – data might be the new oil, but it is still unstructured, unrefined, hard to find and currently only available to giants like Google.
What do you see from the growing value of your data?
Users are getting tracked with every click
The growing value of our data, results in an unbearable situation when it comes to data privacy online. Simply put: There is no privacy online. We are being tracked with every click and our data is getting distributed, sold and multiplied and so is our sensitive and personal information.
Each year, our data generates hundreds of billions of dollars worth of economic activity, mostly between and within corporations – all on the basis of information about each of us. Why are the big players offering their services “for free” to their users? Because, they are not free. The transactions between the user, giving up details of him-/herself to a company in exchange for a product like email or Facebook are worth on average $ 1,000 per person per year. Since we are just in the beginning of making data useful for many business areas, this number is quickly raising.
Opinion – a scarce commodity
The problems listed above are not really new. And there are already many projects, startups and companies, working on global solutions for data consumption with a fair treatment of user data. Many of these projects are focusing on data for AI. This makes sense when we look at how AI is gradually evolving, especially in the working environment. AI and big data are changing the way we do business – or even more – will change what we understand about work completely. There are masses of data needed to make predictions and analyse insights that are far beyond the capabilities of manual processing. There is so much potential for AI development that it’s getting harder and harder to imagine a future without it. But there are many questions arising in the discussions about AI taking over our current jobs. What does AI mean for the future of our jobs? Will it take over and make us redundant? Or will the future create even more work for us humans?
Anyways, no matter what the right answer is for this discussion: we think, due to the emerging evolution of AI, human mental assets will get more and more important.
And which mental asset is more unique than our structured opinion? Opinion is a scarce commodity, which is produced and exchanged every day. It is the result of all experiences, thoughts and people in our lives. It is the one attribute which makes us humans unique and diverse.
But, in regards to Brexit or the US-elections in 2016 we realized, that today’s web doesn’t provide a secure environment for opinion data. Even worse, existing filtering and tracking mechanisms in social media are severely detrimental when it comes to online opinion.
SLANT’s vision is a secure, transparent and trustful environment for opinion data with the full focus on web users. It is the only trusted source for opinion data and is developing the infrastructure for future democratic processes on the blockchain.
Web users urgently need to regain the control over their data. SLANT is helping them by providing the users a home for their opinion where they have the full control over their produced data. SLANT users are the ones who decide whether their data should be accessible for third parties or if they want to keep their opinion secure and private. If they offer their data to interested groups, they should get paid for it. They get rewarded for their mental asset; opinions.
“A view or judgement, formed about something, not necessarily based on fact or knowledge”
An opinion is a view or judgement formed about a topic made by an entity or group of entities, not necessarily based on an argument.
A topic is an issue of general interest where entities can form a view or judgement about.
A tag (usually) is a single word meta information stored on a resource. Tags can be retrieved for free in order to search them.
An individual, a group or a content producer who is contributing or signing slant data to the network.
An argument is text, directly connected to an opinion.
A message which is distributed to the slant network depending on filters (audience targeting) and stored on each wallet. A message may only be unlocked (read) with a private key of that wallet which will result in direct read verification.
- Slant data
Slant data is defined by the combination of an opinion, a topic, a message, an entity and an argument.
- Data owner
The data owner is either authoring a topic or is defining arguments around a topic.
- Data consumer
The data consumer acquires Slant data via the SLANT interface or uses it to send messages to wallets.
A resource is a data class within the network to be referenced by data packages.
- SLANT Connector
= the wallet manager on the client. The SLANT Connector keeps track of the user’s action and matches it against signing requests from locations in order to successfully sign data packages.
- Data package
Data packages bundled Slant data sold to the consumer
A set of parameters and instructions to be triggered against the network in order to result in an outcome. A query may include a Message or an instruction to aggregate data.
- Signing Request
A request made by a location to the Connector in order to sign a data package on behalf of the user, to push it into the SLANT network.
Any kind of event within the SLANT network, i.e.: interactions of users or the distribution of rewards to users.
In order to properly function for the use cases the protocol must provide:
- Trust in data
The identity of the data owner should be protected while providing mechanisms to verify the authentication of the data
- Decentralized control
The control of the owner over his data must not depend on a centralized third party
- Simple usage
The core features of the protocol must be designed to reduce the overhead required for end users to use the platform or any extensions
- Simple implementation
The protocol must be easy to implement, thus data is stored in json format
Everything within the platform will be managed by wallets. Wallets store a score of the user (which will be determined by other users) and the score then will be applied to the rewards a user gets.
Wallets must enable the owner to:
- mine & store tokens privately without third party access
- pay tokens in order to user the SLANT platform (reading rights)
- (at some point) exchange tokens against fiat money
Acquiring an address
To use the platform and its features, one must have a wallet with an address, where the reward is sent to and with which transactions are signed. Therefore we must tackle the challenge to achieve an optimal solution between, providing an easy-to-use interface with frictionless account setup and, enabling the flexibility of increasing security and control over their own account (for those who want to). For this, the SLANT platform will provide two options for users to manage their wallets:
- a centralized key storage authentication mechanism for users who don’t fully focus on security and just want to have their traditional functionality of websites and interactive widgets
- a browser extension for those who want to be in full control over their account
Option 1: Centralized Key Storage
This procedure allows a user to register an account on the SLANT platform where a private key is generated on the server and attached to the user account. A user then is able to login with a username and password. An integrated script on the website will then open up an iframe where the user is logged in into a session.This iframe provides endpoints which support the Channel Messaging API where requests to sign transactions are accepted and returned. Further requests are matched against collected actions in the website context to prevent that requests are signed. (https://developer.mozilla.org/en-US/docs/Web/API/Channel_Messaging_API)
Option 2: Decentralized Browser Extension
SLANT recommends using this option when authenticating. A browser extension will generate (or accept an own generated) key pair. When the user makes an action, it stores the action temporary until a signature request arrived or the lifetime expired (usually within seconds). When the signature request does match against one of the actions recorded in the browser extension, it signs the transaction and returns it to the requester to pass it to the next or the platform. This requires, that user install a browser extension. To catch those, who don’t have the extension yet, SLANT suggests that the website embedding the SLANT interfaces suggest the installation to the user. If this fails, a fallback (Option #1) is provided, where the user can use the traditional credentials to sign transactions. Find a diagram below to show the process when a user visits a website without a SLANT address until the point where the transaction is pushed into the SLANT network:
The address of the user will act as an identifier and data packages signed by that address will be linked to it. To limit attacks, the wallet of the end user must be in a separate scope isolated from other parties, especially locations (websites) to protect the private keys of the user.
A user needs to be always referred to a real person, to make the system work (SLANT aims to mine real opinion data).
Locations include for example a publisher’s website and also an extension of the protocol (for example a new app). Just like the user, the location receives tokens for any transactions they push into the network (though the amount of tokens may vary depending on the quality). Thus, for locations, there must be an easy backend integration to manage wallets (for example to query for aggregation of data).
The consumer may be any party involved in the system, interested in the data which is mined through the network. At its core, the wallet of the consumer is technically the same as the one of the location or the user. So any feature, enjoyed by the consumer will also be available for users and locations.
Resources are like categories or channels of transactions (usually) of the same type. For example in the case of RAWR (www.rawr.at), a resource could be a question, users will be confronted with. Resources need to be registered in the network before transactions can be assigned. The SLANT network will provide an interface, which on requesting a new resource, will return the address of that resource which can then be used by transactions to be assigned to.
As defined before, expressing or measuring an opinion can be anything which is related to an action or an event thus mined transactions contain an information about the event.
name: 'foo', // name of the resource
// ... any data, for example vote: 1 or argument: "hello world"
tags: [<string>], // tags which are used for filtering
type: [<string>], // either "resource" or "entity"
resource: <string> , // the address of the resource which is returned when it's created or looked up
locked: <boolean> , // whether the user allows to read this data package
address: <string> , // address of the data owner
signature: <string> // signature of the data owner of the data package except the signatures array
address: <string> , // address of the location #1 (for example a widget embed on a site)
signature: <string> // signature of the data owner of the data package including signatures
address: <string> , // address of the data owner
signature: <string> // signature of the data owner of the data package including signatures & signatures
// ... nth more
|.signatures.length >= 2||There always exists one user and at least one location|
|when .type==”resource”, set .tags||Tags may only be defined on resource and not on data packages|
|when .type==”data”, do not set .tags||Tags may only be defined on resource and not on data packages|
|.tags.length <= 10||Tags need to be specific and not too broad|
|.data.event must have a common identifier (https://developer.mozilla.org/en-US/docs/Web/API/Event)||Categorization of user actions in order to determine activity involved in producing data package.|
Let’s assume we have the following setup:
- Location #1
The location #1 is a website on the web
- Registering a resource
This example would register the resource in the network (as location #2)
- User #1
There is a user who will visit the location #1 and interact with location #2
- Location #2
The location #2 is a developer who has developed a poll widget which location #1 will include on its website
question: 'What do you feel when you think about snakes?',
tags: ['question', 'animals'],
And the response would return the address of the resource:
Adding a transaction to a resource
When a user publishes his/her argument on the question (resource) we created before, the network submission would look like:
argument: 'I scream and run away.'
The PKI of the SLANT platform provides mechanisms for any wallet owner to make transactions and sign them via their own private key. Hence each transaction will have an array of signatures attached, where each signature will include the signature of the previous data package + available signatures. This enables everyone within the platform to validate the signature chain, authentication & trust level of the transaction.
To extend the trust level of the owner of a data package the SLANT protocol will need mechanisms to prove the KYC. Open discussion rounds about that topic will follow in the future.
The data is stored decentralized with a query engine which may grant access to meta data like resources (see terminology) for free but requires SLANT tokens (which act as reading permissions) in order to consume SLANT data (see terminology).
Data quality analysis
The more verified details a wallet has provided, the more trustworthy the data is and thus the more it is of worth for the consumer. Therefore SLANT will rate the data packages submitted with a verified wallet a higher score resulting in a higher reward for the user and the involved locations. This does not automatically imply, that the provided details may be read from a consumer. For example, one could verify his or her identity with personal details like zip code and so forth but at the same time protect those details from being read by third parties → he or she would then earn more rewards for providing additional data packages because the owner of the data is validated.
As locations are the critical part, (especially in the web context when thinking about websites) the SLANT platform will care about abuse and security related to locations. For now, we plan to develop the following features in order to rank locations:
- Votes on locations
Users are enabled to vote locations they are using up, or down, which will affect the reward being distributed for data packages.
- CSP signatures
Content Security Policies are a good way to protect a user’s identity within the browser on websites. SLANT will rank locations which have a set of CSP rules, higher in the header. At the moment when the user signs a data package, the CSP headers are also added to that data package and then signed with the user’s private key. This enables an on-time snapshot of the CSP headers without data leaks. Depending on the amount of headers and especially the strictness of its rules, the SLANT platform will apply a factor to the reward which may then result in a higher reward for the user.
- Limited rewards per day
The wallets may earn a limited amount of x tokens per day.
- Limited contribution per user per hour
The addresses of .signatures may only contribute x times per hour.
Its free for any wallet to browse existing resources in the network. If users find two or more resources which are equal in their context and sense, they may vote to merge them. If the votes exceed a given threshold the resource with the first timestamp will be the new hub and the other resources will point to the first resource thus removing them from query results.
As users are also consumers of the content of other contributors in the network (for example when a widget displays the results of a poll at the end of the funnel) the user also may up or down-vote a specific user (or “wallet” in its anonymous form). These votes will not only result in gamification (see appendix) but also reflect in the score of the user which will have a direct impact on how many tokens he or she can earn.
Locations are very critical parts in this story because they need to provide data structures to the community, which makes sense to be prepared for consumers. On the other side, the quality of the network of the location determines the quality of the data being mined – therefore users are invited to vote on locations as well. What needs to be defined is, how such ratings would look, so users don’t just up-vote locations in order to get more rewards for their contributions.
As the signatures and addresses are appended to the data package SLANT will found and distribute the amount of tokens to the addresses in the moment when the data package is fully signed and pushed into the network
SLANT network provides different types of queries in order to meet requirements of data consumers as shown in this chapter.
Signature of Consumer
In order to send any query into the network one must have enough slant tokens in his wallet. The query then will be signed with the private key and executed when the signature is valid and the balance high enough.
Based on the popularity of the attributes within a query it will get charged higher. The popularity is defined here as the amount of queries containing the respective attribute in the last 30 days leading us to the formula: TBD
Types of queries
- Aggregation of data
Any data package within the SLANT network will be available to be looked up in exchange to SLANT tokens, and as long as the data owner gives permission to read. Via an interface, a consumer is able to spend tokens and thus send queries directly to the network in order to produce a specific outcome or result.
- Message Distribution
One consumer may also send messages directly to the users with the benefit of trust in the fulfillment of the filter and also on the validation of (read) directly accessible via addresses. For example, when users push a message into the network to address wallets given a specific filter, this message may be only read by those wallets with their private keys. Furthermore, whenever the wallet opens & reads this message, a verification is stored which can be accessed with the key which was returned when pushing the message into the network.
This is a collection of challenges we see us facing in the future. We’d love to discuss these with all of you! In the roadmap you can find deadlines for our feedback rounds and townhall meetings on these requests for comments.
- General discussion on technical core
Open source strategy
- General discussion on open source strategy
- How can we protect ID’s in mobile browsers
- Meta level of action listeners across mobile apps
ID & Fraud Protection
- How can we protect ID’s across websites
- When someone clicks on an advertisement (maybe a link within a SLANT message)
- How can we store data decentralized & protected against unauthorized access
- Scam Protection (Flooding etc..)
Queries & Costs
- How do we prevent use cases with high query prices
- How do we prevent an inflation of tokens
- When someone clicks on an advertisement (maybe a link within a SLANT message)
You can find every topic which will be discussed with the public in this roadmap.
Each topic is going through the same cycle, consisting of:
- a two weeks time-frame in which you can contribute your comments on the given topic through the discussion widgets linked in the protocol or through the contact form below each widget
- one townhall meeting in which we will meet and discuss the given topic in a video chat with everyone who wants to join
- an internal review round in which our team implements all the feedback and comments into the protocol
Internal ReviewFeb 2 - Feb 09
Townhall Meeting: Open Source StrategyFeb 16
Internal ReviewFeb 23 - March 09
Townhall Meeting: Mobile IntegrationMarch 16
Internal ReviewMarch 23 - Apr 06
Townhall Meeting: ID & Fraud ProtectionApr 13
Internal ReviewApr 20 - May 04
Townhall Meeting: Queries & CostsMay 11
Internal ReviewMay 18 - June 01
Townhall Meeting: EcosystemJune 08
Internal ReviewJune 15 - June 29
Release Protocol v1.0July 01