Creating and filtering subregistries

In a world where Os are grouped into different subregistries and Bs are expected to commit to a set of subregistries (B needs to execute this commitment step before it can begin sending video to the Os that are a member of the subregistries), a B will have to select subregistries to commit to. The node software could ship with a UI tool that displays the list of all subregistries along with their titles and descriptions (pulled either directly from an on-chain contract or from IPFS using a hash stored on-chain). But how does B decide which subregistries to commit to?

First, we acknowledge that if anyone can arbitrarily create subregistries, then the system can very quickly be spammed with subregistries. As a result, Bs would have a very hard time filtering a massive list of subregistries.

One solution is to incorporate a mechanism for curating the subregistries similar to Althea's use of a global TCR for their mesh network subnets. A global TCR would allow the network to converge on a global leaderboard that ranks subregistries based on perceived quality. However, it doesn't seem optimal for the Livepeer network to converge on a global leaderboard for subregistries since the quality of a subregistry is likely to be context specific i.e. a subregistry containing Os in the eastern US region might be of high quality to Bs that are also in that region, but might be of low quality to Bs that are located in Europe. Bs should pick the subregistries that are the best fit for them. It is unlikely that subregistries will be one size fits all solutions for Bs.

Another solution is for the system to impose a cost for creating a subregistry. For example, a subregistry creator might have to lock X ETH for Y blocks in order for the subregistry to be valid for Y blocks. This cost would at the very least mitigate Sybil attacks that spam the network with useless subregistries.

Assuming that there is some cost for creating a subregistry, why would someone create a subregistry? The creator could create the subregistry contract with a listing renewal fee that is charged on a per block basis (concept borrowed from Althea). If an O wants to be listed in a subregistry it will pay the listing renewal fee which goes to the creator. An O would want to be listed in the most popular subregistries (which might be associated with the most popular geographic regions). The more Os that join a subregistry, the more listing renewal fees accumulated by the creator. If the subregistry does not serve a broadcaster well (i.e. because many Os in the eastern US subregistry are not actually serving output renditions with the latency expected by a broadcaster that is located in the eastern US region) then the broadcaster can commit to a different subregistry. In this situation, any Os that are in that subregistry would exit. Thus, in order to maintain a stream of listing renewal fees, the creator should make sure to curate the subregistry well according to the advertised characteristics of the subregistry (i.e. for a specific geographic region). A more complex DAO governed subregistry could also take the place of the described single creator governed subregistry.

No repository files, tests, or entry points are named. Start with the subregistry scenarios in the issue and the linked Althea TCR reference; done means reaching and documenting a concrete mechanism for creating, filtering, and renewing subregistries, including how Bs select them and how spam is mitigated.