Joystream / joystream

Joystream Monorepo
http://www.joystream.org
GNU General Public License v3.0
1.43k stars 115 forks source link

Metaprotocol Runtime layer - extrinsic list #3269

Closed ignazio-bovo closed 2 years ago

ignazio-bovo commented 2 years ago

Initially intended to be a personal reference, I thought to make a document that could serve also as object of discussion, since inputs from Atlas / QN teams can change / nullify all of this.

Background

If this Metaprotocol framework architecture is desired

Layer Task Responsibility of
1 Transaction ordering Substrate Runtime Consensus Algorithm
2 Role authentication Joystream Runtime
3 Metadata processing Query node infra & Atlas

Then the joystream runtime layer should just verify role authentication or verify that some information is present on-chain. This means that there should be a remark extrinsics whenever a layer of authentication is needed. This also implies that no differentiation (at runtime level) is made for example between a concilor remark in the council system and a concilor remark in the proposal system.

Notation

Metaprotocol *-remark extrinsics list

Below there is a list of extrinsics with respective signature, event, authentication triple. Eventual comments are made right after

Working Group - Lead

Working Group - Worker

Content - Channel Owner

Content - Channel Collaborator

Content - Channel Moderator

Content - Member

I felt that this is required since QN has no way to verify that video_id actually exists. An alternative is to simply remove this extrinsics and allow comment/reaction for any possible video_id value

Content - Curator Group Member

Content - NFT Owner

Storage - Operator

Distribution - Operator

Membership - member

Bounty - Contributor

There might be no need for interaction between contributors however

Bounty - Creator

Bounty - Entrant

Bounty - Oracle

Council - Candidate

Council - Councilor

Proposal - Proposer

Authentication routines

┆Issue is synchronized with this Asana task by Unito ┆Link To Task: https://app.asana.com/0/1201958687417145/1201958692456531

bedeho commented 2 years ago

Phenomenal work.

As I said in DM, it's not 💯 obvious we need all cases, but having very granular messaging channels will anyway open the door to mappings that are simpler and faster. It is very very important that whomever is using the relevant extrinsic understands exactly what the guarantees are, so they know what the query node has to check on top, so this documentation will be a great base to add to the handbook later also.

ignazio-bovo commented 2 years ago

Any reason why the emitted event should contain origin, when signature verification is a runtime responsibility?

bedeho commented 2 years ago

Any reason why the emitted event should contain origin, when signature verification is a runtime responsibility? It should'nt, perhaps I missed that, but it should def. contain whatever actor id or actor type information exists.