Question: How to standardise infrastructure access policy signals in metadata

[bedeho]

Background

There are already a variety of metadata fields that should impact of Argus, such as

• https://github.com/Joystream/joystream/issues/4326
• https://github.com/Joystream/joystream/issues/4325
• https://github.com/Joystream/joystream/issues/4327
• https://github.com/Joystream/joystream/issues/4331

Question

1. These policy implications are tied to very specific metaprotocol messages, but this means that if an application developer wants to augment these, even in very superficial ways, Argus will not automatically understand these policy signals in these new message formats. Seems the answer here has to partially be to lift out policy stuff into a special layer, sort of like what has been suggested for application actions.: #4307
2. How can we allow application developers to define new policies entirely? e.g. only x users can access something, or only people with an NFT e.g. It would be very powerful if there was some process to standardize such things. **Addendum: this may just not be possible because the DAO is paying these costs, a totally unconstrained way of imposing such obligations does not make sense. The next best alternative may just be to have a really broad suite of policies, and then new ones have to be adopted through governance, here are some interesting initial ones
   • is among this set of members.
   • is among people holding an NFT worth at least x for at least y time.
   • is holders of at least x balance in $CRT

Its not clear if gateway still should pay in all cases.

[bedeho]

Ex-post Note: read this issue as well https://github.com/Joystream/joystream/issues/4557, as it lifts publication dates into runtime for the purposes of making NFT and other native features aware of this, hence the proposal below should be revised in light of this.

Proposal

Warning: This proposal covers what the user may want influence in terms of access policy, not curators.

Recall that content refers to any runtime level object under a channel, so a video, a playlists, and in the future probably many other types of objects (livestreams, articles, etc.) Recall the term insiders which refers to the following group in the context of a given channel

• channel collaborators
• channel owner (including WG workers+lead if owned by curator group)
• lead
• council member
• curators in group which can mutate this status.

Let

• direct channel assets denote data objects directly related to channel itself
• content assets denote data objects directly related to a piece of content.
• full channel assets denote direct channel assets and content assets for any content in the channel

We define a new messages

enum ChannelAuthorizationPolicyType {
 ALL = 0; // Any gateway user can access direct channel assets, insiders access full channel assets.
 ONLY_INSIDERS = 1; // Insiders access full channel assets.
}

// To be used in `create_channel` and `update_channel`extrinsic, wrapping base message
message WithChannelAuthPolicy {
  ChannelAuthorizationPolicyType policy_type = 0;  // policy
  bytes raw_inner_message = 1; // includes primary semantics of action ,like `CreateChannel´, `CreateProfile`, ....
}

---

// "content" is anything published under a channel
enum ContentAuthorizationPolicyType {
 ALL = 0; // Any gateway user can access content assets according to monetization auth policy, insiders access content assets.
 HIDDEN = 1; // Insiders access content assets.
 HIDDEN_UNTIL = 2; // Same as HIDDEN before some premiere time, then same as ALL after. Premiere time is found in message below, no algebraic types :(.
}

enum MonetizedAuthorizationPolicyType {
 UNRESTRICTED = 0;
 HOLDS_CHANNEL_NFT = 1;
 HOLDS_CHANNEL_CRT = 2;
 HOLDS_CHANNEL_NFT_OR_CRT = 3;
 HOLDS_NFT_OR_UNTIL = 4;
 HOLDS_CHANNEL_CRT_OR_UNTIL = 5;
 HOLDS_CHANNEL_CRT_OR_NFT_OR_UNTIL = 6;
 PAID_PAYWALL = 7;
}

