FCP HIPE: protocol-discovery protocol

[dhh1128]

Signed-off-by: Daniel Hardman [email protected]

[TelegramSam]

I feel like agprot and agent-protocol is overly general for the purpose of message family support. Perhaps message-support?

[swcurran]

I agree with Sam. I definitely don't like the truncated "agprot" - we don't need to be that concise, so at minimum, please spell out both words. I also immediately jumped to thinking about transport protocols (http, BT, etc.) when I started reading this. Agreed that Agent to Agent messaging is a protocol, it's not what comes to mind. I like message-support as well.

[dhh1128]

I can certainly make the identifier longer.

Regarding the use of "protocol" versus "message family": I was trying to shift the community's thinking a bit, here, with my use of the word "protocol." We've been talking about message families, which is a good construct. But I think it's a bit suboptimal because it puts the focus on data and data format. As a result, I think we neglect some other issues that also need specification. For example, you've heard me harp on the need for a state machine that tells which messages can be sent, when, and how state changes as a result. I also think the roles in a protocol need definition.

This was, in a way, the thrust of my talk at HL Global Forum: that it's about protocols between agents. Message families are a subset (the skeleton) of a protocol. A protocol could cross message families (e.g., we could have a general ACK message that gets used in many protocols; we already have a general problem-report message that does).

@swcurran 's comment that "Agent to Agent messaging is a protocol" gives me pause, because when I used the word "protocol" here, I was thinking of specific subprotocols like tictactoe or credential issuance, not the general protocol infrastructure. OSI model all over again?

So: I'm pushing back about calling this "message support". It's protocol support, of which message types are a primary consideration, but not the only one. Does my pushback move the needle at all, @TelegramSam or @swcurran ?

[swcurran]

Interesting response - I'll have to think about it more. When I consider what you did with tictactoe, I don't think if it as a parallel concept to, say, http. That is - the word "protocol" does not come to mind (but maybe it should). Set of related messages (or a family) does feel right - which I don't think of as just data and data format - a message family includes the processing behaviour.

[dhh1128]

@swcurran A protocol is not just something like HTTP; it's any set of coordinated behaviors by multiple parties. Buying a house is a protocol. Ordering a meal at a restaurant is a protocol (and Vapianos, where we ate the other night, had a different one from many). Issuing a credential is a protocol. Issuing a credential is more than a message family; it's also all the steps that the parties have to engage in, in between sending each other messages.

[TelegramSam]

Good Discussion. I think that Message Families are the interface of the protocol. A reasonable assumption can be made that if you claim to support the interface, you also support the steps in between.

I think what this HIPE does is describe discovery of supported message family / protocol interfaces.

In regards to needle moving: I'm becoming convinced that explicitly declared 'roles' for message families and discovery of supported roles is very necessary in message family definition.

[swcurran]

Totally understand and agree on what protocols are - it's just the usage of the term in technical contexts. Tech use of "protocol" implies putting the "thing" on a pedestal and "message families" don't feel like that.

[dhh1128]

@TelegramSam and @swcurran Please go read my HIPE about how to define protocols (#69), and then see if you are still disliking my emphasis on "protocol" instead of "message family". I really think "message family" is too narrow (look at how much of the tictactoe protocol is not about the message family), and I also don't resonate to the concern that tech use of "protocol" implies putting the thing on a pedestal.

[dhh1128]

I will be updating this HIPE to bring it into conformance with the PR about how to define protocols (#69 ).

[TelegramSam]

I've added a few inline comments. Aside from those minor suggestions, my only reservation is the fairly early definition of roles in protocols. I don't want to wait though, and as it's an optional field I think we are nearly ready for FCP on this HIPE.

[dhh1128]

@TelegramSam I believe all outstanding issues have been resolved. The PR needs to be renamed to call it the "protocol discovery" PR instead of the "feature discovery" PR.

[swcurran]

Looks good! Let's move it forward.

[dhh1128]

@TelegramSam and @swcurran I wonder if we need to provide a way to find out which decorators an agent will support? Obviously, it must support any that are required by a protocol--but would it be important to know whether it supports ~timing.expiration_time, for example? Or ~please_ack? Or...

[TelegramSam]

@TelegramSam and @swcurran I wonder if we need to provide a way to find out which decorators an agent will support? Obviously, it must support any that are required by a protocol--but would it be important to know whether it supports ~timing.expiration_time, for example? Or ~please_ack? Or...

Heh. I just left this comment on the message tracing proposed HIPE. I do think that is valuable, but maybe not necessary for this initial HIPE.

[TelegramSam]

So, if we provide a docs link to each decorator like we do for message families, they become automatically applied to this discovery process. Seems worth discussing over in the decorator HIPE.

[dbluhm]

I think all of the other family names in HIPEs are using snake case versus kabob case. Switching this one to protocol_discovery to stay consistent seems like a good idea.

[dhh1128]

Agreed. Will switch.

…

On Wed, Apr 17, 2019 at 4:49 PM Daniel Bluhm ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In text/protocol-discovery/README.md <#73 (comment)>: > + +## Motivation +[motivation]: #motivation + +Though some agents will support just one protocol and will be +statically configured to interact with just one other party, many +exciting uses of agents are more dynamic and unpredictable. When +Alice and Bob meet, they won't know in advance which features are +supported by one another's agents. They need a way to find out. + +## Tutorial +[tutorial]: #tutorial + +This HIPE introduces a protocol for discussing the protocols an agent +can handle. The identifier for the message family used by this protocol is +`protocol-discovery`, and the fully qualified URI for its definition is: I think all of the other family names are using snake case versus kabob case. Switching this one to protocol_discovery to stay consistent seems like a good idea. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#73 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAQ3JCBAQBMX4IOBOKRGG3DPQ6SPBANCNFSM4GK52ZMQ> .

[dhh1128]

This is superseded by Aries RFC 0031 (hyperledger/aries-rfcs#31)