Registry Proposal Process ◈︎

AIOSchema Registry Proposal Process

Version: v0.5.6 Status: Active

What Can Be Proposed

A new official extension field (no vendor prefix, listed in /registries/extensions/)
A new vendor prefix registration (x-<vendor>-)
A new anchor service registration (/registries/anchor-services/)
A new hash or signature algorithm

Requirements Before Submitting

For an official extension field:

The field name MUST use snake_case and MUST NOT conflict with any existing Core Block field or registered extension field.
The field MUST have a defined type, requirement level (MUST/SHOULD/MAY), and description.
The field MUST NOT carry personally identifying information in a public manifest context.
A reference implementation demonstrating the field SHOULD be provided.

For a vendor prefix:

The prefix MUST be unique and not in use by any other registered vendor.
At least one field under the prefix MUST be documented at submission time.
Commercial use requires a registry license agreement.

For an anchor service:

The service MUST publish a discovery document at https://<service-domain>/.well-known/aioschema-anchor.json.
The service MUST be publicly verifiable and independent of the content author.
The service MUST produce immutable, timestamped records.

How to Submit

Submit proposals via the GitHub repository issue tracker:

https://github.com/aioschema/aioschema/issues

Use the label registry-proposal. Include:

Proposal type (field / vendor prefix / anchor service / algorithm)
Full field or prefix name
Type and description
Rationale
Reference implementation or documentation URL (if available)

During the founder-controlled phase, the founder reviews and approves all proposals. Upon Foundation establishment, a formal review process will be defined.

IPR

All accepted contributions to the registries are subject to the Royalty-Free IPR commitment. See /ipr/.