Unlock off-chain overloading of video

[bedeho]

Background

Currently, we have represented concepts like videos, playlists and episodic content (series) as explicit & distinct blockchain level entities within channels. They all have off-chain metadata standards, which allows the ability to have multiple and evolving standard for the write-only part of the information & assets that only the channel owner controls, stuff like descriptions, titles, etc. That unlocks a lot of innovation at the presentation layer, as app-developers (e.g. Gateways) can unilaterally introduce new ways of representing these concepts.

Problem

It's not really clear why we need these distinct concepts, as anyone can in principle (if they disregard the naming) represent anything as a video by overloading the metadata suitably. So they can represent all the other concepts above for example. Having the distinct entity types then leads to two problems

1) It then seems a bit misleading, perhaps to the extent that it can cause a more limited understanding of what is possible, to have these distinct concepts. It could lead to developers not understanding that they are entirely able to introduce totally new things like books, tracks, albums, etc.

2) It means general purpose concepts, like NFTs, do not work for all concepts out of the box, unless we manually go and add it to them one by one.

Solution

Drop all the distinct types, just have one universal channel entity called Content, which works exactly like Video currently, just with methods and fields renamed to be more neutral.

┆Issue is synchronized with this Asana task by Unito

[ignazio-bovo]

I approve

[mnaamani]

Putting all the "details" into the metadata seems like a very workable idea. The less the runtime code needs to change the better. On the point of NFTs we may want to add ownership transfer capability to individual items of content otherwise the NFT would encompass the whole channel. Maybe that is acceptable?

[bedeho]

On the point of NFTs we may want to add ownership transfer capability to individual items of content otherwise the NFT would encompass the whole channel. Maybe that is acceptable?

NFTs already only exist for individual videos, i.e. individual content items, not entire channels. So what this would mean under the new approach would be that all possible content items had the same fundamental NFT functionality, at least technically.

I guess both of you are open to it, but the question is then timing, do we do this now or later?

[ignazio-bovo]

I would prefer later, so I can focus on integration tests

[bedeho]

Ok, sounds wise, lets keep this open then, Ill add the tech-debt label.

[ignazio-bovo]

Now I am starting to understand the problem more deeply. You are saying basically:

• replace/rename

  /// A video which belongs to a channel
  pub struct VideoRecord<ChannelId> {
  pub in_channel: ChannelId,
  /// Whether the curators have censored the video or not.
  pub is_censored: bool,
  }

  using a more generic data struct ContentRecord.

• move all the representation metadata (i.e. info that can be used to discrimination between say video, series, images etc..) off-chain.
• we will no longer touch the ContentRecord data structure in the future. Saving us from any possible map cleaning in any new release.

Correct @bedeho, @mnaamani ?

[bedeho]

Yes this is all correct. We will touch ContentRecord in the future, not by changing its name, but by introducing new things. For example, all your work with pull based payments, or the new work you will do with channel tokens, that will all surely impact this type.

[kdembler]

Once we do this change I guess we could use similar approach for serialized metadata as we've discussed for https://github.com/Joystream/joystream/issues/3255 so that we can identify different types of content

[bedeho]

This change is really purely cosmetic, we don't need to wait for this.

[kdembler]

Really doubt we will do breaking naming change at this point, since this was meant only as a cosmetic, closing