Design Doc: Schemas, Intents, and Delegation Groups #2312

JoeCap08055 · 2025-04-04T19:37:46Z

Description

In the current implementation, schemas are registered with immutable numeric identifiers (SchemaId) and describe the layout and storage semantics (e.g., Avro/Parquet formats, on-chain/off-chain storage). These schema IDs are used as references by clients and runtime modules alike, particularly in the delegation system defined by the msa pallet.

Delegations currently allow a user to authorize a provider (e.g., an app or service) to act on their behalf, but this authorization is tightly bound to a specific SchemaId. This model has proven limiting in several ways:

Coupling between specific schema versions and delegations
Schemas represent data format, not purpose
Lack of human-readable context

These limitations have motivated a re-architecture of the schema and delegation systems to introduce the concepts of:

Named intents with schema version tracking
Intent-based delegation
More expressive APIs and storage models

Closes #2265

- old SchemaId -> SchemaVersionId - protocol -> schema - namespace -> protocol

JoeCap08055 · 2025-07-14T14:39:40Z

Additional question/discussion point:

(Thinking mostly about on-chain storage like Itemized and Paginated, but could maybe also apply to off-chain storage locations like IPFS)

Currently, on-chain storage is stored in a storage child trie with the specific schema version id as part of the key. This made complete sense given that, at the time, there was no way to associate on schema version with another as being representative of minor variations of the same data format.

However, with the advent of an encapsulating Schema for which individual Schema Versions are merely minor format changes, would it make sense to reorganize on-chain storage such that the on-chain storage references the Schema, rather than the Schema Version, and simply includes the Schema Version as a record header? This would have the following effects/benefits/drawbacks:

