Token-curated Registries & Livepeer


#1

Token-curated registries (TCR) are decentrally-curated lists with intrinsic economic incentives for token holders to curate the list’s contents judiciously. They have many applications. For example, adChain uses a TCR to curate a list of quality websites for advertisers to target. Likewise, the 0x protocol team just announced its plans to curate a list of ERC20 token metadata for market participants to verify token addresses.

Can the Livepeer community benefit from its own token-curated registry? For example, per the suggestion of @ericxtang, we can curate a pass/block list of nodes/IPs that any node operator can elect to subscribe to. This can be used to block abusers, promote good actors, or even curate content on an application level.

I’d love to gather the community’s opinion on TCRs in the context of Livepeer as well as initial parameters (minimum deposit for listing candidates, token supply, etc). There’s a generic TCR repo by the creator of the TCR, so we could theoretically plug our initial parameters, deploy, and create a nice front end. This could be a relatively low cost / high-value project for the Livepeer community.

Thoughts?


#2

cool idea! who would be using this most likely? transcoders? token holders looking to stake towards a transcoder?


#3

Right? Eric introduced me to the idea. Yeah, I think token holders looking to stake towards a transcoder could definitely benefit from a list. Having a community-vetted list of transcoders would be a great resource for them while doing research.

We could create another list for vetted broadcasters. This could be subscribed to by both developers and transcoders. Developers could subscribe to this list and perhaps display a little Twitter-like “verified badge” next to a broadcaster in their Livepeer app. Transcoders could subscribe to this list to ensure they’re only doing work for vetted broadcasters.

We could also create a “block list” for submitting nodes/IPs found guilty of any of the outlined attacks.


#4

Yah I think there are really interesting things here along the lines of content moderation. Under the hood Livepeer is just passing bytes of data around and users can use the protocol to broadcast what they want, but people running public nodes most likely do not want to propagate or transcode content that is illegal or in violation of certain principals.

A TCR is a decentralized, community driven way, to create a list that classifies certain types of content or broadcasters. Node operators could optionally tap into this list as per their own preferences.


#5

In addition to curating a block list, another potentially interesting use case when coupled with incentivized data relaying could be curating various bootnode lists that represent various regions/subnets i.e. SW U.S. or NE U.S. The lists could be opt in for any new node that joins the p2p network - if they opt in they’ll use the bootnodes in the list. The Althea Mesh team is poking around with some of these ideas https://docs.google.com/document/d/1KA89SgxpgHJcEJILuzbIlNLjLtVGNW2OD42eOrZC4yQ/edit

People might want to curate and use these bootnode lists for smaller subnets for reliable connections that are in closer proximity to them in their particular region. Nodes might want to join the list because if new nodes joining the network default to using these bootnode lists, they increase their chance of being a hop on any particular relay path in the network thereby increasing the amount of fees they could earn (as a hop on a path). Deposits required for nodes to join the list should scale with the number of connections that they have since these nodes are likely earning more relaying fees and have a greater ability to mess with nodes on the network with malicious behavior since it is connected to more nodes so it should have more stake locked up that can potentially be slashed.


#6

Nice one. So here’s a breakdown of the lists suggested thus far:

  1. Transcoder List (for token holders to use as a resource while vetting transcoders)
  2. Broadcaster List (For developers, consumers, and public nodes to opt into some sort of content moderation TBD)
  3. Block List (For public nodes to avoid bad actors)
  4. Bootnode List (for transcoders? to help them discover relay nodes? in close proximity to them…@yondon let me know if I messed that up)

Of these lists is there one, in particular, you all would like to see prioritized?


#7

I think the one that would be most immediately tapped into would be 3, but it would require building some UX for stakeholders to actually easily observe and share that data back to the list.

2 is almost the opposite approach. It would be building a simple content discovery platform that features all video, and have it be curated which broadcasters’ videos show up there via the list. That could also be useful but is a big product challenge that extends well just beyond list building.


#8

Yah agreed. For a block list, what sort of data should go into a listee’s application? Off the top of my head here are some ideas:

  • Ethereum address of abuser
  • IP address of abuser
  • Description of offense
  • Array of transaction hashes (sometimes leave a paper trail of malicious behavior)

Pseudocode example:

let listing = {
  ethereumAddress: '0x05193dDa4fd8379087282e110f3c263c95453a56',
  ipAddress: '16.165.176.20',
  description: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit.',
  transactionHashes: [
    '0x18870f151bf615aba244d9bf94cf9cbd65d59c01070d4334d9d30c6433631ccd',
    '0xbc830324db795e0f1e41e7918b36331aafc55e94bb8d829070516848e8d59267'
  ]
}

let obj = {
  id: listing
}

// Compute the listingHash offline
let listingHash = keccak256(listing)
// 0xfc11ba76da281550e957189c9909d866c8fb72034ec6724e6a60906a776d0fe2

// Add the JSON object to IPFS
let CID = ipfs.files.add(Buffer.from(JSON.stringify(obj)))
console.log(CID[0].hash)
// Qmf2CPd4ZwpP7vGEHvsk8DWdvatxSdc7iXXBv2bRJvuCp7

// Data is the ipfs multihash of the added json object
let data = CID[0].hash
// Qmf2CPd4ZwpP7vGEHvsk8DWdvatxSdc7iXXBv2bRJvuCp7

// If you called ipfs.get(data), you will be able to see the json obj
// This is what clients will do to build the context of the application (see below)
let ipfsPath = ipfs.files.get(data)
// { 
//   "id": {
//      "ethereumAddress": "0x05193dDa4fd8379087282e110f3c263c95453a56",
//      "ipAddress": "16.165.176.20",
//      "description": "Lorem ipsum dolor sit amet, consectetur adipiscing elit.",
//      "transactionHashes": [
//         "0x18870f151bf615aba244d9bf94cf9cbd65d59c01070d4334d9d30c6433631ccd",
//         "0xbc830324db795e0f1e41e7918b36331aafc55e94bb8d829070516848e8d59267"
//       ]
//   }
// }

// Apply
registry.apply(listingHash, 50000, data)