Consider removing dynamic layer

[brianorwhatever]

As far as I can tell, none of the implementations of this spec use the dynamic layer of this method. If everyone is just using static this method could become quite succinct which would help adoption.

[dhh1128]

I agree. However, I don't want to do all the surgery to pull out the dynamic stuff. Are you interested in writing a PR and adding yourself to the contributors list?

[brianorwhatever]

I would if we are going to revive this method. If not I don't think it's worth the effort. At this stage I'm just gathering information to figure out the best plan moving forward.

[brianorwhatever]

Ultimately, this method to me is entirely captured by static and numalgo=2. Here is the reason I believe this to be true..

static:

• numalgo 0 is identical to did:key with the addition of a leading 0 (and an extra character in the method as well)
• numalgo 1 is interesting however I don't think anybody has implemented it (I might be wrong - if so I'd like to see!) and I also believe this would be a different method entirely
• numalgo 2 is the most commonly used here and this is what should remain

dynamic:

• this is where numalgo 0 would be powerful as you'd be able essentially update a did:key.. but I'm not sure anyone has implemented this
• again not implemented in numalgo 1 as far as I know
• It doesn't make sense to use numalgo 2 as an updatable did as the identifier itself is huge and there would be more succint ways to do it (num algo 0 or 1). Who would want to use this identifier enough to update it.. did:peer:2.Vz6MkpjaKEX9avv2c1QuJte4EHRTvH6gfuAB4FtZSDxWLYKQ7.Ez6LSgbQucMX4aT46UPKwxSBeSNNYK9XKQ9TZdkxi5AFU8AmQ.SeyJpZCI6IiNkaWRjb21tIiwidCI6ImRtIiwicyI6Imh0dHBzOi8vcG9ydGN1bGxpcy4xa2VlcC5jb20vZGlkY29tbSIsInIiOlsiZGlkOndlYjpwb3J0Y3VsbGlzLjFrZWVwLmNvbSJdfQ

So that being said I am proposing removing 5/6 of the methods available in this spec which is quite a drastic change.. I could see creating a separate "did:peer dynamic extension" spec being of value if there is interest in that but as experience is showing there hasn't really been so far..

[dhh1128]

I am not opposed to most of those suggestions, @brianorwhatever . I think there are people using numalgo 0, so removing might disrupt them -- but everything else would probably be easy to remove to simplify.

[brianorwhatever]

yeah, that is what I suspect as well which is unfortunate as it replicates did:key but should probably remain in as you say. Do you know of anyone using numalgo 1?

[dhh1128]

re numalgo 1: no, I believe it's unimplemented

[brianorwhatever]

I have recently discovered https://impervious.ai/ which in its backup recovery key and throughout the app uses numalgo with an initialState param