Closed zbarbuto closed 1 year ago
@zbarbuto , can you resolve conflict since Pr #34 please 🙏
Have rebased
rebased again with last changes to tests in https://github.com/Meeco/did-sdk-js/pull/36
Maybe DID_DOCUMENT could be used for both then and Document key could simply be removed? Only if that does not impose too many changes around the rest of the codebase.
For backwards compatibility wouldn't make more sense to use Document
for both since this is a "new" event? Although maybe it's nice to keep them separate to ensure actions revolving around a completed document are their own thing?
For backwards compatibility wouldn't make more sense to use Document for both since this is a "new" event? Although maybe it's nice to keep them separate to ensure actions revolving around a completed document are their own thing?
Backwards compatibility was already broken by changing DID format with one of the previous PRs so I thought it might make sense to update this as well. I like the argument about keeping thing separate for completed document tho.
Adds support for resolving DID documents stored on IPFS.
The message envelope the same format as the
DIDOwner
message:where the
event
will decode to:The resolver will treat this message as a complete overwrite of the current did document to use the document fetched from IPFS. At the moment, it treats the message as "This is now my did document" regardless of any prior events. However, this could easily be changed to require a
DELETE
first if needed, as with the currentCREATE
operation.This is a breaking change as the signature of the
DIDDocument
constructor has changed and processing messages now has to be called separately (as the process needs to be asynchronous so that any external documents can be fetched).Some tests were already failing when I checked out the repo so I'm not sure about whether or not that's to do with my setup or not.