Feature/emit did peer 4 #2696
Feature/emit did peer 4 #2696
Conversation
Signed-off-by: Jason Syrotuck <jasyrotuck@gmail.com>
Signed-off-by: Jason Syrotuck <jasyrotuck@gmail.com>
Signed-off-by: Jason Syrotuck <jasyrotuck@gmail.com>
Signed-off-by: Jason Syrotuck <jasyrotuck@gmail.com>
Signed-off-by: Jason Syrotuck <jasyrotuck@gmail.com>
Signed-off-by: Jason Syrotuck <jasyrotuck@gmail.com>
Signed-off-by: Jason Syrotuck <jasyrotuck@gmail.com>
Signed-off-by: Jason Syrotuck <jasyrotuck@gmail.com>
| # The long format I sent has been acknoledged, use short form now. | ||
| if LONG_PATTERN.match(conn_rec.my_did or ""): | ||
| conn_rec.my_did = await self.long_did_peer_4_to_short(conn_rec.my_did) |
There was a problem hiding this comment.
I think as a community we need to formalize this a bit more but I think this is a logical starting point.
Signed-off-by: Jason Syrotuck <jasyrotuck@gmail.com>
Signed-off-by: Jason Syrotuck <jasyrotuck@gmail.com>
…ies-cloudagent-python into feature/emit-did-peer-4
|
Regards the issue of updating the long form to the short. I would think that from the start on received DIDs, we want to store the short form on the connection ID, and when we need to resolve a long form, we convert it before looking it up. Since it is impossible to look up a short form via its long form, I think we should always do that. I guess on creation its trickier, since we need to send it to the other party as the long form. Do we ever need to use the long form again after we send it to the other party? Especially if we assume the other party stores it as a short form (per comment above). Also, do we store the DIDDoc? If so, is there a DIDDoc to Long Form transformation that would provide a way to get the long form back if ever needed? |
|
Ready for final review. @swcurran we currently need the protocol manager class to manage the ins and outs of each protocols behaviour, but that's still going to have maintenance issues if there are interleaved blocks of code handling unqualified, did:peer:2/3 and did:peer:4. There is no code access at the point in time you are referring to, outbound queuing system uses the same values that we are manipulating. so doing any changes after we have gotten a response after sending the long form seems like the best and safest. Sending out the long form and then trying to change the agent's connection record may result in more convoluted behaviour than it's worth. This is definitely something to keep an eye on. We are not storing the did documents at all in storage. The short form did looks up the long form did, resolves that long form did into the document and then makes the appropriate substitutions to make it behave like the specification. |
|
Got it — thanks. Sounds good. |
| if args.emit_did_peer_2: | ||
| settings["emit_did_peer_2"] = True | ||
| if args.emit_did_peer_4: | ||
| settings["emit_did_peer_4"] = True |
There was a problem hiding this comment.
Wondering when one of these will become the new default, rather than having to specify the behaviour at startup (I am a bit out of the loop on this so I am likely missing some background info).
|
Open for comments on how to update the long form with the short form. The resolver handles its own mapping, however i'm storing a duplicate DIDInfo, one where the did is long form and another where it's short form (for the same verkey).