-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
DID
: Decentralized identifiers (DIDs) (XLS-40):
#4636
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some comments. Biggest issue, IMO, is the lack of any invariant checks. You should consider what types of checks make sense to code up.
src/ripple/app/tx/impl/DID.cpp
Outdated
if (uri->empty()) | ||
{ | ||
sleDID->makeFieldAbsent(sfURI); | ||
} | ||
else | ||
{ | ||
(*sleDID)[sfURI] = *uri; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should be able to just reduce this if
/else
with:
(*sleDID)[~sfURI] = ctx_.tx[~sfURI];
Notice that you don't check if one or both the URI and DATA fields are being set to the same value that they already hold; so it's possible for someone to "update" the object while making no change. You may want to elide the call to update
in that case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that reduction works.
What I want is: do nothing if the field doesn't exist in the transaction, delete the field if the field is an empty string, and replace it in any other case.
What my understanding of that line of code is: delete the field if it doesn't exist, and replace it in any other case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, given what you're trying to do my proposed construct won't work. It's fine as it, but I wouldn't have personally structured this as you have; I'd have included two flags that, if set, indicate the type of value you're setting/clearing. So, if sfFlags & flagURI
was set, then the URI
field is replaced with the URI
field from the transaction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the DID object just a first class NFT that's set and unset by the user themselves on their own account? Am I missing something? Should someone else be able to modify this? |
I think you might be referring to an old version of the spec - it was updated (and changed pretty heavily) about a month ago. |
src/ripple/protocol/impl/TER.cpp
Outdated
@@ -92,6 +92,7 @@ transResults() | |||
MAKE_ERROR(tecINSUFFICIENT_FUNDS, "Not enough funds available to complete requested transaction."), | |||
MAKE_ERROR(tecOBJECT_NOT_FOUND, "A requested object could not be located."), | |||
MAKE_ERROR(tecINSUFFICIENT_PAYMENT, "The payment is not sufficient."), | |||
MAKE_ERROR(tecEMPTY_DID, "The DID object cannot be made to be empty."), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: I think it would be useful to say "Atleast URI or Data field must be non-empty in a DID object"
How should this PR be moved forward? Should it be considered for the next release? |
@intelliot the spec isn't finalized yet and there isn't much time between the final spec release and the 2.0 release. I'd like it to go into 2.0, but it may get pushed to the next release. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 LGTM
note: let's wait for updated spec (at least) before merging this updates needed at: XRPLF/XRPL-Standards#100
|
(note: checking with @nbougalis regarding whether he still has change requests) |
QA tests 👍 |
@intelliot this is good to go |
note: @dangell7 has reviewed: "Looks good to me." |
|
||
\sa keylet::did | ||
*/ | ||
ltDID = 0x0049, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: This clashes with a LedgerFormat we use in Xahau.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to close the loop: this was discussed offline and Xahau will take care of this on their end
DID
: Decentralized identifiers (DIDs) (XLS-40):
Suggested commit message:
|
note: @sappenin would like the spec to be merged prior to this implementation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 LGTM
- `ledger_entry` is the recommended read method, and it is more efficient than the `account_objects` method. - Note that both methods support `DID` object retrieval. Context: - Prior discussion: #100 - Implementation: XRPLF/rippled#4636 --------- Co-authored-by: Mayukha Vadari <[email protected]>
…om rippled code (#2491) Add support for XLS-40 and adds a script to automatically generate transaction models from rippled source code. ### Context of Change XRPLF/XRPL-Standards#136 XRPLF/rippled#4636
Implement native support for W3C DIDs. Add a new ledger object: `DID`. Add two new transactions: 1. `DIDSet`: create or update the `DID` object. 2. `DIDDelete`: delete the `DID` object. This meets the requirements specified in the DID v1.0 specification currently recommended by the W3C Credentials Community Group. The DID format for the XRP Ledger conforms to W3C DID standards. The objects can be created and owned by any XRPL account holder. The transactions can be integrated by any service, wallet, or application.
High Level Overview of Change
Introduces:
DID
DIDSet
, which creates and updates theDID
objectDIDDelete
, which deletes theDID
objectContext of Change
Earlier discussions/versions:
Type of Change
Test Plan
Added tests for the new features.