feat(server): make the reserved people rings usable without registration - #371
Open
filvecchiato wants to merge 24 commits into
Open
feat(server): make the reserved people rings usable without registration#371filvecchiato wants to merge 24 commits into
filvecchiato wants to merge 24 commits into
Conversation
This branch forked before chain.get_chain_info landed on main claiming request id 166, so the three RFC-0024 account methods were allocated the same id. Shift them to 168/170/172 and leave 166 free for the chain method arriving on merge. Regenerates the server wire table and updates the codegen golden.
Chain the two follow-alias resolvers in chain_runtime so a product-scoped alias resolves against pending intents and awaits setup before binding to the transport follow. Point the getAccountAlias example at chain.getChainInfo, and reach the platform through RuntimeServices in the ring VRF paths. Wire ids: chain.getChainInfo 166, ring VRF 168/170/172.
Resolve through the connection's sticky alias binding first, so pending intents only cover a request that beats follow setup. A second follow on a chain made the intent lookup ambiguous and failed every aliased operation on it.
PeopleCollection names the two reserved peopl.dot rings, mapping each to its 32-byte collection id, derivation index and ring location. Both are listed, resolvable for proofs and signatures, and selectable as providers without an RFC-0024 registration. Reserved member keys are disclosed only to peopl.dot; other callers get the handle and its ring. Rings outside a collection still fall through to the registry.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #360, addressing @valentunn's review note: keep the well-known light/full people ring keys usable so other products can use ring-VRF features until Humanity takes over key management.
Stacked on
codex/rfc0024-integration— the diff only reads clean once #360 merges.What it does
PeopleCollectionnames the two reservedpeopl.dotrings and maps each to its 32-byte collection id, its derivation index and its ring location on the configured People chain:pop:polkadot.network/people(space-padded)peopl.dotindex 0pop:polkadot.network/people-litepeopl.dotindex 1Both are listed, resolvable for proofs and signatures, offered as providers and selectable as one — no RFC-0024 registration required. A ring outside either collection still falls through to the registry, so an explicit registration continues to decide whether a handle covers it.
A reserved member key identifies which ring member the user is, so it is disclosed only to
peopl.dotitself. Other callers receive the handle and its declared ring, which is what provider selection needs.Reserved handles are recognised through their derived index bytes, so a
Rawindex naming the same key resolves the same way.statement_allowance::ringreads the lite collection id from the shared constant instead of repeating the literal.Verification
cargo +nightly fmt --checkandcargo clippy -p truapi-server -p truapi --all-targets --all-features -- -D warningsare clean.cargo test --workspace --all-featurespasses, 514 intruapi-server.Both native hosts were checked for parity. The collection ids match Android (
RingCollectionId.paddedString) and iOS (PeoplePallet+Members.swift) byte for byte. Both key these rings off the account holding them rather than a derivation index, so member keys are not portable across hosts — only the collection ids are shared. Neither host has a registration step, and neither exposes a personhood-active signal this core could gate on, so both collections are offered unconditionally and ring membership stays a chain question.Separate finding for #360
HostAccountCreateProofErrorandHostAccountGetAliasErrorgain three variants ahead ofRejectedandUnknown, shifting their SCALE discriminants.triangle-js-sdkscarries the four-variant form (packages/host-api/src/protocol/v1/accounts.ts), so against a host on that branch a declined proof decodes to nothing andKeyNotRegisteredreads asRejected. Appending the new variants, or pinning#[codec(index = N)], avoids it. Not addressed here.