Soundprotocol
  • Abstract
  • Introduction
    • Current problems
    • The SoundProtocol project
  • Token Model
    • SoundProtocol Token ($SOP)
      • SOP Token Distribution
    • Stablecoin Payments
  • Content Node
    • SoundSP: A decentralized storage protocol
    • Upload flow
    • Content permissioning
      • Proxy re-encryption
      • Unlock conditions
  • Content Ledger
    • Node registry
    • Social features and fan feed
    • Tokens and governance
  • Discovery Node
    • Discovery API interfaces
    • Future work
  • Governance
    • Short-circuiting
    • Enforcing node response accuracy
  • Community-owned Streaming
Powered by GitBook
On this page
  1. Content Node
  2. Content permissioning

Unlock conditions

Artists can tie ability to unlock any piece of content to any condition they choose—some unlock conditions native to the protocol, if the community chooses, could include:

  • A payment being made

  • Sufficient holding of an token

  • Past streaming behavior attested by a discovery node, including but not limited to:

-following the artist

-streamed artist’s work more than a given number of times

-reposted artist’s content more than a number of times

The content node would look for the specified condition to be satisified to issue a proxy re-encryption key at the fan’s request.

By running their own content node, a artist could permission content in any additional way they see fit. Their node software can be modified to add new unlocking permission modules, serving as a testbed for modules to make their way into the core protocol too.

PreviousProxy re-encryptionNextContent Ledger

Last updated 1 year ago