On-chain Resolution

[nickreynolds]

As @mirceanis mentioned in #7 , one of the more interesting features of did:ethr is that it is partially resolvable on-chain. We should consider approaches that improve the on-chain resolution of DIDs beyond the functionality of did:ethr.

In particular, I would think we would want to add support for on-chain resolution that includes Service Endpoints.

Adding support for on-chain resolution will almost certainly increase DID update costs. We could consider an approach in which off-chain and on-chain resolution is not expected to be identical, and when a user updates their DID Document, they can choose between 2 different Update functions: one that will modify their on-chain Document (e.g. by updating contract state so can be queried within a contract function), and one that will modify their off-chain Document (e.g. only emits an event that can be processed by off-chain resolver)

Is there any problem with a DID method that would likely lead to widely divergent resolved DID Documents, if the DID is resolved on-chain vs off?

[mirceanis]

It doesn't have to lead to diverging DID documents.

(assuming we're still going to be using events to build documents) Any change that triggers an event can have a flag that marks it in contract-storage too, but the event would still be emitted.
Events are very cheap, so the off-chain DID document can continue to be built off of events.

Since everything that potentially gets stored in contract storage also triggers an event there wouldn't be any divergence.
The on-chain "resolution" would only refer to a subset of the off-chain available items.