What should we name the protocol between the KERIA Service and the (currently named) Signify Clients?

[pfeairheller]

In order to properly version the REST API protocol between KERIA and her clients we need a proper name. Please vote.

[2byrds]

I'd like to hear other perspectives before I vote, because I waffled between the top three suggestions:

• Signify if the most helpful for understanding the goal of limiting the clients to signing related ops.

• KATE is the most human understandable/friendly/fun name, and highlights the overall strategy.

• KERIA seems like the simplest and most consistent choice for outsiders. KERIpy implements the KERI protocols. So then is it analogous to say that KERIA agents communicate via the KERIA protocols? If so, then 'KERIA' is the most obvious/straightforward explanation we could give to an outsider and ties in well with the KERI ecosystem brand.

[kentbull]

KATE is definitely the most human friendly name. That's second place for me.

[m00sey]

For me Signify is the protocol.
KATE is the "idea" or "premise" that Signify is the abstraction for and KERIA is the python implementation of that.

Only one choice for me.

[nkongsuwan]

From the user’s perspective, Signify is the library that is used and interacted with the most while KERIA is often treated as a black box with an API. So the “Signify” protocol sounds more natural to me.

[kentbull]

This makes sense to me as well.

[2byrds]

Thank you all for your feedback! I voted for Signify

[rodolfomiranda]

I'm still not sure. The protocol is for the KERI Agent API, so KERIA is a good candidate. On the other side, Signify provides the client side implementation of the protocol, so Signify is also a good candidate. If we go with Signify, then we should say that:

• KERIA, KERI Agent, implements Signify protocol
• the current Signify library, is the client side of the Signify protocol

[2byrds]

I like your bullet points because the 'control' flows from the client side so naming it Signify protocols supports that notion that the client protocols are influencing the agent implementation.

[kentbull]

I like that. It is KERIA that supports Signify. KERIA may support other protocols moving forward. Maybe KATE is a different edge signing protocol and Signify is protocol one we're implementing right now.

[dhh1128]

I worry that naming the protocol "signify" might be confusing, when you consider the need to version the protocol and the component separately. What version of the protocol should I expect to find supported in the Signify component if the component is at version 1.1?

If the answer is NOT guaranteed to be "1.1", then I think we're setting ourselves up for confusion. But if it IS guaranteed to be 1.1, then we've lost the benefit of thinking if the protocol as an interface; now our dependency is on a whole codebase, not just on an interface that should be stable across many versions of the codebase.

For this reason, I think I like "Kate" best, but I could also reconcile with those who love Signify via the following compromise: the name of the protocol is "Signify Protocol ", not just "Signify", and we usually abbreviate it ("SP"). Now it makes sense to me to ask, "What version of SP does Signify support?"

[rodolfomiranda]

We can also call the signify libraries as Signify Clients to reinforce the difference.
still undecided....

[kentbull]

I like the arguments here. We could call it SKATE, Signing with Keys At The Edge.

Or maybe SATE, Signing At The Edge, a play on "sate" meaning "In a state of complete and thorough satisfaction."

SATE Protocol could be a state of complete and thorough signing.