Advantages from did:ethr that would make sense to keep in did:eth

[mirceanis]

• Free and instant DIDs. Creating a DID doesn't require interacting with a network, so it can be done entirely offline.
  This also means that, at least initially, the new DID can be used privately.
• No extra infrastructure is required besides the ethereum network itself (and a registry contract on it).
• DID control and DID documents can be updated.
• DID controller can be a multi-sig contract or proxy.
• DIDs can partially be resolved on-chain (through owner and delegate queries)
• Updates are granular, not requiring the entire DID document to be republished (useful for institutions with many delegates).
• History of a DID document can be audited and queried.
• Can resolve to historical versions of a DID document through query parameters.
• Supports any EVM-compliant blockchain that keeps a history of events.
• Allows decoupling of DID ownership from transaction funding. (although, this mechanism can be improved a lot more.)

[mirceanis]

This list assumes a few things:

• it's mostly based on events
• it supports on-chain storage too (for some updates)
• it supports meta-transactions

Is there anything here that would present difficulty and that we might want to avoid?

[lleifermann]

it's mostly based on events

I am not sure if the contract really needs to emit events. I understand the reasoning behind an event driven structure but it puts quite some power into did resolvers (and code the resolvers need to implement)

Maybe we are able to find a good way to do everything via in-contract storage without a linear increase of costs for did creation/modification. We had a comparable challenge designing a eth based revocation method. If one leverages evm native data structures like accounts you can do pretty wild stuff like quasi infinite storage.

[mirceanis]

An event list approach allows the resolver logic to be reused on other storage mechanisms too (like ceramic for example), but at this point it's an implementation detail, I'm not insisting on this and am still very interested in alternatives.

If indeed it's possible to obtain the same 100% on-chain without extra cost, it would be amazing.
Can you share more details about what you mean by native data structures?

[strumswell]

Can you share more details about what you mean by native data structures?

As far as I can tell he is just talking about mappings, arrays, and the like and how nesting them gives you a lot of powerful possibilities for, e.g., access control and generally organizing data. We did something similar for our revocation registry contract, but I am not sure we can apply this 100% on-chain data approach here as well because of the complexity/ size of the data (keys! endpoints!).

Having said that, I would love to have 100% resolvable DIDs on-chain to also access different key pairs to verify signatures on-chain of different key types. But cost is imo a much more important metric. How useful is the greatest DID method if operations cost you multiple dollars and people don't use it in production due to that. We already see people going for cheap-ish DID methods like key, web, and ion.