fix(server): read lite PoP names in both their dotted and flattened forms - #602
Merged
Conversation
filip-parity
changed the title
filip-parity
requested review from
TarikGul,
filvecchiato,
re-gius and
valentinfernandez1
September 4, 2026 09:23
valentinfernandez1
approved these changes
Sep 4, 2026
|
Do not merge until #275 is finalized and deployed |
Contributor
Author
re-gius
reviewed
Sep 7, 2026
There was a problem hiding this comment.
There were some late changes in paritytech/dotns#275 which are not reflected in this PR - please address them
valentinfernandez1
enabled auto-merge
September 7, 2026 13:23
…orms DotNS is moving lite names from the flattened alice42 to the stored dotted form alice.42; deployed contracts still flatten. The read path now accepts both: classify_labels keeps a dotted stem.NN label verbatim and still re-dots flattened storage, and bare_store_label lets a dotted lite label through the TLD strip instead of dropping it as a subname. Also bounds the lite check by the gateway's real limit: LiteLabelOwner is keyed by the dotted label as a 32-byte BaseLabel, so the old stem+2<=32 flattened bound accepted a 30-char stem the pallet cannot decode. is_dotted_lite_username now caps the dotted form itself.
Reflects paritytech/dotns#275: classify_labels asks the PoP controller for issuance provenance before a label fills a username slot, the lite stem follows the letters-only person rule, and the flattened spelling is no longer read as a lite name. The live store test asserts provenance for dotted survivors.
filip-parity
force-pushed
the
fix/dotted-lite-labels
branch
from
September 8, 2026 04:59
9e22d65 to
96ebd50
Compare
re-gius
approved these changes
Sep 8, 2026
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
3 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.
TL;DR
DotNS is moving lite names from the flattened
alice42to the stored dotted formalice.42(paritytech/dotns#273); every deployed contract still flattens, so the read path accepts both spellings:classify_labelskeeps a dottedstem.NNlabel verbatim and still re-dots flattened storage, so nothing changes against today's chains and dotted deployments work as soon as they exist.bare_store_labellets a dotted lite label through the TLD strip instead of dropping it as a subname.is_dotted_lite_usernamenow bounds the dotted form itself:LiteLabelOwneris keyed by the dotted label as a 32-byteBaseLabel, so the old flattenedstem+2 <= 32bound accepted a 30-char stem the pallet can't decode.One inherited ambiguity is documented in the code: a depth-one subname under a digit-only parent (
app.42) is indistinguishable from a dotted lite name; digit-only second-level names are governance-only.