Decentralised Content Curation Protocol.

How it works?

Users announce their actions in the text files, which are then timestamped on the blockchain and hosted on the IPFS decentralised storage.

Blockchain ensures proof that a particular action took place at a specific moment in time.

This record of history can be then crawled, parsed and interpreted by the client-side robots and different views can be rendered.

Multiple clients can present competing indexes and interfaces. In any case, users data and actions are persistent in the data layer.

It's similar to how the web is crawled by the Google bot.

1. Time stamping of user actions (Objective Layer)

Basic (no incentive)

In the basic model, users just announce their actions by time stamping hashes of IPFS addresses.

The system is based on subjective and public announcements of actions on the blockchain by the users.

Actions can be positive or negative. Users can announce that they are adding content from the system or removing content.

Each user runs and maintains repository of their actions and can only write to their own repository.

E.g:

For User A their 'actions repository' would look like:

Block 1288, decentralised_imgur, post,  +'Content IPFS hash1'"
Block 1289, decentralised_youtube, post, +'Content IPFS hash2'"
Block 1290, decentralised_facebook, flag, -'Content IPFS hash3'"
Block 1291, identity XYZ, decentralised_facebook, +vote
Block 1292, identity ZYX, decentralised_youtube, -vote

The blockchain doesn't verify integrity of the announcements.

It timestamps the text file with action announcements, to confirm that a set of actions was announced and published at a certain block.

Syntax of the announcements is also arbitrary and different conventions can emerge.

Users host their actions repository on IPFS and ensure it's up-time.

Incentivised timestamping

In this variation identities can incentivise each other to announce specific actions. This requires the smart contract functionality of the blockchain.

How it works?

  1. Identity A sends a bid to Identity B proposing to pay X amount of token, if the Identity B includes content hash xyz in their action history.
  2. This transaction is facilitated by a smart contract, the contract holds the money in escrow, and validates whether Identity B included specified hash in their blockchain history.
  3. Identity B, accepts the bid, posts the content hash xyz to their history. In then pings the smart contract which validates that the hash was included. Contract releases the money from escrow to Identity B.

In this example we used roles of Content creators and Moderators.

STEP ONE - Incentivising actions, Bid

**

STEP ONE - Incentivising actions, Accept

2. Parsing and interpretation (Subjective Layer)

The client performs the following actions:

  • aggregates user action announcements from the blockchain and IPFS

  • parses the announcements & verifies their integrity

  • renders a filtered view to the user

  • the filtered view is rendered using the UIs and moderation rules adopted by the user

  • as UIs and moderation rules are announced on the blockchain as any other content type, at any given time there's multiple available views that can be presented.

Clients scan the blockchain for the announcements and then decide which announcements to include and which to discard in the final rendering of the view to the client.

3. Comparisons to existing models - Google Search

To better illustrate the idea behind the protocol, we'll use the example of Google running the index of the web.

Google's bots crawl the web and analyse, among other things, link structure between websites.

Websites owners are free to link to other websites in an arbitrary fashion, however, to ensure visibility in Google they adopt Google's guidelines.

Google as the dominant index for the web, controls attention of users and using its position can enforce website creation standards. Websites which not adhere to Google's rules, or abuse the system, get filtered out.

With the system we propose, there's similar economic dynamics as with Google index and website publishers. Users can announce arbitrary actions but its in their best interest to be aligned with the most widely adopted client.

The difference is that ranking rules and user interfaces are public and decentralised. In the Google's model, ranking rules have to be closed. Otherwise they could be easily exploited.

In our model, these ranking rules are publicly visible and created in a decentralised fashion.

Theoretically, if the ranking rules are public and open it's easier to game the system.

However, there are two countermeasures built into the model:

  • abusive actions have to be publicly recorded on the blockchain. They are permanently visible.
  • users performing moderator roles, can watch the blockchain for the 'filtering opportunity'.