Initial commit for a did:peer driver

[FabioPinheiro]

I was going to implement a docker image to resolve the peer did offline. But that would take more than a few hours, and I have some questions if the output is correct.

So I propose to merge this temporary driver for did:peer in the meantime.

Example https://did.fmgp.app/resolver/peer/did:peer:2.Ez6LSghwSE437wnDE1pt3X6hVDUQzSjsHzinpX3XFvMjRAm7y.Vz6Mkhh1e5CEYYq6JBUcTZ6Cp2ranCWRrv7Yax3Le4N59R6dd.SeyJ0IjoiZG0iLCJzIjoiaHR0cHM6Ly9hbGljZS5kaWQuZm1ncC5hcHAvIiwiciI6W10sImEiOlsiZGlkY29tbS92MiJdfQ

[peacekeeper]

Hello @FabioPinheiro thanks, I think a did:peer driver would be really interesting.

Could you tell us a bit more about did.fmgp.app? Is this something like a DIDComm agent where other agents connect, and then it can resolve did:peer identifiers for those connections?

Could this also be added as a local driver (Docker container) to the Universal Resolver, instead of calling the remote service?

Would you perhaps be available to discuss this on one of the next DIF ID WG calls? I think this topic would be really interesting to the group: https://github.com/decentralized-identity/identifiers-discovery/blob/main/agenda.md

[FabioPinheiro]

did.fmgp.app is just a playground that I build with a scala implementation of DidComm v2.

yes there are some agents running on there also. There are able to respond to trust pings and basic messages. Can also visualize all the messages received by one agent https://did.fmgp.app/#/stream (just look into the dev console -> network -> ws). Almost all the agents there have known private keys, which I really miss from other places when I was trying to test interoperability.

The limitation of this implementation of did:peer are:

• It only supports numalgo = "2" ( and probably the "0") but numalgo "1" is not supported. https://identity.foundation/peer-did-method-spec/#method-specific-identifier
• The multicodec used for numalgo = "2" as some hard code bytes. (I still didn't see an example that didn't work but the spec are more generic)

Could this also be added as a local driver (Docker container) to the Universal Resolver, instead of calling the remote service?

That was the initial plan. In reality, almost all the code is on https://github.com/FabioPinheiro/scala-did/blob/master/demo/jvm/src/main/scala/fmgp/did/resolver/DidPeerUniresolverDriver.scala

• I need to do a new release to maven.
• Make a new project with that code.
• Build a docker image (-+ like what I already do for this website)
• Figure out how to publish to the docker hub

Would you perhaps be available to discuss this on one of the next DIF ID WG calls?

I can try. I'm not sure because I will be traveling between the 13th and the end of the month

[kimdhamilton]

What's the status of this PR? Can we close it since the branch seems to be merged?

[FabioPinheiro]

@kimdhamilton I think so. Another solution was done to resolve did:peer