[Discussion]: Schemas v2

[wilwade]

Feature Description

There are various ideas about how to improve Schemas. Let's discuss and find a way forward on it.

• Schemas have three implied and real pieces
  • Protocol namespace (dsnp and frequency on Mainnet)
  • Schema (dsnp.update for example)
  • Schema Version (dsnp.update v1 and v2 for example)
• Delegations are at the Schema Version level, the other levels are merely structure
• Protocol authors cannot upgrade independent of new schema version and asking each user to approve

Concerns/Tradeoffs

• How can users be protected from bad schema upgrades?
• How can users not be bothered by schema upgrades that have only structural differences?
• How can the delegation model be improved/changed to handle the multi-layer schema structure (specifically different versions)?
• How can the interaction model with schemas be unified and simplified (even at the expense of complexity in schema creation)?
• How can the Ethereum integration work align with these changes?

Searched for Related Issues

• [x] I have done a search for related issues and either found none, or noted them

[wilwade]

Community Call Notes for 2025-03-20

• Ideas
  • Schema patterns Examples: dsnp.update@*, dsnp.update@v3+, etc...
  • Semantic versions?
• Allowing trust is in the Protocol instead of the specific schemas
• Things to think about
  • Trust level
  • Security aspects of the specific schemas
  • Cost of checking a delegation needs to be efficient
    • Cost for checking before an on-chain write
• This is close to a Terms of Service Update
• Is there a path where the user doesn't need to be aware of version changes and improvements

Schema Grouping

Outcomes Moving Forward

• Users should not need to approve new versions of a schema
  • Where new versions of a schema are not changing the intent of the schema
  • Outcome: Schema versions should be restricted to updates that do not change the intent
  • Outcome: Users should NOT need to approve a specific schema version
  • Note: A simple schema version integer system works well with this
  • Question: Is it possible to delegate only a specific version? NO.
  • Note: Currently it will be the responsibility of Frequency Governance to ensure that the update does not change the intent

[JoeCap08055]

Implementation notes:

• Currently, names are loosely/optionally associated with a schema. In order to implement protocol-level delegation, schema names would become a mandatory part of schema creation/deployment.
• Currently, extrinsics that require a schema have it specified as a numeric ID corresponding to a specific schema version
  • Q1: Do we need to modify/augment storage so that it is (easily) possible to reverse-map a specific schema version to its protocol name
  • Q2: should we move toward a model where schema arguments in extrinsics are specified as a namespace.protocol@version (or, possibly, a numeric protocol ID + numeric version?) instead of a specific schema version?
  • Q2.1: Following from that, should we have pallet storage registering an ID for <namespace.protocol> (or perhaps separate storage for and )?

[wilwade]

Closing for #2312