Philip Feairheller

In `kerigo` we implemented an internal representation of key state and used the existing `Event` struct as its representation, also adding a new field to it `latestEvent` that was itself...

Adding the new complex attachment group now and removing the `a` field now seems like the right choice. I assume the demise of the `VRC` receipt will wait for another...

That logic looks sound to me.

@SmithSamuelM - You mention while discussing the first class of watchers (a validator's own watchers) that the key state notice is mostly a discovery mechanism. This mechanism is particularly important...

@stevetodd I'm confused by what you're asking here. You ask about how `keripy` is wrapping out going messages and its concern about someone else receiving a bad message code. I...

The message version is the first thing processed and should address your concerns. A given implementation of the KERI protocol should reject a message that is for a version it...

If I understand this correctly, the use case can be illustrated with the following example: An Indy Ledger (Sovrin, for example) wants to provide Ledger Backer support for KERI identifiers...

> Now if all I want to do is change the IP address of the Backer then that is a discovery problem and the keri-dht already solves that. But in...

I agree that the RESTful Mimic Tunnel is the better approach. I wonder if the additional `b` field is necessary. Though the exercise started out by exploring the RESTful API,...

@SmithSamuelM I like the idea of leaving it off with the understanding of making it default to "get" in the future.