Idea: Experimental Atlas forks - WIP

[mochet]

1. Goals

• To (eventually) develop customized forks of Atlas that can deliver distinct experiences for end-users and widen the potential appeal of using the platform.
• Doing so in ways that extend beyond the initial design scope of Atlas
• This is an idea aimed at attracting the widest possible number of users for post-mainnet
  • Having at least a few different forks available for gateways to experiment with immediately after mainnet launch when considering the role would very likely start gateways off with an eye on customizing Atlas extensively in the future
• Successful community building is very hard to achieve and it doesn't work with a single approach, multiple approaches are necessary

2. Scope

• The point of this is not to change Atlas for everyone, but to provide some customized versions that cater to different audiences and interests
• Experimental, intial proof of concept custom forks of Atlas
  • They don't need to be perfect or extensive
    • They can start small scale with rudimentary, rough experiments
  • They do need to experiment with allowing for transactions that don't use any runtime features
    • off-chain processing of these transactions will probably be required.
      • They may use a runtime feature like system.remark
      • They may just be user>user transactions
      • They could be surfaced via the query node
      • The gateway would need to read a transaction event and trigger some form of change in its appearance
• This may not at all be realistic for JSG for pre-mainnet (both in terms of resources, attention & time)
  • Everything is quite experimental, so it doesn't make much logical sense for this to even be directed towards JSG at the current phase of the project when stability and finalizing thigns is the current absolute focus.
  • However, Bounties on the testnet are the ideal place this idea could be toyed with
    • This Value of this is significant and discussed in detail within the Value section
• Some of the features are linked to but not dependent onhaving gateway tokens https://github.com/Joystream/joystream/issues/2976
  • This is not guaranteed to exist (yet)

3. Definitions

• Default Experience- The regular experience provided and consumed with Atlas (by default)
  • entire Joystream ecosystem/open ecosystem - all channels, all videos, all content that is available on Joystream for all users. This is basically the open ecosystem
  • default Atlas - Atlas as it exists now
• Customized Experience - Creating forks of the default version of Atlas to allow for very different features
  • custom instance - an individual, customized version of Atlas that has been deployed by a gateway to appeal to certain users
  • closed ecosystem - an ecosystem that only includes one user or a group of specific, participating channel owners or users that have willingly elected to utilize it.
    • The entire Joystream ecosystem is not shown
  • ecosystem bridges - bridges between multiple ecosystems, can include or exclude open ecosystem
  • end-user customization - providing features and tools which allow either users or channel owners to use features from the custom instance they are participating with to suit their own desires
• Community Building - The combination of people, community, subcommunities, tools, roles and incentives that work together to form a strong foundation for a community to develop from

4. Value

1. Mainnet success is dependent upon community building--this idea will help with that significantly
   • Most community building has been done towards governance and comparitively little towards other areas
2. Many platforms in the past have experimented with a variety of the options presented below
   • At least some are easily achievable and hopefully inexpensive to experiment with
3. Appealing to different types of users is very important. The wider the better.
   • If these experiments are inexpensive and can generate wider appeal then there is no reason to cast a small net or just one net in a very big ocean.
4. Different users require different experiences
   • It is important to understand this refers to far more than just content creators. End-users will want to have options to customize their experiences in ways that are very unique.
   • Users may not know what exactly they want, this is why variety can help
   • Having experimental concepts that different ranges of users find exciting or appealing helps to generate a sense of participation and belonging with the platform.
5. This will likely increase incentivizes for the most important role on the platform (gateways)
   • This role reaches far more users than any other role on the platform
   • channel reach and success is reliant upon gateway reach & success
   • It will allow for more transactions and more financial relationships to be generated
6. Development of this area will have likely have substantial, positive and lasting impacts for large parts of the community
   • pre-mainnet: Training people in the inner workings of Atlas
     • Starts the process of moving ownership of Atlas to the community
     • Starts the process of training people to complete far more technical tasks
   • pre-mainnet: Creation of bounties
     • Provide ongoing work during incentives v3 that is the richest so far:
       • involves elements of design, frontend, backend, query nodes, gateways,
     • Which helps to develop:
       • creation and refinement of authored bounties, relevant processes, standards, templates and expectations
       • a better network of Builders (with varying skillsets)
       • a better network of Oracles (with varying skillsets)
       • involving multiple people working together to achieve outcomes
       • involves multiple people submitting competing work
       • time expectations on bounties that are complex
       • grading, work submission, value and communication expectations across the board
       • ways of dealing with submitted work that requires revisions
       • creation of bounties submitted by individual users rather than just the HR group
   • pre-mainnet: Governance & Spending Proposals
     • Starts the process of scoping out more in-depth and technical tasks
       • Hopefully instigating "chained proposals" (groups of proposals relating to one major task)
     • Starts the process of defining community ownership of assets that are funded by the council
     • Starts the process of moving beyond the community-repo
   • pre-mainnet: Builders & HR groups
     • Obviously will definte and improve both of these WGs heavily
     • Will help build communication between the WGs
     • Will begin to start utilizing discretionary funding and other features that didn't exist before
   • pre-mainnet: Advertisers
     • opens the door for the first time to actively experimenting with possible ways of attracting and obtaining value from advertisers
   • pre-mainnet: Everything else and far more
     • It provides reasons to begin discussing and defining potential runtime upgrades before mainnet launch
     • gateway operators and gateway tokens seem to

5. How & Why?

