The Slant Protocol v0.1

Scope

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.

The Protocol:

This protocol aims to be the number one standard in scrobbling, structuring and organizing opinion data in the next generation of the web.

Committers

The Vision

We believe in an empowered society where opinion is an inevitable part of value creation.

The Big Picture

In human history fundamental events such as the agricultural revolution changed the long term prospect of our society. People started to cultivate land and domesticate animals. For the first time, people began to structure resources forming a society characterized by social stratification. Another event was the industrial revolution. Human labor got enriched by machines. For the first time, economic growth outpaced the growth of the population, resulting in more income for the society.

 

Today, we all experience a third fundamental event, which will change the long term prospect of our society yet again – the information revolution. In a similar way as the industrial revolution enriched human labor through machines, the information revolution enriches human labor with information. This has many advantages, but it also means, that human labor is further removed from the economic productivity factor and will increasingly be focused on the bare minimum – decision making. This trend is massively fuelled by autonomous agents and artificial intelligence. As a consequence, today we are witnessing the beginning of the failing traditional, productivity centric economic models. Inflationary monetary policy and financial crisis are only the first signs of our collapsing economic model.

 

With the Slant protocol, we are proposing a new economic model which reflects a new concept of labor. It is centered on decision making and opinion as the most fundamental human right to evolve the labor based concept of work. It is designed to turn opinion into a valuable and transferrable digital asset which represents the labor factor of the information economy. If the slant protocol is successful we will live in a society, where opinion is transactional and sovereign at the same time. Forming opinion and making informed decisions becomes a fundamental source of income for each individual. Having access to the opinion market will be more substantial for us than having access to the labor market. We can’t even start to explain how big this is.

Why web3.0?

During the web2.0 period, Michael Breidenbruecker, one of the initiators of Slant, founded Last.fm,  an opinion network for music. In 2003, financial and mostly legal pressure on Last.fm ltd. was so heavy, that the future of the legal entity was more than in question. In this situation, Michael was developing scenarios how the Last.fm service could be maintained and how user data would not become the collateral of legal and financial battles. A phenomenon that is even more dramatic today giving recent data misuse scandals of other social networking platforms. What was the real problem?

 

Similar to all other web 2.0 projects, Last.fm stored data on a centralized architecture and fostered the economic value of the data through a legal entity in order to maintain the centralized architecture, provide services to its users and pay everyone on the payroll as well as investors and shareholders. In other words, not only Last.fm but the whole of web2.0 in general wasn’t just built on centralized technical architectures but also centralized financial architectures. The real problem was the centralization of data and financial value.

One of the scenarios Michael developed was to decentralise the architecture and keep the service running on a decentralised network. This network would need to guarantee the supremacy of opinion data and at the same time enable the exchange of opinion data on a trusted basis. This network would also need to incentivise all involved parties and distribute financial value. In 2003, this was simply not possible. Interestingly the biggest problem of web2.0 has now become the biggest feature of web3.0. Lets get it right this time guys!

Web 3.0 isn’t just replacing the need for a centralized technical architecture but also the need for a centralized financial architecture. We are pretty sure that the Slant protocol will only work on a decentralized technical and financial architecture.

Roadmap

The Roadmap

Join us discussing the most important topics of our protocol in our weekly townhall meetups! Check out the schedule down here and get in touch with us if you want to join!

Request For Comments: Protocol v0.1

April 01 - April 30

Townhall Meeting: Incentives & Governance

April 17

Request for comments: Incentive System

April 17- April 24

Request for comments: Governance Structure

April 17 - April 24

Townhall Meeting: Ecosystem

April 24

Request for Comments: Ecosystem

Apr 24 - April 30
Terminology

Terminology

  • Opinion

“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.

  • Topic

A topic is an issue of general interest where entities can form a view or judgement about.

  • Tag

A tag (usually) is a single word meta information stored on a resource. Tags can be retrieved for free in order to search them.

  • Entity

An individual, a group or a content producer who is contributing or signing slant data to the network.

  • Argument

