search

hyperledger / aries-rfcs

Hyperledger Aries is infrastructure for blockchain-rooted, peer-to-peer interactions
https://hyperledger.github.io/aries-rfcs/
Apache License 2.0
326 stars 217 forks source link

Tracking implementations to understand breaking change impacts #137

Closed swcurran closed 5 years ago

swcurran commented 5 years ago

We've had two recent incidents of breaking changes made in RFCs that affect implementations - DID Exchange (discussed previously) and new Discover Features (the feature formerly known as protocol-discovery). In these early days, I think we need a way to track when there are implementations so that when breaking changes are made, the existing implementations are known and can be directly notified.

The implementations and their association with Aries-RFCs should be self-reported and should be tied to a specific version and point in time, so that when a breaking change is proposed, the impact can be understood.

Not sure what is the best way to do this that will handle our current case and scale appropriately:

Maybe with the latter the definition can be strict enough that a utility can be created to walk the lists and report the impact of an RFC change?

Anyone have suggestions from what has been done in other communities at this stage of growth?

TelegramSam commented 5 years ago

Related: We need to understand which status of an RFC indicates that building on it is a good idea. DID Exchange isn't there yet IMO, but that isn't yet obvious in our RFC Structure.

swcurran commented 5 years ago

Wow. Given that the status of the RFC is "Accepted", then the fact it isn't there yet is a major issue. The lifecycle has to be followed.

My preference is that we add "Connection" back in as accepted and change DID Exchange to proposed.

And we track implementations so that we know when, and we can notify, things are going to break.

TelegramSam commented 5 years ago

The error here is indeed mine. I have a not-yet-done PR which changes the status of DID Exchange back to Proposed.

swcurran commented 5 years ago

Sounds good - but please add the connection protocol back at the same time. We've got lots of implementations that are working because that is accepted and in place.

On Wed, Jul 24, 2019 at 11:33 AM Sam Curren notifications@github.com wrote:

The error here is indeed mine. I have a not-yet-done PR which changes the status of DID Exchange back to Proposed.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/hyperledger/aries-rfcs/issues/137?email_source=notifications&email_token=AAHYRQT6TCPQAZ2EKGBEPJ3QBCN57A5CNFSM4IF25MBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2XHALI#issuecomment-514748461, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHYRQVW2LGJKN2JD4QYOJTQBCN57ANCNFSM4IF25MBA .

troyronda commented 5 years ago

We have started on building the DID Exchange feature. What are the differences between DID Exchange and Connection (other than the name)?

llorllale commented 5 years ago

@troyronda "connection" was its previous name

dhh1128 commented 5 years ago

@swcurran I am supportive of what you are asking for. I think we should have an Implementations section, and encourage people to submit PRs linking to their impls. And I think better discipline would be a benefit for everyone.

However, I do not agree with your characterization of the history of the Connection protocol. I wanted to offer an alternate history, just so people who come to this ticket see that there are other viewpoints that aren't so critical of how that evolved. So, IMO:

  1. The connection protocol was incubated in Indy, and merged there. This was under an old process that predated Aries, and more or less equates to Indy's ACCEPTED status.

  2. When Aries came along and we decided that some Indy HIPEs ought to be Aries RFCs, we generally tried to move things straight across while adjusting statuses for the new process/lifecycle Aries was using. However, there was never a crisp agreement about how this transition would happen in all its specifics--there was just a general intention and a rough process.

  3. This particular protocol was raised as a PR against Aries with the name "Connection", but before the PR was fully processed, the RFC title was changed from "Connection" to "DID Exchange". Changing a PR is not a violation of any process; any author who raises a PR can always do that before the PR is merged.

  4. There has been no breaking change. The Connection protocol that your codebase implements still exists in its Indy HIPE, and nothing about it has changed in a way that breaks anybody. It is correctly marked as Superseded by the Aries RFC with the new name, and Aries RFC 0023 DID Exchange correctly notes that it supersedes Indy HIPE 0031. We don't need to "bring back" a Connection Protocol in Aries; it never existed in Aries in the first place. If you want to keep supporting the Indy Connection Protocol, by all means do.

@troyronda The differences between Indy's Connection Protocol and Aries's DID Exchange Protocol are largely cosmetic. If you're building for one, you're almost exactly building for the other, give or take a few string constants. Press forward with confidence.

swcurran commented 5 years ago

I disagree with your view of the flow, but I'm not fussed about. However, there is a factual error in what you have that I highlighted in Rocketchat and will repeat here about what implementations exist:

A number of implementers implemented Connections 0.1 that is documented here - https://hackmd.io/s/HkklVzww4 It was defined for IIW and has had a much longer lifespan than expected. Note that it is significantly different that DID-Exchange in that it does not support preview or the proposal messages.

The indy-hipe version was never implemented and so should be ignored. As I talked about on Rocketchat, I think the 0.1 version of the connection protocol should be added as an Aries RFC and can do that.

This is all separate from the point of the issue - how do we know when changes are going to break existing implementations so that we treat those more carefully.

kdenhartog commented 5 years ago

Taking note that I have a TODO to provide an example of how this might work. I haven't gotten to it, but will provide a proposed solution and link to it in this issue.

swcurran commented 5 years ago

An Implementations section has been added to the RFC template and all of the existing RFCs. As well, the "Demonstrated" status has been added to the RFC lifecycle.

I think we are good to close this and I'll do that in a day or two. Please post a note if you think more needs to be done.

swcurran commented 5 years ago

Closing this issue - we're good for now.