Hello, I would like to know what does it actually entail to utilize Ceramic with additional DID methods not supported by default. Is this possible at this stage or are Ceramic apps limited to the current methods supported? If it’s possible to extend applications to utilize additional DID methods, what changes need to be made and in which components?.. I’m thinking currently on methods did:ion and did:key for example.
Additionally, if I were to build a Ceramic app that utilizes a new method, how would that impact the interoperability with other Ceramic apps? Is the DID layer abstract enough to achieve full interoperability among DID methods? (my understanding is that the idea of DID as a standard is precisely interoperability)
I’m curious to know about this. Any feedback is appreciated.
Currently the two main DID methods that Ceramic supports is did:key and did:pkh. While other DID methods could be added there are definite tradeoffs with doing so.
For example adding support for did:ion is not something that is tractable right now. The reason for this is that running an ION node requires both running a bitcoin node + an ION node (that requires a lot of resources). We would like Ceramic to avoid relying on any blockchain besides Ethereum. Otherwise running Ceramic trustlessly becomes very hard for node operators.
Got it, that clears things out a bit. And if did:key is supported already then that’s good news to me. However, in order to extend the support to additional DID methods, would that be a work that required the involvement of the Ceramic team (is it a fundamental change at protocol level) or can any developer extend authentication to support additional DIDs. Would that entail changes not only in clients but also the nodes? Anything else that would require changing? I’m more or less curious of what are the implications of adding DID methods architecturally.