Skip to content
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.

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

Consider adjustment to TXT RData format #79

Closed
mistermoe opened this issue Jan 3, 2024 · 1 comment · Fixed by #86
Closed

Consider adjustment to TXT RData format #79

mistermoe opened this issue Jan 3, 2024 · 1 comment · Fixed by #86
Assignees
Labels
enhancement New feature or request

Comments

@mistermoe
Copy link
Member

image

context: I'm in the middle of implementing did:dht in dart.

Is there any rationale behind _did.TLD storing all the relationships? parsing a TXT record that into a DID Document could be O(n) if each _kN_did. had a rel (relationships) property e.g. rel=auth,asm vs. having to look up the relationships in the root entry.

@mistermoe mistermoe added bug Something isn't working and removed bug Something isn't working labels Jan 3, 2024
@mistermoe mistermoe changed the title Rationale behind using TXT RData structure Consider adjustment to TXT RData structure Jan 3, 2024
@mistermoe mistermoe changed the title Consider adjustment to TXT RData structure Consider adjustment to TXT RData format Jan 3, 2024
@decentralgabe
Copy link
Member

your point is correct. the design was chosen because I saw the biggest risk to the TXT size limit of being a key + a key ID. this is why there's guidance on suggested KIDs.

having longer TXT records is possible, but awkward, and I did not want to risk dealing with variations in tooling (still may have to). so - anything to reduce the size of a single record is 👍

that and I believe it's worth it to separate out relationships from key definitions, as is done in DID core itself (see verification methods opposed to verification relationships.

marking this as pending close

@decentralgabe decentralgabe added the pending-close will be closed soon! label Jan 3, 2024
@decentralgabe decentralgabe self-assigned this Jan 5, 2024
@decentralgabe decentralgabe added enhancement New feature or request and removed pending-close will be closed soon! labels Jan 5, 2024
@decentralgabe decentralgabe moved this to In Code Review in SDK Development Jan 5, 2024
@github-project-automation github-project-automation bot moved this from In Code Review to Done in SDK Development Jan 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Done
2 participants