Increase item/page overhead in storage by 2 bytes (u16) per item (Itemized) or page (Paginated) stored
Make schema version upgrades simpler and avoid hefty migrations and other edge cases. For example:
- Currently, for even a minor/trivial format change that requires publishing a new schema version, the following scenarios must be accounted for:
  - Which, of multiple Providers, bears the responsibility of migrating a user's data from the old schema version to the new one?
  - How to avoid race conditions in migrating a user's data between schema versions?
  - It is possible that a user's data could become bifurcated; that is, new records start to be written to the latest schema version before the old records in the prior version have been migrated; how then to know what the proper state is?
    Example (using a user's graph as a proxy for the generic on-chain storage):
    - User 'Alice' has delegations to Provider A. Alice's graph contains Bob and Charlie in Schema Version 1.
    - Schema version 2 is published
    - Alice onboards with Provider B, who requests a delegation for Schema Version 2. Provider B's application does not handle older schema versions.
    - Alice adds Dave to her graph via Provider B, who writes it to a new page in Schema Version 2.
    - Now, Alice has graph pages in both Schema Versions 1 & 2. Does 2 supersede 1? Or does 1 still need to be merged into 2?
    - The onus, therefore, is on the Provider app to always check to see if there is a new (empty) schema version for the graph data, and either (a) avoid writing new data until migration is complete, or (b) perform a migration of the user's entire graph before writing new data. This is difficult (at the least expensive) to enforce on-chain.
    - TL;DR: Currently, the only way to know if a user's graph has been upgraded is the presence/absence of data in the new schema version. If any data exists in the new version, it is impossible to know if that was the result of a full migration of the user's graph from the older version, or a one-off update/write to the new version. Requiring this scenario to be managed by a Provider app is unrealistic.
    Now, if on-chain storage were indexed by Schema instead of Schema Version, we would get something like the following:
    - Alice has Bob & Charlie in her graph on Page 1. Page 1 is written with Schema Version 1, for the schema dsnp.private_follows
    - Schema Version 2 is published for dsnp.private_follows
    - Alice adds Dave to her graph via Provider B.
    - Provider B reads the graph according to dsnp.private_follows and decodes according to schema version 1 (from the page header).
    - Provider B writes a new Page 1 containing Bob, Charlie & Dave, using Schema Version 2 (and indicating so in the page header).
    - Other graph pages may still be using Schema Version 1, until either opportunistically rewritten during a graph update, or a Provider may choose to proactively update all pages for a user.
    - TL;DR: In this model, migrations to new schema versions may be performed opportunistically, en masse, or not at all, at the Provider's discretion. (Granted, the prior scenario still exists if there is a major (ie, material) change to the data format such that a new Schema (not Schema Version) is published, but this scenario should occur much less frequently.)

Thoughts?

designdocs/schemas_protocols_intents.md

enddynayn · 2025-07-14T17:56:56Z

designdocs/schemas_protocols_intents.md

+
+- New schemas must be approved by governance
+- Minor updates (new schema version) may be published by the protocol owner
+- Major updates require a new schema (e.g., change in semantic intent)


Is the decision of what qualifies as a major update entirely at the owner’s discretion, with no on-chain enforcement or challenge mechanism?

Since this doc is being revised to defer the concept owner publishing capabilities and make everything a governance action (for now), the major/minor distinction will be validated by governance.

Whether a programmatic determination can ever be made in this regard may determine the fate of an ownership publishing (without governance) capability.

enddynayn · 2025-07-14T18:03:25Z

designdocs/schemas_protocols_intents.md

+### 👤 Ownership and Control
+
+Protocols are envisioned to be owned by an entity, but there is an open question as to whether this entity should be an
+MSA (i.e., a Provider) or a raw account (i.e., a public key). This decision will impact how access is managed,


Thought: One of the advantages of MSAs is that, in theory, we can attach permissions to them. This would allow governance to add keys with limited access, which is especially valuable for organizations that need to delegate responsibilities. Being able to grant keys with restricted functionality becomes even more important in these contexts.

Interesting. Probably the subject of a separate design or issue, but the idea of adding a control key with explicit/limited rights is intriguing... though, delegations could accomplish the same thing.

aramikm

Great work but it's hard to capture all the side effects and issues that might come with this by only reading this proposal. It might make sense to do a quick and dirty POC and check the weights and see some code.

aramikm · 2025-07-14T20:54:24Z

designdocs/schemas_protocols_intents.md

+- A new schema version ID is automatically assigned the next version
+- Older versions are preserved permanently
+- Delegations may apply to the schema, not a specific schema version ID
+- _Question: can versions be deprecated?_


I think we should mention the max number of versions we support to be stored on chain.

I believe that's currently a config value & likely will not change, but I'll add a mention of it.

aramikm · 2025-07-14T21:06:12Z

designdocs/schemas_protocols_intents.md

+
+```rust
+pub enum DelegationTarget {
+    SchemaVersion(SchemaVersionId),


current SchemaVersionId type is not a well defined structure and it's just an array of the SchemaIds and it doesn't have any id attached to it. I'm not sure how it would work if we don't have any canonical registration or identifier for them.

Actually SchemaVersionId is what current Frequency calls SchemaId and is just a u16

aramikm · 2025-07-14T21:09:31Z

designdocs/schemas_protocols_intents.md

+pub type Delegations<T> = StorageDoubleMap<
+    _, Blake2_128Concat, MsaId,           // Delegator
+    Blake2_128Concat, ProviderId,         // Provider
+    BoundedVec<DelegationInfo, MaxDelegationsPerProvider>


We would need to know the max encoded size of DelegationInfo and that would have an effect on how many maybe we should fit in a BoundedVec or maybe we might need a different structure if it's too big.

There are 2 things to consider here:

If we ignore DelegationInfo, and simply store delegations the way we currently do, using a BoundedBTreeMap, with a DelegationTarget enum key instead of a SchemaId (u16), here are some back-of-napkin calculations:

current max storage for 30 schema delegations (current per-delegation max): ~180 bytes

max storage for 30 delegations of DelegationTarget: ~211 bytes

However, our current delegation storage has some deficiencies; namely, we can know that a Schema is currently delegated, or when it was revoked, but we cannot know when that delegation started (because we only store a revoked block number or zero). The new DelegationInfo struct allows us to store that information. To store 30 delegations (we probably would need to use BoundedVec instead of BoundedBTree due to the way we would need to do lookups), would cost ~361 bytes, so effectively double the storage we currently use for delegations.

aramikm · 2025-07-14T21:23:47Z

designdocs/schemas_protocols_intents.md

+
+### 🧪 Additional Considerations
+
+- In the future, extrinsics may support intent-based authorization **without referencing a schema** at all. These would


Intent based authorization would cause some issues and would solve some issues.

Cons:

It would allow actions being done on behalf of the user even if the user doesn't specifically gave permission for those. (Imagine a new schema gets registered with the delegated intent but the user actually doesn't want to do delegation for that new schema but since it already gave intent based auth it can not do anything)

Pros:

it would allow smooth evolvement of protocol without asking for extra permissions for each change.

Some additional thoughts about intents... I think probably we need to have a discussion dedicated to the topic, since there seem to be as many problems created as solved:

Namespaced intents mitigate the "con" above... somewhat. However, they would still involve an element of trust, that the owner of a namespaced intent does not evolve the protocol in ways that are not aligned with the original purpose

The next version of this doc (in progress) will remove/defer the concept of "ownership" and revert all actions regarding Schemas and Intents to governance approval. While this also mitigates the concern above, (1) it may put too much burden/trust on governance, and (2) still leaves an open question of how to handle things if/when "ownership" of intents/schemas is later implemented

Delegation via intents has implications both on-chain and off-chain:

on-chain: looking up a delegation via intents has storage read implications that would affect weights. Mitigating this would require new extrinsics that include the IntentId in addition to SchemaVersionId

off-chain: validating posted (or to-be-posted) content against delegations requires additional work, though this can be mitigated by providing custom runtime calls or client library functions to facilitate the lookup

Intents have an added benefit of being able to represent arbitrary permissions, whether related to a Schema or not. The current delegation model represents ONLY a singular "allow delegated WRITE to schema_id" permission. Intents could represent READ permissions as well, such as "allow access to users's graph key" that an off-chain wallet or other software could query.

I think the question of whether or not to implement Intents comes down to answering the following questions:

Is it reasonable to ask a user to grant an Intent delegation if there is no way (other than chain governance controls) to prevent the Intent from being evolved in unknown ways?

Are we willing to deprecate the existing chain API for the messages and stateful_storage pallets such that IntentId becomes an input to extrinsics that formerly required only a SchemaId?

And a follow-on:

If we decide to implement Intents, how are they managed? The choice has implications for pallet storage and delegation lookup weight impact:

Intent->Schema associations are managed through the Intent itself

Schema->Intent associations are managed through the Schema (and therefore immutable from the Schema's perspective)

SchemaVersion->Intent associations are managed as metadata in each published SchemaVersion (and therefore mutable between SchemaVersions)

We're going to defer the concept of Intents for now; I'll separate it out to a separate issue for tracking.

I've re-thought the concept of Intents. The problematic part of Intents was the ability to associate an Intent with a group of related (not versioned) schemas, ie ['broadcast', 'reply', 'react']. If we restrict Intents to a list of versions of the same basic schema, then the problematic aspect goes away, and we can still avoid delegation churn.

TL;DR:
Previous version of this doc: protocol -> schema -> [schema@v1, schema@v2,...]; intent a separate entity where intent -> [schema A, schema B, ...]

New version: protocol -> intent -> [schema@v1, schema@v2, ...]

New version makes a lot more sense to me, too.

aramikm · 2025-07-14T21:54:11Z

@JoeCap08055 I can see that might be helpful if we consider the abstraction and generic usecase of stateful storage but I can not see why we might want to change the graph related schemas.

My 2 cents are that if we don't have to do it we probably should not try. The reason is that even though it might be beneficial for generic case it's problematic for graph which is 99% of the actual use of the stateful storage for us.

We would need a deeper discussion about this.

enddynayn · 2025-07-15T21:50:37Z

I really like the direction we’re heading with minor schema updates. It should make the update process more efficient and easier for providers to manage.

That said, I think the concept of Intents could use some additional discussion. It might bring back some of the same challenges we previously encountered with updates. For instance, if a provider wants to add a new schema to an existing intent, it could unintentionally trigger an update.

There are a few potential ways to address this, but each comes with trade-offs that might not be worth it.

I am looking forward to hearing other thoughts on how we want to approach intent.

JoeCap08055 · 2025-07-16T16:16:20Z

designdocs/schemas_protocols_intents.md

+- **protocol** - the top level of the tripartite nomenclature _protocol.schema@version_ (ex: _dsnp_ is the protocol in
+  _dsnp.broadcast@v2_)
+- **schema** - the second level of _protocol.schema@version_ (ex: _dsnp.broadcast_ resolves to a specific schema).
+  Schemas should always be referred to by their fully-qualfied name (ie, _dsnp.broadcast_, not just _broadcast_)
+- **version** - the third level of _protocol.schema@version_, resolves to a specific _minor_ iteration of a schema
+- **intent** - an on-chain primitive representing an abstract action or operation


Looking for some comments on naming.

I was initially in favor of: Namespace->Protocol->Schema; however, apparently "Protocol" for the 2nd level was rejected...?

@wilwade suggested Protocol->Schema->SchemaVersion. However, already in conversations it's clear that Schema vs. SchemaVersion is very confusing.

I think perhaps we should keep the third level as it currently is, Schema, to avoid renaming/cognitive shift. I've got some suggestions here for the other levels:

Level 1: Namespace, Domain, Package, Module, Scope, Protocol
Level 2: Model, Template, Component

Happy to consider others...

naming is hard 😬

Hmm... what if we did:

Domain -> analagous to ENS Domain; will be an easy conversion if we ever implement/move to ENS

MetaSchema

Schema

This eliminates the confusion whereby L2 points to "versions" (would be confusing if "versions" of a Model, for instance, were called Schemas). So a MetaSchema points to "versions" that are Schemas

Idea based on a re-read:

Protocol -> Intent -> Schema

Effectively remove "version" as a concept (force it to be a part of the name) and instead just have deprecated schemas.

So for example something might look like this eventually:

Protocol: DSNP
Intent: Graph
Schema: dsnp-private-connections (deprecated)
Schema: dsnp-private-connections-v2
Permission: dsnp-private-graph-read (future support for permissions, not part of it for now)

I think this works for all existing mainnet schema.

wilwade · 2025-07-21T15:09:33Z

designdocs/schemas_protocols_intents.md

+- Delegation by `SchemaId` (existing/legacy, for future deprecation)
+- Delegation by `IntentId` (implies all schema versions within the Intent)


I would be ok with just migrating all the Schemas that are currently in use to "Intents" that have just one schema. That way we don't have to handle the dual setup

🤔 I think that might work...

wilwade · 2025-07-21T15:13:17Z

designdocs/schemas_protocols_intents.md

+- `RegisteredAt`: Block number
+- `Versions`: [optional] Ordered list of `SchemaId`s (e.g., `[7, 15, 27]`, for versions 0..2)
+
+### 🧬 Versioning Rules


What if we dropped versions and instead just did schema deprecation tagging?

Not sure I understand. Elaborate?

I have a bit more here: #2312 (comment)

Versions imply a semantic that we might not want to imply. Also some protocols might use other ways of versioning than int incrementing.

Effectively with Intents, we can just say "here are all the schemas for this intent and these ones are flagged as deprecated"

The schema naming we do could also be updated. With named Protocols and Intents, the only reason to name schemas is for ease of developer integration across mainnet and testnets.

saraswatpuneet · 2025-07-21T16:00:27Z

designdocs/schemas_protocols_intents.md

+// Q: Is this necessary as a separate map, or can be folded into the `IntentInfo` struct?
+pub type IntentVersions<T> = StorageMap<
+    _, Blake2_128Concat, IntentId, BoundedVec<SchemaId, MaxSchemaVersionsPerIntent>
+>;


any reverse mapping needed here?

Depends. I think we would store the parent IntentId in the SchemaInfo struct. So to get the reverse mapping of SchemaId -> IntentId would require 1 read; it's really a question of whether it's worth the optimization to read just a u16 vs. an entire struct, vs the extra storage map.

I see, so we are BoundedVec<SchemaId, MaxSchemaVersionsPerIntent> which are schema ids, this could use some renaming from IntentVersions, it could be a common state call for schema management

designdocs/schemas_protocols_intents.md

saraswatpuneet · 2025-07-21T17:41:54Z

designdocs/schemas_protocols_intents.md

+3. **Submit by IntentId only (No Schema):**
+
+    - Enables non-schema-based actions (e.g., future custom actions)
+    - Runtime must validate delegation by `IntentId`


from blockchain perspective, keeping things minimal, why we should support multiple ways to publish other than schemaId? that's more granular for the chain and can enforce some provider side management or a library from us for schema management .

Edit: On second thought, if we want to enable publishing against an intent, these could be good apis add to gateway service which can internally resolve schema id to use, reducing additional work here

For clarification:

You publish to a SchemaId; you delegate to an IntentId. Schemas implement Intents. After thinking about it some more, I realized that any extrinsic that publishes to a Schema already has to read the SchemaInfo metadata to do some basic validation. So if the IntentId is part of that metadata, we don't even need an extra read to look it up to validate the delegation. Thus our existing extrinsic model of just passing SchemaId can remain.

Publishing to a schema on-chain, then, would look like:

Read SchemaInfo by SchemaId

Basic validation (ie, storage location)

Get IntentId from SchemaInfo

Query delegations for IntentId just as we currently would for SchemaId

I'll update the doc to make ☝🏻 more clear

Thanks for the clarification, so there will be some changes on schemas pallet and subsequent migration of schemas to record intent_id

Co-authored-by: Shannon Wells <[email protected]>

JoeCap08055 · 2025-07-22T14:52:15Z

Additional simplification:

Since we've already removed the concept of ownership (deferred until future implementation of ENS and DAO on Frequency), the concept of a "Protocol" or "Namespace" as a primary entity seems superfluous. It can easily be introduced later with minimal effort if we want, but for now it seems sufficient to keep a model similar to the current on-chain storage for schema names; ie a double map protocol/namespace -> intent name -> IntentId

Thoughts?

shannonwells · 2025-07-23T00:30:35Z

Schema versions

I think there needs to be a way to reject messages for unsupported versions, i.e. ones that are past "deprecation". If app developers don't have to upgrade, it's guaranteed that some never will, and it seems that for social graph in particular, that will cause problems. I would want to see another field indicating whether the schema version is still valid for the protocol, and Gateway could even reject messages for that version if it's no longer supported. Maybe that feature doesn't need to be part of this design doc though. I thought we had discussed schema states at some point, like - current --> deprecated --> readonly.

In your example, what if Provider A just insists on updating the graph using Schema v1 while everyone else is using Schema v2? Then I guess it's left to the user to figure out how to pressure Provider A to upgrade to the new version, or withdraw their delegation & stop using the app?

Governance trust

This is getting even more off-piste, but I think it would be a good idea to push out announcements for these types of changes to end users. At first I thought should be a DSNP message type that is basically a system announcement (e.g. ProtocolChange, SchemaUpgrade, etc) but really, a Broadcast would be fine, and wouldn't require Providers to make any code changes.

So Frequency Foundation can have a Provider account and post messages that can be picked up by any other Provider. Those users can go and vote on it (if they have rewards) or at least look at it, and decide what to do, if anything.

aramikm · 2025-07-23T17:49:01Z

designdocs/schemas_protocols_intents.md

+To mitigate these issues, we will store data indexed by `IntentId` instead of `SchemaId`. This will require the
+encapsulated storage payload to contain an additional piece of meta-information; specifically, the concrete `SchemaId`
+that was used to format the encapsulated data.


I'm not sure if I understand this correctly. Would you mind elaborate more on this?

aramikm · 2025-07-23T17:52:11Z

designdocs/schemas_protocols_intents.md

+For the `stateful-storage` pallet, it would be necessary to re-write all storage pages to include the concrete
+`SchemaId` in the page header. How to accomplish this for ~1M user graphs and graph keys on-chain requires further
+analysis.
+


I'm still not sure why we need to do this for graph schemas. How often do they really change?

It's not specifically graph data; that's merely the main data that currently uses that pallet. In future, I imagine other sorts of data will also use stateful-storage; the point is on-chain data is expensive to migrate, so minimizing the impact of minor storage format changes so that migrations aren't required seems like a valuable change to make early on.

shannonwells · 2025-07-22T23:58:16Z

designdocs/schemas_protocols_intents.md

+- Intents must be approved by governance, and are immutable except for appending new SchemaIds to the version list
+- New Schemas must be approved by governance
+- Minor Schema updates (semantic-preserving format changes, etc) may be approved for the same Intent
+- Major updates (change in meaning or semantics, or significant breaking format change) require publishing under a new


How is "major updates" rule enforced, with governance? Are we assuming, for example, that the Council have the ability to reject proposals for a radically different schema version?

JoeCap08055 · 2025-07-30T14:53:58Z

designdocs/schemas_protocols_intents.md

+StorageMap<_, Twox64Concat, DelegationGroupId, DelegationGroup, OptionQuery>;
+```
+
+#### Name Registry


One note for discussion:

Instead of a monolithic name registry, we could define Protocol as a first-level storage entity with an ID and a name mapping name->ProtocolId; then define separate maps (ProtocolId, Descriptor) -> IntentId, and (ProtocolId, Descriptor) -> DelegationGroupId

Not sure what that buys us, but it's an option.

One thing it buys is smaller, cheaper extrinsic payloads when creating/updating Intents and DelegationGroups--instead of passing both payload and descriptor names, could pass just ProtocolId and descriptor name.

saraswatpuneet · 2025-07-30T17:46:42Z

designdocs/schemas_protocols_intents.md

+structure that will require migration:
+
+* `payload_location`  & `settings` will migrate to `IntentInfo`
+* addition of `intent_id`


nit: a separate section for migrations would be useful but assuming this is mostly migrating SchemaInfo but anything on delegation side ?

saraswatpuneet

Looks good!

nit: a section for rpcs or runtime api, if any, would be useful

Edit: noticed a separate section for runtime calls, looks good 👍🏽

shannonwells

This seems to cover all the bases well, looks good now!

JoeCap08055 · 2025-07-30T21:01:07Z

designdocs/schemas_protocols_intents.md

+    1. For each `SchemaNamespace` '\<protocol_name>'
+        1. For each `SchemaDescriptor` '\<name>' at index `n` belonging to a '\<protocol_name>'
+            * Create a new name mapping in the `NameRegistry` as `<protocol_name>.<name>_n` to `Intent(id)`
+3. Store the `messages` pallet cutover block number


Optionally could seed the chain with some pre-defined Delegation Groups as part of the migration.

JoeCap08055 added 4 commits April 4, 2025 15:34

feat: draft design doc for Schemas 2.0

eb73a94

design doc edits

d981fc7

add open question: to ENS or not to ENS?

4ec8bcd

add to README

9b84448

JoeCap08055 mentioned this pull request Apr 8, 2025

Design Doc: Provider Contexts #2311

Merged

wilwade added the discussion Topic for Discussion at a Community Call label Apr 16, 2025

fix: nomenclature revisions

f89b4ee

- old SchemaId -> SchemaVersionId - protocol -> schema - namespace -> protocol

wilwade mentioned this pull request Jul 3, 2025

[Discussion]: Schemas v2 #2265

Closed

1 task

Merge branch 'main' into design/schemas-protocols-intents

0cf5bf8

enddynayn reviewed Jul 14, 2025

View reviewed changes

designdocs/schemas_protocols_intents.md Outdated Show resolved Hide resolved

enddynayn reviewed Jul 14, 2025

View reviewed changes

aramikm reviewed Jul 14, 2025

View reviewed changes

JoeCap08055 commented Jul 16, 2025

View reviewed changes

wip: revamp, remove ownership and rewrite concept of Intents

1af7c9d

wilwade reviewed Jul 21, 2025

View reviewed changes

fix: clean up and resolve terminology and link inconsistencies

7db843b

wilwade reviewed Jul 21, 2025

View reviewed changes

saraswatpuneet reviewed Jul 21, 2025

View reviewed changes

JoeCap08055 added 2 commits July 21, 2025 12:23

add note about archive node

ef629e1

Merge branch 'main' into design/schemas-protocols-intents

805cb7d

shannonwells reviewed Jul 21, 2025

View reviewed changes

designdocs/schemas_protocols_intents.md Outdated Show resolved Hide resolved

shannonwells reviewed Jul 21, 2025

View reviewed changes

designdocs/schemas_protocols_intents.md Outdated Show resolved Hide resolved

saraswatpuneet reviewed Jul 21, 2025

View reviewed changes

JoeCap08055 and others added 3 commits July 21, 2025 14:46

Update designdocs/schemas_protocols_intents.md

2b77552

Co-authored-by: Shannon Wells <[email protected]>

Update designdocs/schemas_protocols_intents.md

aa534c8

Co-authored-by: Shannon Wells <[email protected]>

simplify design and split out issue #2510

b2a4b9e

fix: link

0b335b4

JoeCap08055 changed the title ~~Design Doc: Schemas, Protocols & Intents w/Delegations~~ Design Doc: Schemas & Intents w/Delegations Jul 22, 2025

remove Protocol as an on-chain entity; update migration strategy

5f7bda0

aramikm reviewed Jul 23, 2025

View reviewed changes

JoeCap08055 added this to the Schemas and Permissions 2.0 milestone Jul 29, 2025

shannonwells reviewed Jul 29, 2025

View reviewed changes

JoeCap08055 added 2 commits July 29, 2025 19:56

feat: new iteration of design doc

c87f5ac

Merge branch 'main' into design/schemas-protocols-intents

8eed4f8

JoeCap08055 marked this pull request as ready for review July 29, 2025 23:57

JoeCap08055 changed the title ~~Design Doc: Schemas & Intents w/Delegations~~ Design Doc: Schemas, Intents, and Delegation Groups Jul 30, 2025

add storage info

5f58740

JoeCap08055 commented Jul 30, 2025

View reviewed changes

saraswatpuneet reviewed Jul 30, 2025

View reviewed changes

shannonwells approved these changes Jul 30, 2025

View reviewed changes

saraswatpuneet approved these changes Jul 30, 2025

View reviewed changes

add migration strategy

95c57a8

JoeCap08055 commented Jul 30, 2025

View reviewed changes

JoeCap08055 mentioned this pull request Jul 31, 2025

[Feature]: More expressive parquet schema #2322

Open

1 task


		### 🧪 Additional Considerations

		- In the future, extrinsics may support intent-based authorization without referencing a schema at all. These would

		- Delegation by `SchemaId` (existing/legacy, for future deprecation)
		- Delegation by `IntentId` (implies all schema versions within the Intent)

Design Doc: Schemas, Intents, and Delegation Groups #2312

Are you sure you want to change the base?

Design Doc: Schemas, Intents, and Delegation Groups #2312

Uh oh!

Conversation

JoeCap08055 commented Apr 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Uh oh!

JoeCap08055 commented Jul 14, 2025 • edited by mattheworris Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

enddynayn Jul 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aramikm left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aramikm commented Jul 14, 2025

Uh oh!

enddynayn commented Jul 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JoeCap08055 Jul 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JoeCap08055 Jul 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

JoeCap08055 commented Apr 4, 2025 •

edited

Loading

JoeCap08055 commented Jul 14, 2025 •

edited by mattheworris

Loading

enddynayn Jul 14, 2025 •

edited

Loading

enddynayn commented Jul 15, 2025 •

edited

Loading

JoeCap08055 Jul 16, 2025 •

edited

Loading

JoeCap08055 Jul 16, 2025 •

edited

Loading

saraswatpuneet Jul 21, 2025 •

edited

Loading