--- tags: draft, governance --- # Multiformats Governance :::info This is a very early draft, I am just capturing notes as I go along. It is barely coherent and not ready to review. Proceed at your own risk. ::: Registries are always problematic in that they invite various forms of squatting. When there is no financial gain, squatting is rarely intentional. Rather, someone started a project that didn't turn out to be as useful or successful as they intended, or they don't have the time to work on it that they thought they would, and that entry they registered just lingers. That is not necessarily a major problem if the resource in question is not subject to depletion, but most of the time part of the reason for having a registry in the first place (versus using, say, UUIDs) is precisely that the resource can be depleted or at least because entries may be meaningful and using meanginful entries causes congestion of the resource. Such a resource lends itself to being managed as a (possibly quite simple) commons, and therefore can be made sustainable according to [Ostrom's observed principles](https://foundation.mozilla.org/en/blog/a-practical-framework-for-applying-ostroms-principles-to-data-commons-governance/). ## Elements of Multiformats Governance What is being governed are registrations in `table.csv`, `multibase.csv`, and related resources. In order to register an entry, one needs to provide: * Evidence of two independent implementations * A complete specification of how to encode and decode content matching the entry * Comprehensive tests to evaluate conformance with the specification * A compelling case justifying the addition of the entry, notably explaining why it is a valuable long-term addition to the Multiverse (is that a joke we make?). The angle here is that we need to think on the multi-decades horizon here, especially given the extensive archival use cases to which multi* brings real value. No one can predict the future but an entry that is clearly unlikely to be useful beyond the immediate future should not be considered. Registrations are evaluated by the Multi Stewards (do we have them?). Existing entries that do not match the above criteria should be considered for removal. An entry can be removed by providing evidence to the Stewards that it does not match the above requirements, and ideally by showing that it is not being relied upon in real-worl content. (This may be difficult to establish though.) Intents to remove should be widely announced in MF channels and a two weeks notice should be given for the community to object. All substantive community objections must be addressed by the removal proponent or other interested parties. After an entry has been removed, its prefix is considered reserved for a year so that the decision can be easily reverted in that period should the need arise.