Governing Web Monetization revshare on Peerkat

Metagov Gateway
#1

Peerkat is an on-demand live-streaming platform that is interested in “Web 2.5” governance. They are experimenting with Web Monetization in the form of their “freemetization” experiment, which adds/masks video ads depending on whether Coil is enabled. They’ve also implemented probabilistic revshare (the pointers are specified by the person uploading the livestream), as well as a Metamask integration (!?), and are interested in and open to different ways of governing the revshare logic.

One of their inspirations is audius.org, which has an excellent implementation of voting.

I’ve included some extra details, since Peerkat’s next step is to gamify their platform, and Metagov could also be useful there.

  1. Currently, they use ThunderCore (a blockchain) to support tipping of videos.
  2. Interested in adding bounties.
  3. The community is very crypto-centric, and is into gamification.
#2

Some more information on the freemetization experiment and how we might build on it, based on the recent call with Ike.

  • Most important: the revshare pointers (plus, presumably, probabilities per pointer) are stored directly on a smart contract currently living on Rinkeby, an Ethereum testnet. Right now, governance of the revshare pointers is equivalent to governance of that smart contract.
  • Most of the revshare logic also lives in the smart contract. A small part remains off-chain which is mostly the logic that generates the random number.
  • There’s a separate server, operated by Peerkat, that communicates between the Freemetization page and Coil and which is mostly used to reroute the web monetization payments. [But what, if anything, is governing this server? If this part is vulnerable, does it make sense to have the rest of the logic on a smart contract?]. When the Freemetization page is served, it sends a signal to the server, the server picks reads the smart contract (which is public), and then forwards that pointer to Coil for payment.
  • That pointer is a Coil pointer. However, the owner of the Coil pointer can choose to receive payments to an Ethereum or XRP wallet (using a new integration called Uphold). So the location of the smart contract (whether on Rinkeby, or Ethereum mainnet, or NEAR, or wherever) is completely independent of what (crypto)currency is getting paid.
  • Currently, the smart contract allows you to add/remove payment pointers, and has an ownership feature (i.e. ability to edit payment pointers), plus the ability to transfer ownership to another person. In the future, Ike would like to include the ability to delegate certain actions to certain other owners, e.g. to have someone make edits on certain sections of the contract on my behalf but not to necessarily pass “ownership”.

Next steps:

  • A “standard” way of governing the revshare contract would be to pass ownership from a single person to a DAO. Miriam and Josh should explore this. For example, the smart contract could have a “base” set of revshare pointers, and Metagov could act as an oracle that triggers special logic on the contract to modify the base revshare settings (e.g. applying a multiplier on certain pointers).
  • Send Ike additional documentation once it’s ready.
  • Key question for us to consider as we think about how to govern this smart contract: how much of the governance logic lives on the smart contract itself vs. off of it? And of portions that are off the contract, how much should live on-chain and how much should live off-chain? And then, of the stuff that lives off-chain, where should that logic live, i.e. in some service or in a PolicyKit policy?

Side note: Ike imagines that the pointers will be owned mainly by content creators, but it could be anyone. E.g. production companies, lighting companies, entire communities. He was also quite interested in the upcoming governance hackathon with NEAR.

#3

Here’s a rough idea of how we could use Metagov to support an off-chain reputation system that is used as a “multiplier” for revshare pointer weights:

  • The smart contract has a get_pointer function which returns a payment pointer to a GateHub or Uphold wallet. get_pointer is called by whatever is ultimately inserting the pointer in a meta tag for revenue.
  • The smart contract also has a set_multipliers function which updates the weights for each pointer. (ex. set_multipliers({"$josh.example": 5, "$miriam.example": 2}).
  • The smart contract has its own revshare configuration and mechanisms for adding and removing pointers.
  • The contract wants to use SourceCred grain as a multiplier for weights. Grain is distributed weekly, so it the multipliers should be updated weekly.
  • The people that own the wallets are part of a “community” that uses Discourse and Sourcecred. The Sourcecred instance tracks value on Discourse. They have their Discourse instance set up with a custom user field called “payment_pointer” Each user can fill it in with their wallet address (ex thelastjosh has payment_pointer: "$josh.example").
  • The community uses PolicyKit+Metagov for governance.
  • The community has 3 enabled Metagov plugins: Discourse, SourceCred, and SmartContract. These are their relevant capabilities:
    • SourceCred: sends an event to the Driver when grain is distributed on their instance
    • SmartContract: exposes an action for making a call to this community’s contract
    • Discourse: exposes a function for retrieving user attributes from this community’s discourse
  • Finally…the governable PolicyKit policy looks something like:
    • When event grain_distributed occurs, ask metagov for the payment_pointer attribute for each Discourse user, and then tell metagov to send them to the contract using /action/$smartcontract.call { set_multipliers }.

This might not be a desirable approach, but writing it out is a helpful exercise for me. With this approach, most of the governance logic is still in the smart contract, and PK+metagov are acting more like an “IFTTT” service. The added bonus is that the Policy itself is governable.

1 Like