// To be used with `create_video` and `update_video`, wrapping base message
message WithContentAuthorizationPolicy {
  ContentAuthorizationPolicyType policy_type = 0;
  optional Timestamp premiere_time = 1; // for `HIDDEN_UNTIL` policy

  MonetizedAuthorizationPolicyType monetization_type = 2;
  optional Timestamp monetization_premier_time = x; // for `HOLDS_NFT_OR_UNTIL`, `HOLDS_CHANNEL_CRT_OR_UNTIL` and `HOLDS_CHANNEL_CRT_OR_NFT_OR_UNTIL`
  optional uint64 crt_bar = ; // for `HOLDS_CHANNEL_CRT`, `HOLDS_CHANNEL_CRT_OR_UNTIL` or `HOLDS_CHANNEL_NFT_OR_CRT `
  optional uint64 paywall_price = x; // for `PAID_PAYWALL`

  raw_inner_message: bytes; // includes primary semantics of action ,like `CreateVideo´, `CreatePlaylist`, ....
}

This is a sketch, feel free to clean this up if there is a better representation which roughly allows the same sort of policy space. Critically, this way of wrapping inner messages means that applications can permissionlessly introduce new concepts, like music, books, article or anything else, and Argus will still understand how to distribute them, even though it does not know what the object actually is. Also, all of this should be wrapped inside application action messages, if they are used, described here: https://github.com/Joystream/joystream/issues/4307, so e.g. for channel creation through an app: AppAction( ..., raw_action: WithChannelAuthPolicy(..., raw_inner_message: CreateChannel(...))).

Note

• This proposal does not natively deal with https://github.com/Joystream/joystream/issues/4326, as it is effectively restricted to user defined access policy.
• There is no harm in rolling this out post-mainnet, as lack of such a wrapper message can just be interpreted as the default policy by Argus nodes, hence all you need is a resynch, no QN migration or anything else.

[traumschule]

Isn't the beauty of the remark extrinsic that no one restricts for what kind of messages it can be used for (even if decided to store my thumbnail collection on-chain), as long as the sender pays?

Not all apps may discose the meaning of their messages but some might. Then it will be up to DAO participants to find a way to collect known signals (maintained by builders or anyone). Say someone developed a monitoring system and remarks about the status and performance of providers (joystream/community-repo#656). The council could then request changes to argus from builders or leads can act on it. However we can't know what kind of apps will come up and shouldn't try to restrict it.

How can we allow application developers to define new policies entirely? e.g. only x users can access something, or only people with an NFT e.g. It would be very powerful if there was some process to standardize such things. *

This is not for the DAO to decide in my opinion. Whatever technical solution they come up with may be their competitive advantage. They may however require specific data from the DAO (via a paid service for example) to better capitalize on their ideas which in turn could require costly (runtime) changes, for example covered by a bounty funded by various market players and possible GW.

[bedeho]

This is not for the DAO to decide in my opinion. Whatever technical solution they come up with may be their competitive advantage.

There has to be some defined standard for how apps signal what they want this infrastructure to do, otherwise how is this supposed to work at scale? Is each app developer going to go in and ask for favors from individual operators to work this or that way for certain kinds of content? That does not make sense. There has to be a standard which defines the service the infrastructure can model, and this standard can evolve over time. Also, remember, while the blockchain messages are permissionless to write, having the infrastructure behave in a particular way in response to those messages cannot be a free for all. These operators are working in the DAO, paid by the DAO, staking in the DAO and accountable to the DAO, hence the DAO effectively owns the full CDN, of course it decides how it operates. If an app wants to use some other means of distribution, it can, at least unless the runtime content terms restrict this: https://github.com/Joystream/joystream/issues/4350

[traumschule]

Got you. So whatever is in stock here for GW to unlock on argus' side we can't know yet. To make the current system more flexible in terms of what flags a channel owner can set and how they are interpreted by argus a start would be a tags field, a string that can also be updated by a GW (via some high-level channel monetization form). That way in the future argus could support more and more functions with each release cycle in cooperation with the GW alliance lobbying for specific filters.

[bedeho]

Obs, be aware that all permissions relating to CRTs, that is

HOLDS_CHANNEL_NFT_OR_CRT = 3;
HOLDS_CHANNEL_CRT_OR_UNTIL = 5;
HOLDS_CHANNEL_CRT_OR_NFT_OR_UNTIL = 6;

will be blockers, as there is no near term plan or other imperative to implement hte otherwise quite onerous CRT mappings in the QN, which is what powers Argus. So v1 of this probably should just not support these.