propose HIPE: protocols explainer

[dhh1128]

No description provided.

[swcurran]

I think (not certain) it would be more useful in the tic-tac-toe example to use an explicit message family error message ("cheater!!") rather than problem-report, and thus might not be the best example for the use of problem-report. Obviously not a big deal, but might be worth calling out the pros and cons.

It's interesting in that it kind of depends on the structure of the agent and it's handling of thread state vs. message type in the dispatching of messages. I'm not sure as I type this if there is, or if there should b,e guidance on that in the thread HIPE.

Hope that makes sense...

[dhh1128]

We need to have a deeper conversation about specific messages versus generic ones. Let's do that offline, and report the outcome here.

[swcurran]

This is a great HIPE - I really like it.

Are we nearing the point where the Message Family specification DID can be published on a ledger with an endpoint and this message family's spec published? Put another way - is the HIPE the message family spec, or will it/should it eventually be published elsewhere in some other format?

[dhh1128]

The message family spec DID can be published any time. I guess I'll add that to my to-do list and see if we can get it taken care of. I've kind of held off because as soon as I do, the question of who holds the keys to the DID becomes more important. Any thoughts about that? Like, maybe all the maintainers of the HIPE repo hold the keys, or shamir secret sharing of maintainers, or something?

As soon as we have a DID Doc that defines a service endpoint for these message families, we need a place to host the service endpoint. Any ideas for that?

I guess we need to start working on a message family HIPE. Maybe the one I started on protocols needs to roll into it...

[TelegramSam]

we need instructions about how to register a DID on the ledger and update it, to allow anybody to create their own message families.

I'm wondering if we have a special location of the HIPE repo that serves as hosting for indy related message families. We use github directly, or indirectly through an automated publishing script, to serve the necessary pages.

[Patrik-Stas]

Seems like typo in the state machine image. On state my move, when send move event occurs, it says "transition to my move or wrap up". I suppose this should be "transition to their move or wrap up"?

[dhh1128]

@Patrik-Stas Thanks for the catch. Now fixed.

[dhh1128]

I have revised this HIPE significantly. The content about Tic Tac Toe is mostly unmodified, but there is now a main README that discusses what protocols are and how they should be defined and documented by a HIPE. The Tic Tac Toe HIPE is then presented as a hyperlinked example.

[dhh1128]

@TelegramSam : this is the only change in this commit that I don't feel comfortable with. I think your phrase "change in expectations" is not quite clear enough. When party A talks protocol version 1, and party B talks protocol version 2, they should not expect to be interoperable; the different major numbers advertises incompatibility. However, if it's A=1.3 and B=1.5, then they should expect interoperability except on some optional features that B apparently knows about but A does not.

So here's the way I'd state it: minor numbers in a protocol introduce features that are optional, such that the later version could be interoperable with an earlier version having the same major number, as long as the functionality used between the two parties is gracefully degraded. On the other hand, major versions say that no interoperability should be assumed.

[dhh1128]

This HIPE has been converted to an Aries RFC. See https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0003-protocols/README.md.