• To avoid dependence on just being a YouTube alternative or a Netflix alternative
  • Explore & identify more diverse users + groups and ways of appealing to those users
  • Explore & build closed ecosystems where it seems like user engagement will be far higher due to the higher impact it has compared to an open ecosystem
  • Explore & build ecosystem bridges that connect different ecosystems with social content or financial relationships
  • Explore & identify ways of appealing to users who may already participate on platforms where transactions are much more frequent compared to others
  • Explore & identify ways of significantly improving the available methods for community building
    • Identify the easiest, fastest & cheapest options an develop these prior to mainnet launch to provide at least a little "eye opener"
    • Ensure community building is not limited or constricted by a small number of ways for mainnet launch
• Provide ways for gateway operators to have distinct appeal compared to other gateway operators
• Provide more alternatives for how gateway operators can generate income
  • Vastly expand away from web2 advertising networks and/or payment networks
  • Vastly expand away from just $JOY
  • Make use of the idea that a gateway operator can offer many things for on-chain transactions that provide direct incentives for them so that they explore them further in competition with other gateways
• Justify why I believe gateway tokens are essential (https://github.com/Joystream/joystream/issues/2976)

5. Appeal

• Appealing to different types of users is very important. The wider the better.

• This kind of concept does not appeal to everyone, but does appeal to certain users who want a more familial, social relationship with a smaller group of users rather than participating.

• An example may be groups of users who already have preexisting close ecosystem relationships on some other platform.

Concept - Basic examples

• A customized version of Atlas that can be used so creators/channel owners can have their own individual pages that they link to their fans.
  • This is not the same as sharing a link to a channel on regular Atlas!
    • That would be https://play.joystream.org/channel/715?tab=Videos
  • This is a way that a gateway provider can give users a distinct, individual custom URL that does not show any other channels or what is normally shown in Atlas
    • This would be something like http://alice.coolgateway.xyz
    • The gateway provider would hopefully run a custome instance that allows for very in-depth end-user customization of everything ranging from color themes, background images and many other elements that are not gateway respected by any other gateways
    • The gateway provider would also possibly build a way for all of the channel owners participating on this specific instance to be able to share or "repost" other common channel owners videos.
      • Example:
        • alice & bob have both signed up to have custom individual pages on coolgateway.xyz
        • charlie has not signed up for this
        • alice & bob can access a feed which only shows content posted or shared by their channels--they cannot see any element of charlie's channel
        • If charlie wanted to, he could also join this closed ecosystem and participate
      • The gateway provider may elect to have the closed ecoystem's feed on the main domain name, or may elect to have its access hidden away.

Use cases

There are a few different schools of thought for this. (that exist on both the user + provider side):

• A customizable subdomain/URL that can be a combination of any of the following:
  • show only a single user's content and is accessible to anyone on the internet
  • show only a single user's content and is password protected
  • also have a feed/timeline that can show
    • content solely within the closed ecosystem that is being promoted or reshared by the single user
    • content from other connected closed ecosystems
    • content across the entire Joystream platform
    • this 'feed/timeline could completely replace the normal channel view
    • this feed/timeline could treat both the single user's content and other content that is shared from within the closed ecosystem as "equals"
      • or it could treat "other content" as inferior
      • or it could only show "other content" on a specific feed page
• Smartphone Apps can also be used in many similar ways to gatekeep content
  • an app could basically replicate the experience that anyone on the internet sees when they interact with this gateway
  • an app could also be completely exclusive and not be available to anyone on the internet without access to the specific app

[dmtrjsg]

@bedeho @kdembler interested to understand the technical pre-requisites to set this in motion.

[bedeho]

This has to be rewritten, I cannot easily get to the bottom of what it exactly is proposing, and still seems like WIP. I suggest a fresh rewrite if author still is interested in this.

[mochet]

This has to be rewritten, I cannot easily get to the bottom of what it exactly is proposing, and still seems like WIP. I suggest a fresh rewrite if author still is interested in this.

This is something I'll be personally working towards post-mainnet so I don't think there is any need to spend time on it right now. It also relies somewhat on Gateways.

[eclipsingbinary]

This is very interesting.

• "Explore & build ecosystem bridges that connect different ecosystems with social content or financial relationships"

I'm new to gateways but adding modularity is something I do think about.

Here are a few ideas, I don't claim that they're good ideas or if they are feasible, I don't even know if they make any sense lol, but that's where my head goes.

1. Tiered Subscriptions

   • Token Gating with NFTs as a way to have tiered subscriptions.
   • Support multiple networks for this.
   • A user or app builder can gate their channel or app with an Ethereum NFT if that's where they are minting them.
   • If you own NFT A you have access to some content but if you have NFT B you get extra goodies.

2. Another thing I think about for content creators is, if everything goes well for us, we'll be earning multiple tokens, on multiple platforms in multiple networks. How do we bring these together so that we can accept all these tokens as forms of payment that unlock features on our channels?

• User gets rewarded by creator Token X on Platform X
• User comes to Atlas and exchanges Token X for NFT, Subscription, Creator's Token or JOY. The creator accepts this token because it is already part of their personal ecosystem of tokens that they and their community value.

3. ENS domains integration as a way to target Ethereum users that are already crypto native but don't have a video platform yet. This also adds modularity as ENS domains accepts payments from multiple networks including Polkadot. The drawback is that it is limited to those with an ENS address. I see it as a way to bridge people having jpg or gif NFTs on Ethereum and Video NFTs or Vlog on Atlas

[bedeho]

I'm closing this, a more narrowly defined and concrete proposal should be submitted if still relevant.