An argument is text,  directly connected to an opinion.

  • Message

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.

  • Resource

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

  • Query

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.

  • Transaction

Any kind of event within the SLANT network, i.e.: interactions of users or the distribution of rewards to users.

Requirements

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

Authentication

Wallet

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 use the SLANT platform (reading rights)
  • (in the future) 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:

Entities

  • User

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.

  • Entitiy

A user needs to be always referred to a real person, to make the system work (SLANT aims to mine real opinion data).

  • Location

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).

  • Consumer

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.

Data Flow

Data Mining

Resources

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.

Transactions

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.

Data Structure

    {
	data: {
		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
	signatures: [
		{
			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[0]
		},
		{
			address: <string> , // address of the data owner
			signature: <string>  // signature of the data owner of the data package including signatures[0] & signatures[1]
		},
		// ... nth more
	]
}

Constraints

Constraint Reason
.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.

Example

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

{
    data: {
        question: 'What do you feel when you think about snakes?',
    },
    tags: ['question', 'animals'],
    signatures: [
        {
            address: 'location#2',
            signature: '#location#2'
        }
    ]
}

And the response would return the address of the resource:

{
    address: 'xyc1'
}

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:

{
    data: {
        argument: 'I scream and run away.'
    },
    resource: 'xyc1',
    signatures: [
        {
            address: 'user#1',
            signature: '#user#1'
        },
        {
            address: 'location#1',
            signature: '#location#1'
        },
        {
            address: 'location#2',
            signature: '#location#2'
        }
    ]
}

Signing Transactions

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.

Enrichment of addresses (KYC)

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.

Decentralized Storage

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).

Rewarding

Data quality analysis

Verified Identities

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.

Trusted Locations

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.

Fraud protection

  • 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[0] 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.

  • Distribution

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

Data Consuming

Quering

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.

Cost Calculation

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.

Ecosystem

Ecosystem

 t time variable

  • t=0 opinion event starts
  • t=τ moment of mining (token distribution to user or app developer)

nu(t) amount of users, who took part at opinion event at moment τ

nC amount of customers, who bought opinion data until moment t=τ

t(c) moment when customer c ∈ 1, . . . , nC bought data

0<α<1 amount of token income distributed to slant

 

0<β<1 amount of tokens distributed to the app developer

 

0 < π(u) < 1 amount of tokens distributed to user

 

\( \sum_{u=1}^{nu} = 1 \)

 

  • with π(u) = ​\( \frac{1}{nu} \)​, every user, who is participating at the opinion event is getting an equal amount of tokens

Amount which a customer  c∈1,…,nC paid for data:

p(c) = γ0 + φ(nU (t(c)) (a monotonically increasing, but concave φ(.)

  • if there are more users at the point when a customer buys data, the data are more expensive. Increase of cost is degressive
  • e.g.: ​φ(x) = ​​​\( \sqrt{x} \)​ or ​φ(x) = γ ln(x)
  • another possibility is to increase the price for the data when bought too early. In this case, would need to decrease and increase afterwards

Income at opinion events at moment t = τ:

 

E = ​​\( \displaystyle\sum_{c=1}^{nc} p(c) \)

 

Payouts:

E·α are the tokens being generated at an opinion event and stored at SLANT

E · (1 − α) are the tokens being generated at an opinion event and distributed to the app developers and the users

E · (1 − α) · β distribution to the app developer

E·(1−α)·(1−β) distribution to the users

E·(1−α)·(1−β)·π(u) distribution to user u

 

Notes:

This is a very first approach to an ecosystem calculation. We are currently working on this topic. Feel free to get in touch if you are a rockstar in that area!

 

Request for Comments

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.

Technical Core 

  • General discussion on technical core

Open source strategy

  • General discussion on open source strategy

Mobile Integration

  • 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

Ecosystem

  • How do we prevent an inflation of tokens

Insert math as
Block
Inline
Additional settings
Formula color
Text color
#333333
Type math using LaTeX
Preview
\({}\)
Nothing to preview
Insert