Background

We are in the process of incorporating applications as metaprotocol level concept, here #4307, primarily to unlock attribution that finally enables the council to pay apps for the content and creators they onboard based on accurate information. That proposal made applications owned by memberships, which was a natural starting point, it does however have limitations:

1. Scalable Payments: a practical and efficient way to reward apps
2. Financing: Running an app requires investment of various kinds of front, with uncertain payoffs down the road.
3. Transferable ownership: Being able to sell your app to someone else later, so they are the full beneficiary and administrator, generates better incentives for long term stewardship, even if time horizon for personal involvement is uncertain or finite. This is of particular importance, as apps can harm end users.

Proposal

These could all be implemented by making the metaprotocol more elaborate, adding new proposals and adding new integrations between membership pallet and project_token pallet, but even then, there would be no functional software that would be able to allow people to use all these features.

Instead, I propose we simply overload the channel entity in the content pallet to also be to function as an app. By doing that, you get 1,2,3 solved for free, without any work. One could also very easily add a new section to Atlas, or just make a standalone product, which allowed for using all the $CRT features, but only for apps, not creator channels, and very limited extra work would be needed.

Technically, one could more specifically do something like this:

• The actions CreateApp, UpdateApp are sent over content::channel_owner_remark instead of membership::member_remark. I think DeleteApp causes more trouble than its worth.
• Apps have their own ID identifier space, as distinct from the channel IDs
• There can be at most one app per channel.
• In QN/Orionv2
  • Add Apps as a new schema entity, it holds all the metadata already defined for an app.
  • Add nullable 1-1 relationship Channel::app to Apps

This is not the only way to do this, but it is a way which causes minimal change requirements other places. Feel free to improve!

Atlas can now choose to either systematically ignore all channels, or videos from channels, which have an app, or they can just be included as normal channels. Notice that its still possible to do all the normal channel stuff with apps. If we wanted, Atlas could also choose to add a flare or other sort of signal to channels which are apps. Most regular users would just be non-the wiser.

Question: with current QN or coming Orinv2, will it be easy to avoid channels which are apps, and also videos that correspond to channels that are apps, in all places needed? (search, within categories, etc.)