Skip to content

[Discussion]: Schemas v2 #2265

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
1 task done
wilwade opened this issue Mar 6, 2025 · 2 comments · May be fixed by #2312
Open
1 task done

[Discussion]: Schemas v2 #2265

wilwade opened this issue Mar 6, 2025 · 2 comments · May be fixed by #2312
Labels
discussion Topic for Discussion at a Community Call

Comments

@wilwade
Copy link
Collaborator

wilwade commented Mar 6, 2025

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

  • I have done a search for related issues and either found none, or noted them
@wilwade wilwade added the discussion Topic for Discussion at a Community Call label Mar 6, 2025
@wilwade
Copy link
Collaborator Author

wilwade commented Mar 20, 2025

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
Copy link
Collaborator

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 )?

@JoeCap08055 JoeCap08055 linked a pull request Apr 4, 2025 that will close this issue
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
discussion Topic for Discussion at a Community Call
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Design Doc: Schemas, Protocols & Intents w/Delegations frequency-chain/frequency
2 participants
@wilwade @JoeCap08055