Date   

Academic Involvement in Hyperledger

hmontgomery@us.fujitsu.com <hmontgomery@...>
 

Hi Everyone,

 

I spent last week at a Dagstuhl seminar on permissioned blockchain (thanks Mic for getting me the invitation!).  If you aren’t aware what this is, it is basically an unstructured week at a German castle in the middle of nowhere talking about research problems in a particular area of computer science (in this case, permissioned blockchain).  So, basically it’s nerd camp for adults—your mileage may vary, but I thought it was really fun.

 

As you all might expect, Hyperledger came up quite a bit in discussions.  In fact, Fabric seemed to be the most talked about (and built upon) system.  I had no idea that there were this many people across the world in academia working on things related to Hyperledger (it seems to be the case that blockchain papers are being sent to a very wide variety of conferences so it is hard to follow).  In particular, Hyperledger has captured a lot of interest in the database community which I did not expect or know about until last week.  The fact that Hyperledger has caught on in parts of the academic community was really encouraging.  Some of the academic work included direct building on Hyperledger (like the fast Fabric paper—one of the authors was there), while other work used, say, Fabric, as a way to test the performance of new algorithms.  For instance, multiple people reported BFT algorithm tests in terms of Fabric performance.

 

However, there were some notable issues:  pretty much all of the participants didn’t know how to contribute their work back to Hyperledger!  Those that had contacted people found the contribution process difficult, thought it was hard to get started, and didn’t know who to talk to about issues in the process.  Many of these people were not just coming with algorithms on pencil and paper—they had modified versions of, say, Fabric running with their implementation changes, and performance numbers to boot!  Several groups said that they tried to get involved and contribute, but one or more hurdles stopped the process.

 

It struck me as particularly wasteful that we did not have an efficient way to get these folks involved in Hyperledger.  Given that many of these research groups already had working code, it seemed like it should be easy to incorporate these changes, but it wasn’t happening.  In particular, I think this was due to the fact that most people had never worked with an open source organization before and were not aware of how things worked.

 

With this in mind, I’d like to suggest we create a forum for Hyperledger research-related activities.  I’m not sure whether this should be a working group, SIG, or something else entirely, but I think we should have a biweekly (or perhaps monthly) meeting where researchers could talk about their work and get feedback on how to contribute the results of their research back into the Hyperledger code bases.  In addition to helping researchers contribute code, we could potentially do more:  we could have engineers talk about interesting problems they face that might be good for research, and researchers present solutions to problems (or efficiency/security improvements) that could be implemented to improve the various Hyperledger projects.

 

I asked people at the seminar if they would be interested in joining something like this, and roughly half of the 30 participants expressed interest in joining.  So I think we would have a pretty substantial crowd.

 

What do people think about this?  Does anyone have any suggestions on how to best implement this idea?  Again, it seems very wasteful not to help these researchers (and potential contributors) get involved.

 

Thanks a lot for your time, and have a great day.

 

Thanks,

Hart


Identity WG call- notes of the meeting June 26, 2019

Vipin Bharathan
 

Hello all,
Please read the notes .
Questions/comments/corrections welcome.
We have a tentative agenda for the next call scheduled for the 10th of July also linked to from the notes.
The attendees should provide more details or corrections against their names if they desire. 
Links to audio/video are also available in the notes.
Best,
Vipin


Re: [Hyperledger Labs] Proposal: Require two factor auth for Hyperledger Labs on github in a week

Ry Jones
 

Sure. I created a group of non-2fa users in labs and sent a message to the group. Many of them are people that have not used labs or even github at all this year.


On Thu, Jun 27, 2019 at 11:36 AM Mark Wagner <mwagner@...> wrote:
With the July 4th holiday and my assumption of minimal support on the 4th and 5th, would it make sense to delay a week ?

-mark

On Thu, Jun 27, 2019 at 7:30 AM Ry Jones <rjones@...> wrote:
All,
I propose turning on the two factor auth requirement for the Hyperledger Labs organization on 03 JULY 2019. What I learned from enabling the requirement on the main Hyperledger org is that when a person is re-invited, it is very easy to return the previous permissions and settings to the user. In fact, it is the default.
Thoughts?
Ry

--
Ry Jones
Community Architect, Hyperledger



--
Mark Wagner
Senior Principal Software Engineer
Performance and Scalability
Red Hat, Inc


--
Ry Jones
Community Architect, Hyperledger


Re: [Hyperledger Labs] Proposal: Require two factor auth for Hyperledger Labs on github in a week

mark wagner <mwagner@...>
 

With the July 4th holiday and my assumption of minimal support on the 4th and 5th, would it make sense to delay a week ?

-mark


On Thu, Jun 27, 2019 at 7:30 AM Ry Jones <rjones@...> wrote:
All,
I propose turning on the two factor auth requirement for the Hyperledger Labs organization on 03 JULY 2019. What I learned from enabling the requirement on the main Hyperledger org is that when a person is re-invited, it is very easy to return the previous permissions and settings to the user. In fact, it is the default.
Thoughts?
Ry

--
Ry Jones
Community Architect, Hyperledger



--
Mark Wagner
Senior Principal Software Engineer
Performance and Scalability
Red Hat, Inc


Re: Proposal: Require two factor auth for Hyperledger Labs on github in a week

Ry Jones
 

I've asked in chat, and I'm asking on the mailing list. I haven't run an activity audit on the labs repos (yet).

My next proposal to labs is to archive some of the labs that seem to have run the course. We have a distinct org for that:
Ry

On Thu, Jun 27, 2019 at 7:40 AM Christopher B Ferris <chrisfer@...> wrote:
Have we reached out to get people to add 2FA? You can @ the repo members.

Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Digital Business Group, Open Technologies
email: chrisfer@...
twitter: @christo4ferris

On Jun 27, 2019, at 7:29 AM, Ry Jones <rjones@...> wrote:

All,
I propose turning on the two factor auth requirement for the Hyperledger Labs organization on 03 JULY 2019. What I learned from enabling the requirement on the main Hyperledger org is that when a person is re-invited, it is very easy to return the previous permissions and settings to the user. In fact, it is the default.
Thoughts?
Ry

--
Ry Jones
Community Architect, Hyperledger



--
Ry Jones
Community Architect, Hyperledger


Re: Proposal: Require two factor auth for Hyperledger Labs on github in a week

Christopher Ferris <chrisfer@...>
 

Have we reached out to get people to add 2FA? You can @ the repo members.

Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Digital Business Group, Open Technologies
email: chrisfer@...
twitter: @christo4ferris

On Jun 27, 2019, at 7:29 AM, Ry Jones <rjones@...> wrote:

All,
I propose turning on the two factor auth requirement for the Hyperledger Labs organization on 03 JULY 2019. What I learned from enabling the requirement on the main Hyperledger org is that when a person is re-invited, it is very easy to return the previous permissions and settings to the user. In fact, it is the default.
Thoughts?
Ry

--
Ry Jones
Community Architect, Hyperledger


GitHub package registry beta

Ry Jones
 

GitHub has a beta for a package registry. We're opted into the waiting list; you can read more here:
I'm interested in what you think about publishing on github instead of npm or dockerhub directly. I don't have any opinions beyond it would be one less thing to manage.
Ry
--
Ry Jones
Community Architect, Hyperledger


Proposal: Require two factor auth for Hyperledger Labs on github in a week

Ry Jones
 

All,
I propose turning on the two factor auth requirement for the Hyperledger Labs organization on 03 JULY 2019. What I learned from enabling the requirement on the main Hyperledger org is that when a person is re-invited, it is very easy to return the previous permissions and settings to the user. In fact, it is the default.
Thoughts?
Ry

--
Ry Jones
Community Architect, Hyperledger


No TSC Meeting Jun 27

Middleton, Dan <dan.middleton@...>
 

The TSC does not have agenda items for Jun 27. Consequently we are cancelling this week’s phone call.

 

Next week’s meeting which would fall on July 4 is also canceled.

 

Our next conference call will be July 11th.  Meanwhile TSC work will continue to progress in committees and any business can also be raised through this mail list.

 

Regards,

 

Dan Middleton

Intel Principal Engineer

 

 


Upcoming Event: Hyperledger Caliper Quarterly Update Due #tsc-project-update - Thu, 06/27/2019 #tsc-project-update #cal-reminder

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Reminder: Hyperledger Caliper Quarterly Update Due #tsc-project-update

When: Thursday, 27 June 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Caliper update to the TSC was due 24 June, 2019, and it will be presented to the TSC on 27 June, 2019. Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


Re: Quilt reboot, and "compound" projects

Christopher Ferris <chris.ferris@...>
 

IMO the interconnection of a project is its maintainers/community and some architectural coherence that all are bought into.

Chris

On Jun 23, 2019, at 12:20 PM, "hmontgomery@..." <hmontgomery@...> wrote:

I think we need to clarify what, exactly, a compound project *is* before we can say whether or not they make sense as projects. 

 

Does the compound project provide multiple different functionalities that reuse and share a lot of code?  It probably makes sense for this kind of thing to be a single project.

 

On the other hand, what if the compound project is a collection of different code bases for a similar functionality that don’t have any interconnection?  In this case, it probably makes sense to keep things separate.

 

I guess what I’m getting at is that I think it should be the level of interconnection between the components/modules/features/functions that should determine whether some collection of code is one project or multiple projects.  We could technically state that, say, Indy is a compound project because it has two “functionally different” libraries Indy-SDK and Indy-Node.  But this makes absolutely no sense due to the interconnection of the two code bases.

 

Does this make sense?  It’s been a long day of travel so it’s entirely possible this makes no sense.

 

I am also super-excited for a new interop proposal.

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Middleton, Dan
Sent: Saturday, June 22, 2019 8:14 PM
To: tsc@...
Subject: Re: [Hyperledger TSC] Quilt reboot, and "compound" projects

 

Compound projects feel a bit unnatural to me.

 

One elephant in the room is whether we can let projects end the lifecycle. I think that’s a really healthy thing for any portfolio.

I’m not so sensitive to the potential loss of name recognition. In this particular case, I don’t [yet] see an interest from the Quilt maintainers in progressing the ILP code. To me that signals the project is at its natural conclusion.

 

My view of Ursa is that we are still in the storming stage. I think as a team we are getting closer to its definition, but we shouldn’t point to it as a template of a compound project right now. In fact, if ursa turned into a bag of disjoint parts I don’t think it would be successful, but that’s a different thread.

 

A lot of what defines a project to me is the maintainers and contributor community around it and their shared drive to create a coherent piece of software. If we sideloaded a second code-base with a different set of developers that doesn’t feel like a unified project to me. That feels more like a branding decision that I think is overthinking our incubation stage.

 

(and to be clear I am very interested to see a new interop proposal and evaluate it on its own merits)

 

Regards,

 

Dan Middleton

Intel Principal Engineer

 

 

 

From: <tsc@...> on behalf of Vipin Bharathan <vipinsun@...>
Date: Saturday, June 22, 2019 at 6:06 AM
To: "tracy.a.kuhrt@..." <tracy.a.kuhrt@...>
Cc: "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] Quilt reboot, and "compound" projects

 

Hello Tracy,

If it is different from ILP, what is it? Will there be a doc describing it much like a project proposal. Any technical papers?  Is there code you would like to bring in? 

Best,

Vipin


On Jun 21, 2019, at 10:55 PM, tracy.a.kuhrt@... wrote:

Hi, Chris and other TSC members. 

The item that you are talking about (Helm charts, etc) is not the interoperability project that we want to contribute to Hyperledger. That will be separate discussion at some point in the future.

I had originally suggested we bring our interoperability contribution into Hyperledger Quilt because the TSC was clear when they approved Quilt that they wanted it to grow beyond just ILP to encompass interoperability. I know some people were communicating Quilt as an interoperability project (before we began the reboot discussion) even though it has always been “a Java-based ILP library” with direction from the TSC to be more. There is ton of interest in the ecosystem for interoperability beyond ILP and payments. The Quilt brand is fairly strong in representing “interoperability”. This along with Mark’s point about distinguishing different interoperability projects is something that should be considered when making the decision.  

While the code that we are wanting to contribute is distinct from ILP, it does fall into the interoperability space. When we were discussing this with Adrian, David, Silona, and others, we did see a need for a set of overall maintainers to ensure that the projects that came into Quilt fell into the interoperability space and who would determine where overlap might exist for code sharing. 

Obviously, we will proceed as the TSC decides — be that to continue the process of bringing this under the Quilt brand or bringing a proposal for a new project to the TSC. We are looking forward to the continued discussion and decision. Please let me know if there are further items that I can clarify/answer. 

Tracy



Re: Quilt reboot, and "compound" projects

hmontgomery@us.fujitsu.com <hmontgomery@...>
 

I think we need to clarify what, exactly, a compound project *is* before we can say whether or not they make sense as projects. 

 

Does the compound project provide multiple different functionalities that reuse and share a lot of code?  It probably makes sense for this kind of thing to be a single project.

 

On the other hand, what if the compound project is a collection of different code bases for a similar functionality that don’t have any interconnection?  In this case, it probably makes sense to keep things separate.

 

I guess what I’m getting at is that I think it should be the level of interconnection between the components/modules/features/functions that should determine whether some collection of code is one project or multiple projects.  We could technically state that, say, Indy is a compound project because it has two “functionally different” libraries Indy-SDK and Indy-Node.  But this makes absolutely no sense due to the interconnection of the two code bases.

 

Does this make sense?  It’s been a long day of travel so it’s entirely possible this makes no sense.

 

I am also super-excited for a new interop proposal.

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Middleton, Dan
Sent: Saturday, June 22, 2019 8:14 PM
To: tsc@...
Subject: Re: [Hyperledger TSC] Quilt reboot, and "compound" projects

 

Compound projects feel a bit unnatural to me.

 

One elephant in the room is whether we can let projects end the lifecycle. I think that’s a really healthy thing for any portfolio.

I’m not so sensitive to the potential loss of name recognition. In this particular case, I don’t [yet] see an interest from the Quilt maintainers in progressing the ILP code. To me that signals the project is at its natural conclusion.

 

My view of Ursa is that we are still in the storming stage. I think as a team we are getting closer to its definition, but we shouldn’t point to it as a template of a compound project right now. In fact, if ursa turned into a bag of disjoint parts I don’t think it would be successful, but that’s a different thread.

 

A lot of what defines a project to me is the maintainers and contributor community around it and their shared drive to create a coherent piece of software. If we sideloaded a second code-base with a different set of developers that doesn’t feel like a unified project to me. That feels more like a branding decision that I think is overthinking our incubation stage.

 

(and to be clear I am very interested to see a new interop proposal and evaluate it on its own merits)

 

Regards,

 

Dan Middleton

Intel Principal Engineer

 

 

 

From: <tsc@...> on behalf of Vipin Bharathan <vipinsun@...>
Date: Saturday, June 22, 2019 at 6:06 AM
To: "tracy.a.kuhrt@..." <tracy.a.kuhrt@...>
Cc: "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] Quilt reboot, and "compound" projects

 

Hello Tracy,

If it is different from ILP, what is it? Will there be a doc describing it much like a project proposal. Any technical papers?  Is there code you would like to bring in? 

Best,

Vipin


On Jun 21, 2019, at 10:55 PM, tracy.a.kuhrt@... wrote:

Hi, Chris and other TSC members. 

The item that you are talking about (Helm charts, etc) is not the interoperability project that we want to contribute to Hyperledger. That will be separate discussion at some point in the future.

I had originally suggested we bring our interoperability contribution into Hyperledger Quilt because the TSC was clear when they approved Quilt that they wanted it to grow beyond just ILP to encompass interoperability. I know some people were communicating Quilt as an interoperability project (before we began the reboot discussion) even though it has always been “a Java-based ILP library” with direction from the TSC to be more. There is ton of interest in the ecosystem for interoperability beyond ILP and payments. The Quilt brand is fairly strong in representing “interoperability”. This along with Mark’s point about distinguishing different interoperability projects is something that should be considered when making the decision.  

While the code that we are wanting to contribute is distinct from ILP, it does fall into the interoperability space. When we were discussing this with Adrian, David, Silona, and others, we did see a need for a set of overall maintainers to ensure that the projects that came into Quilt fell into the interoperability space and who would determine where overlap might exist for code sharing. 

Obviously, we will proceed as the TSC decides — be that to continue the process of bringing this under the Quilt brand or bringing a proposal for a new project to the TSC. We are looking forward to the continued discussion and decision. Please let me know if there are further items that I can clarify/answer. 

Tracy



Re: Quilt reboot, and "compound" projects

Middleton, Dan <dan.middleton@...>
 

Compound projects feel a bit unnatural to me.

 

One elephant in the room is whether we can let projects end the lifecycle. I think that’s a really healthy thing for any portfolio.

I’m not so sensitive to the potential loss of name recognition. In this particular case, I don’t [yet] see an interest from the Quilt maintainers in progressing the ILP code. To me that signals the project is at its natural conclusion.

 

My view of Ursa is that we are still in the storming stage. I think as a team we are getting closer to its definition, but we shouldn’t point to it as a template of a compound project right now. In fact, if ursa turned into a bag of disjoint parts I don’t think it would be successful, but that’s a different thread.

 

A lot of what defines a project to me is the maintainers and contributor community around it and their shared drive to create a coherent piece of software. If we sideloaded a second code-base with a different set of developers that doesn’t feel like a unified project to me. That feels more like a branding decision that I think is overthinking our incubation stage.

 

(and to be clear I am very interested to see a new interop proposal and evaluate it on its own merits)

 

Regards,

 

Dan Middleton

Intel Principal Engineer

 

 

 

From: <tsc@...> on behalf of Vipin Bharathan <vipinsun@...>
Date: Saturday, June 22, 2019 at 6:06 AM
To: "tracy.a.kuhrt@..." <tracy.a.kuhrt@...>
Cc: "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] Quilt reboot, and "compound" projects

 

Hello Tracy,

If it is different from ILP, what is it? Will there be a doc describing it much like a project proposal. Any technical papers?  Is there code you would like to bring in? 

Best,

Vipin


On Jun 21, 2019, at 10:55 PM, tracy.a.kuhrt@... wrote:

Hi, Chris and other TSC members. 

The item that you are talking about (Helm charts, etc) is not the interoperability project that we want to contribute to Hyperledger. That will be separate discussion at some point in the future.

I had originally suggested we bring our interoperability contribution into Hyperledger Quilt because the TSC was clear when they approved Quilt that they wanted it to grow beyond just ILP to encompass interoperability. I know some people were communicating Quilt as an interoperability project (before we began the reboot discussion) even though it has always been “a Java-based ILP library” with direction from the TSC to be more. There is ton of interest in the ecosystem for interoperability beyond ILP and payments. The Quilt brand is fairly strong in representing “interoperability”. This along with Mark’s point about distinguishing different interoperability projects is something that should be considered when making the decision.  

While the code that we are wanting to contribute is distinct from ILP, it does fall into the interoperability space. When we were discussing this with Adrian, David, Silona, and others, we did see a need for a set of overall maintainers to ensure that the projects that came into Quilt fell into the interoperability space and who would determine where overlap might exist for code sharing. 

Obviously, we will proceed as the TSC decides — be that to continue the process of bringing this under the Quilt brand or bringing a proposal for a new project to the TSC. We are looking forward to the continued discussion and decision. Please let me know if there are further items that I can clarify/answer. 

Tracy




Re: Quilt reboot, and "compound" projects

Vipin Bharathan
 

Hello Tracy,
If it is different from ILP, what is it? Will there be a doc describing it much like a project proposal. Any technical papers?  Is there code you would like to bring in? 
Best,
Vipin


On Jun 21, 2019, at 10:55 PM, tracy.a.kuhrt@... wrote:

Hi, Chris and other TSC members. 

The item that you are talking about (Helm charts, etc) is not the interoperability project that we want to contribute to Hyperledger. That will be separate discussion at some point in the future.

I had originally suggested we bring our interoperability contribution into Hyperledger Quilt because the TSC was clear when they approved Quilt that they wanted it to grow beyond just ILP to encompass interoperability. I know some people were communicating Quilt as an interoperability project (before we began the reboot discussion) even though it has always been “a Java-based ILP library” with direction from the TSC to be more. There is ton of interest in the ecosystem for interoperability beyond ILP and payments. The Quilt brand is fairly strong in representing “interoperability”. This along with Mark’s point about distinguishing different interoperability projects is something that should be considered when making the decision.  

While the code that we are wanting to contribute is distinct from ILP, it does fall into the interoperability space. When we were discussing this with Adrian, David, Silona, and others, we did see a need for a set of overall maintainers to ensure that the projects that came into Quilt fell into the interoperability space and who would determine where overlap might exist for code sharing. 

Obviously, we will proceed as the TSC decides — be that to continue the process of bringing this under the Quilt brand or bringing a proposal for a new project to the TSC. We are looking forward to the continued discussion and decision. Please let me know if there are further items that I can clarify/answer. 

Tracy



Re: Quilt reboot, and "compound" projects

Kuhrt, Tracy A.
 

Hi, Chris and other TSC members. 

The item that you are talking about (Helm charts, etc) is not the interoperability project that we want to contribute to Hyperledger. That will be separate discussion at some point in the future.

I had originally suggested we bring our interoperability contribution into Hyperledger Quilt because the TSC was clear when they approved Quilt that they wanted it to grow beyond just ILP to encompass interoperability. I know some people were communicating Quilt as an interoperability project (before we began the reboot discussion) even though it has always been “a Java-based ILP library” with direction from the TSC to be more. There is ton of interest in the ecosystem for interoperability beyond ILP and payments. The Quilt brand is fairly strong in representing “interoperability”. This along with Mark’s point about distinguishing different interoperability projects is something that should be considered when making the decision.  

While the code that we are wanting to contribute is distinct from ILP, it does fall into the interoperability space. When we were discussing this with Adrian, David, Silona, and others, we did see a need for a set of overall maintainers to ensure that the projects that came into Quilt fell into the interoperability space and who would determine where overlap might exist for code sharing. 

Obviously, we will proceed as the TSC decides — be that to continue the process of bringing this under the Quilt brand or bringing a proposal for a new project to the TSC. We are looking forward to the continued discussion and decision. Please let me know if there are further items that I can clarify/answer. 

Tracy



Re: Quilt reboot, and "compound" projects

Christopher Ferris <chris.ferris@...>
 

I could be wrong, of course. Tracy is the expert here.

Chris

On Jun 21, 2019, at 1:45 PM, "hmontgomery@..." <hmontgomery@...> wrote:

Hi Chris,

 

Thanks for the response.

 

First, on bloat:  we avoid bloat by having customizable builds (that only incorporate what people themselves need).  For instance, right now we have and Indy-SDK build that only pulls in the things needed from Indy SDK, and, in the future, we are planning on having other builds for similar projects (or project components).  I believe Mike and other are working on a build for Indy-Node, some people are working on an Iroha build, and we have begun figuring out what a Sawtooth build would look like.  Dave, Mike, and Dan, among others, have done an awesome job working out how this works.

 

As far as Quilt:  I haven’t seen the Accenture proposal, so I don’t know exactly what they are doing.  If they aren’t using ILP or code from Quilt in any way, then yes, it probably makes more sense to have a separate project.  Given your understanding of the situation, your conclusion makes perfect sense.  Thanks for sharing the extra information here.

 

Thanks,

Hart

 

From: Christopher B Ferris [mailto:chrisfer@...]
Sent: Friday, June 21, 2019 10:36 AM
To: Montgomery, Hart <hmontgomery@...>
Cc: bbehlendorf@...; tsc@...
Subject: Re: RE: [Hyperledger TSC] Quilt reboot, and "compound" projects

 

Hart,

 

I am not suggesting that you bust up Ursa, though TBH, I have not looked closely at how you avoid bloat as we add more algorithms but a consumer only needs one of them.

 

I am saying that my understanding of some of the things being proposed to go into Quilt have nothing to do with ILP.

 

Quilt is not some panacea for blockchain interoperability. It is a Java implementation of the ILP protocol. I had heard that the Accenture folk were considering bringing the Helm chart stuff that made deploying Fabric or Sawtooth etc interoperable. Not the same thing.

 

Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Cognitive Applications
email: chrisfer@...
twitter: @christo4ferris

IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Montgomery, Hart" <hmontgomery@...>
To: Christopher Ferris <chrisfer@...>, "bbehlendorf@..." <bbehlendorf@...>
Cc: "tsc@..." <tsc@...>
Subject: [EXTERNAL] RE: [Hyperledger TSC] Quilt reboot, and "compound" projects
Date: Fri, Jun 21, 2019 12:55 PM
 

Hi Chris,

 

I’m not sure I necessarily agree with this.  I don’t know the full details of the interoperability proposals, so I can’t say for sure, but I can elaborate from my experiences on Ursa.

 

Ursa is, essentially, one project for cryptography code.  It’s option (a) that you describe for cryptography.  We have sub-libraries that address different things:  right now, we have Ursa-lib for basic crypto and threshold signatures, and zmix for our zero knowledge primitives.  We may be adding multiparty computation soon as well.

 

We could have split it up into multiple projects, each of which addressed a particular portion of crypto code that people wanted to use, but that would have been very inefficient:  we reuse code between different modules, and separate projects probably would have resulted in a lot of needless duplication.  In addition, having one project rather than many allows us to concentrate our cryptographic talent all across the spectrum (from almost-mathematicians to engineers) in a single place.  Multiple projects would mean multiple, separate meetings, mailing lists, etc. for each project and coordination would be very, very difficult.  This would be frustrating if people were involved in many different small projects instead of one “umbrella” project (and, in Ursa, most people work on all of the sub-libraries to some extent).

 

I guess what I’m saying is that I don’t think the “five projects that address various aspects” of cryptography would have worked at all for Ursa, and I think it would have in fact been a nightmare to manage.

 

On the other hand, interoperability might be different.  If the small projects are working on completely different things and there isn’t any reuse of code between them, then it probably makes sense to have different projects (but again, this is a situation that isn’t indicative of good cross-platform cooperation).  On the other hand, if they are going to use each other’s code and contributors are planning on working on multiple different interoperability projects, then the small project approach probably doesn’t make sense.  So, while I don’t know what the correct solution is at this point for interoperability (we haven’t seen the proposals), I think it’s premature to assume that the multiple small projects approach will work better than the one “umbrella” project.

 

Does this make sense?  Thanks a lot for reading.

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Christopher Ferris
Sent: Friday, June 21, 2019 5:46 AM
To: bbehlendorf@...
Cc: tsc@...
Subject: Re: [Hyperledger TSC] Quilt reboot, and "compound" projects

 

So, I find myself thinking that we'd be better off with a number of smaller, component-level projects that can be (re)used and composed, than adding (or adding to) larger sprawling ones. I say this because a) it lowers the barrier to entry somewhat and b) it will (hopefully) spur more cross-project engagement and collaboration, along the lines of Transact or Ursa.

 

Think about it. Which sounds more compelling:

a) we have one project for interop

b) we have five projects that address various aspects of DLT interop

 

I find (b) more compelling. Interoperability is complex and has a number of aspects ranging from the underlying messaging protocol, to the transaction formats, to the shared domain-specific data standards.

 

It will mean that as a TSC, we will need to start tackling some of the x-project considerations. This was inevitable, but I think A Good Thing(tm).

 

Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Cognitive Applications
email: chrisfer@...
twitter: @christo4ferris

IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Brian Behlendorf" <bbehlendorf@...>
Sent by: tsc@...
To: "tsc@..." <tsc@...>
Cc:
Subject: [EXTERNAL] [Hyperledger TSC] Quilt reboot, and "compound" projects
Date: Thu, Jun 20, 2019 8:41 PM
 

Hi TSC, continuing the conversation we had started but didn't have
enough time to fully articulate on the call.  So that makes this the
"Quilt Update" due for today.

A few months ago, we started discussing the future of Quilt with its
current maintainers, as well as with a set of people who had expressed
to us an interest in the topic of cross-ledger inter-operability after
our call-out for such interest on a number of TSC calls for a "Quilt
reboot".  We also had heard of at least 2 new potential packages of code
that could come in, addressing "inter-operability" differently, but in
highly complementary ways to each other and to Quilt.  So we started to
get everyone talking, and talking with each other.  I want to emphasize
that the current Quilt maintainers welcomed this discussion and
participated actively.

Quilt itself, the Java implementation of the ILP spec, is not dead - it
has responsive maintainers and a small but active userbase. But the
current maintainers are just out of energy to do more than answer some
basic questions or fix security holes if any appeared.  And, it's been
tough to get Quilt's users interested in becoming contributors.  There
is still lots of work that could be done on Quilt, so it's not
complete.  Bugs do get fixed, sources updated.  It hasn't "taken off"
nor by itself grown to encompass other potential ways to build bridges
across different DLT system, but it's also something that continues to
create value, and where if bugs (particularly security holes) are found
and come with a PR, that does get attention.  But the two current
maintainers had sent a clear message they didn't have time to actively
recruit new users or do more than basic life support. So it's an odd
state of "quiet, but not dead" that doesn't necessarily deserve being
archived or effectively removed from the community, but isn't as active
as we'd probably all like it to be.

It was felt that new activity within the same project boundaries but on
different code might lead developers and thus improvements into a
"quilt-ilp-java". Also, these new projects weren't quite sure whether
their boundaries were clearly and firmly separate - that merging their
efforts might make sense, possibly in the short term, possibly in the
long term.

So instead of just asking "how do we reboot the Quilt project in
isolation", the question we posed to this group we had convened was
whether the Quilt developers felt there was value to combining all the
code together into a single repo, or alternately adding new
complementary sub-projects and repos within Quilt, making
"quilt-ilp-java" a peer to however many others.  And, whether those
projects would connect with each other and find common cause in the same
way we hope other sub-projects do already, though absent a major parent
project like e.g. fabric and fabric-sdk-*. We also asked the folks on
these other projects (like from Accenture, which as Tracy mentioned
today on the call has some code they'd like to bring in) whether they
felt better being part of a compound project, or would feel better
submitting as independently branded new top-level projects or through
Labs.  The sense on the call, from what we could tell, seemed to be in
favor of putting this together as a sub-projects within a single project
still called Quilt, still limited to the scope as approved by the TSC,
benefiting from the promotion we've done to date that Quilt is about
interop, and hoping that interest in one piece can drive attention or
more to another pieces.  It also seemed clear we should take any
proposal like this to the TSC for approval, since there was substantial
new code potentially coming in, and we didn't want folks thinking that
the ordinary function the TSC provides to review large new contributions
coming in was being routed around.  Essentially, a TSC vote on the
"Quilt Reboot" that included new code and maintainers but adhering to
the original scope and ideals, should still be held to the same
standards for any new project, with regards to code quality, likelihood
for a new community to grow around it, vendor neutrality, and so on.

After the call, I admit, we got busy.  CA team members got sick or went
on leave.  The followup to this meeting was on our shoulders to turn
into a proposal document for the TSC, and work with the existing Quilt
maintainers and these new potential maintainers to make that a
compelling proposal, and also coordinate with other TSC a bit ahead of
time as we often do with new project proposals so that when they're
proposed they have as few obvious issues as possible.  That work
progressed slowly. Plus, we were waiting for some of the proposed
contributions to actually become available for review.  We are coming
back around to this now.  This was one driver for the Chair discussion
we just had, as some participants felt it was important that the TSC not
feel like they were being handed a hard-to-manage situation with lots of
new faces, and it was something the CA's had started to feel would be
useful as a formal role anyways.  We didn't want to propose them at the
same time conflating the two issues.  With that Chair issue now
concluded by the TSC, we are hoping to make a Quilt reboot proposal soon
for the TSC's consideration.

Now, meanwhile, there is re-thinking going on about the project
lifecycle, and the role of sub-projects within those - we'll have to
align with that of course, but we hadn't yet seen in those discussions a
reason to stop this proposal.  I think defining the responsibility
sub-projects have to their parent/container and then to the TSC is still
important of course.  But I didn't sense that the TSC would do away with
sub-projects or require them to associate all subs with a parent
codebase as a policy matter.  And policing for such activity within
established projects is tough anyways.

That's where we are.  While I know Dan M has in general felt uneasy
about these sort of thematic "compound" projects (I know I would without
some of the constraints I mention above, like TSC approval for new major
components), I didn't want the TSC to be asked to consider a proposal
for or against such things in the abstract without a live example to
consider.  But if the TSC as a whole feels it's important to set a firm
policy here, we'll of course go along with that and recommend these
projects be submitted independently, and that some reasonable status
with the existing Quilt that covers the Java port of ILP be arrived at
which still allows its users to report bugs and make occasional releases
and new maintainers to emerge.

Thanks,

Brian

--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf





 

 

 

 

 


Re: Quilt reboot, and "compound" projects

hmontgomery@us.fujitsu.com <hmontgomery@...>
 

Hi Chris,

 

Thanks for the response.

 

First, on bloat:  we avoid bloat by having customizable builds (that only incorporate what people themselves need).  For instance, right now we have and Indy-SDK build that only pulls in the things needed from Indy SDK, and, in the future, we are planning on having other builds for similar projects (or project components).  I believe Mike and other are working on a build for Indy-Node, some people are working on an Iroha build, and we have begun figuring out what a Sawtooth build would look like.  Dave, Mike, and Dan, among others, have done an awesome job working out how this works.

 

As far as Quilt:  I haven’t seen the Accenture proposal, so I don’t know exactly what they are doing.  If they aren’t using ILP or code from Quilt in any way, then yes, it probably makes more sense to have a separate project.  Given your understanding of the situation, your conclusion makes perfect sense.  Thanks for sharing the extra information here.

 

Thanks,

Hart

 

From: Christopher B Ferris [mailto:chrisfer@...]
Sent: Friday, June 21, 2019 10:36 AM
To: Montgomery, Hart <hmontgomery@...>
Cc: bbehlendorf@...; tsc@...
Subject: Re: RE: [Hyperledger TSC] Quilt reboot, and "compound" projects

 

Hart,

 

I am not suggesting that you bust up Ursa, though TBH, I have not looked closely at how you avoid bloat as we add more algorithms but a consumer only needs one of them.

 

I am saying that my understanding of some of the things being proposed to go into Quilt have nothing to do with ILP.

 

Quilt is not some panacea for blockchain interoperability. It is a Java implementation of the ILP protocol. I had heard that the Accenture folk were considering bringing the Helm chart stuff that made deploying Fabric or Sawtooth etc interoperable. Not the same thing.

 

Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Cognitive Applications
email: chrisfer@...
twitter: @christo4ferris

IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Montgomery, Hart" <hmontgomery@...>
To: Christopher Ferris <chrisfer@...>, "bbehlendorf@..." <bbehlendorf@...>
Cc: "tsc@..." <tsc@...>
Subject: [EXTERNAL] RE: [Hyperledger TSC] Quilt reboot, and "compound" projects
Date: Fri, Jun 21, 2019 12:55 PM
 

Hi Chris,

 

I’m not sure I necessarily agree with this.  I don’t know the full details of the interoperability proposals, so I can’t say for sure, but I can elaborate from my experiences on Ursa.

 

Ursa is, essentially, one project for cryptography code.  It’s option (a) that you describe for cryptography.  We have sub-libraries that address different things:  right now, we have Ursa-lib for basic crypto and threshold signatures, and zmix for our zero knowledge primitives.  We may be adding multiparty computation soon as well.

 

We could have split it up into multiple projects, each of which addressed a particular portion of crypto code that people wanted to use, but that would have been very inefficient:  we reuse code between different modules, and separate projects probably would have resulted in a lot of needless duplication.  In addition, having one project rather than many allows us to concentrate our cryptographic talent all across the spectrum (from almost-mathematicians to engineers) in a single place.  Multiple projects would mean multiple, separate meetings, mailing lists, etc. for each project and coordination would be very, very difficult.  This would be frustrating if people were involved in many different small projects instead of one “umbrella” project (and, in Ursa, most people work on all of the sub-libraries to some extent).

 

I guess what I’m saying is that I don’t think the “five projects that address various aspects” of cryptography would have worked at all for Ursa, and I think it would have in fact been a nightmare to manage.

 

On the other hand, interoperability might be different.  If the small projects are working on completely different things and there isn’t any reuse of code between them, then it probably makes sense to have different projects (but again, this is a situation that isn’t indicative of good cross-platform cooperation).  On the other hand, if they are going to use each other’s code and contributors are planning on working on multiple different interoperability projects, then the small project approach probably doesn’t make sense.  So, while I don’t know what the correct solution is at this point for interoperability (we haven’t seen the proposals), I think it’s premature to assume that the multiple small projects approach will work better than the one “umbrella” project.

 

Does this make sense?  Thanks a lot for reading.

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Christopher Ferris
Sent: Friday, June 21, 2019 5:46 AM
To: bbehlendorf@...
Cc: tsc@...
Subject: Re: [Hyperledger TSC] Quilt reboot, and "compound" projects

 

So, I find myself thinking that we'd be better off with a number of smaller, component-level projects that can be (re)used and composed, than adding (or adding to) larger sprawling ones. I say this because a) it lowers the barrier to entry somewhat and b) it will (hopefully) spur more cross-project engagement and collaboration, along the lines of Transact or Ursa.

 

Think about it. Which sounds more compelling:

a) we have one project for interop

b) we have five projects that address various aspects of DLT interop

 

I find (b) more compelling. Interoperability is complex and has a number of aspects ranging from the underlying messaging protocol, to the transaction formats, to the shared domain-specific data standards.

 

It will mean that as a TSC, we will need to start tackling some of the x-project considerations. This was inevitable, but I think A Good Thing(tm).

 

Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Cognitive Applications
email: chrisfer@...
twitter: @christo4ferris

IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Brian Behlendorf" <bbehlendorf@...>
Sent by: tsc@...
To: "tsc@..." <tsc@...>
Cc:
Subject: [EXTERNAL] [Hyperledger TSC] Quilt reboot, and "compound" projects
Date: Thu, Jun 20, 2019 8:41 PM
 

Hi TSC, continuing the conversation we had started but didn't have
enough time to fully articulate on the call.  So that makes this the
"Quilt Update" due for today.

A few months ago, we started discussing the future of Quilt with its
current maintainers, as well as with a set of people who had expressed
to us an interest in the topic of cross-ledger inter-operability after
our call-out for such interest on a number of TSC calls for a "Quilt
reboot".  We also had heard of at least 2 new potential packages of code
that could come in, addressing "inter-operability" differently, but in
highly complementary ways to each other and to Quilt.  So we started to
get everyone talking, and talking with each other.  I want to emphasize
that the current Quilt maintainers welcomed this discussion and
participated actively.

Quilt itself, the Java implementation of the ILP spec, is not dead - it
has responsive maintainers and a small but active userbase. But the
current maintainers are just out of energy to do more than answer some
basic questions or fix security holes if any appeared.  And, it's been
tough to get Quilt's users interested in becoming contributors.  There
is still lots of work that could be done on Quilt, so it's not
complete.  Bugs do get fixed, sources updated.  It hasn't "taken off"
nor by itself grown to encompass other potential ways to build bridges
across different DLT system, but it's also something that continues to
create value, and where if bugs (particularly security holes) are found
and come with a PR, that does get attention.  But the two current
maintainers had sent a clear message they didn't have time to actively
recruit new users or do more than basic life support. So it's an odd
state of "quiet, but not dead" that doesn't necessarily deserve being
archived or effectively removed from the community, but isn't as active
as we'd probably all like it to be.

It was felt that new activity within the same project boundaries but on
different code might lead developers and thus improvements into a
"quilt-ilp-java". Also, these new projects weren't quite sure whether
their boundaries were clearly and firmly separate - that merging their
efforts might make sense, possibly in the short term, possibly in the
long term.

So instead of just asking "how do we reboot the Quilt project in
isolation", the question we posed to this group we had convened was
whether the Quilt developers felt there was value to combining all the
code together into a single repo, or alternately adding new
complementary sub-projects and repos within Quilt, making
"quilt-ilp-java" a peer to however many others.  And, whether those
projects would connect with each other and find common cause in the same
way we hope other sub-projects do already, though absent a major parent
project like e.g. fabric and fabric-sdk-*. We also asked the folks on
these other projects (like from Accenture, which as Tracy mentioned
today on the call has some code they'd like to bring in) whether they
felt better being part of a compound project, or would feel better
submitting as independently branded new top-level projects or through
Labs.  The sense on the call, from what we could tell, seemed to be in
favor of putting this together as a sub-projects within a single project
still called Quilt, still limited to the scope as approved by the TSC,
benefiting from the promotion we've done to date that Quilt is about
interop, and hoping that interest in one piece can drive attention or
more to another pieces.  It also seemed clear we should take any
proposal like this to the TSC for approval, since there was substantial
new code potentially coming in, and we didn't want folks thinking that
the ordinary function the TSC provides to review large new contributions
coming in was being routed around.  Essentially, a TSC vote on the
"Quilt Reboot" that included new code and maintainers but adhering to
the original scope and ideals, should still be held to the same
standards for any new project, with regards to code quality, likelihood
for a new community to grow around it, vendor neutrality, and so on.

After the call, I admit, we got busy.  CA team members got sick or went
on leave.  The followup to this meeting was on our shoulders to turn
into a proposal document for the TSC, and work with the existing Quilt
maintainers and these new potential maintainers to make that a
compelling proposal, and also coordinate with other TSC a bit ahead of
time as we often do with new project proposals so that when they're
proposed they have as few obvious issues as possible.  That work
progressed slowly. Plus, we were waiting for some of the proposed
contributions to actually become available for review.  We are coming
back around to this now.  This was one driver for the Chair discussion
we just had, as some participants felt it was important that the TSC not
feel like they were being handed a hard-to-manage situation with lots of
new faces, and it was something the CA's had started to feel would be
useful as a formal role anyways.  We didn't want to propose them at the
same time conflating the two issues.  With that Chair issue now
concluded by the TSC, we are hoping to make a Quilt reboot proposal soon
for the TSC's consideration.

Now, meanwhile, there is re-thinking going on about the project
lifecycle, and the role of sub-projects within those - we'll have to
align with that of course, but we hadn't yet seen in those discussions a
reason to stop this proposal.  I think defining the responsibility
sub-projects have to their parent/container and then to the TSC is still
important of course.  But I didn't sense that the TSC would do away with
sub-projects or require them to associate all subs with a parent
codebase as a policy matter.  And policing for such activity within
established projects is tough anyways.

That's where we are.  While I know Dan M has in general felt uneasy
about these sort of thematic "compound" projects (I know I would without
some of the constraints I mention above, like TSC approval for new major
components), I didn't want the TSC to be asked to consider a proposal
for or against such things in the abstract without a live example to
consider.  But if the TSC as a whole feels it's important to set a firm
policy here, we'll of course go along with that and recommend these
projects be submitted independently, and that some reasonable status
with the existing Quilt that covers the Java port of ILP be arrived at
which still allows its users to report bugs and make occasional releases
and new maintainers to emerge.

Thanks,

Brian

--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf





 

 

 

 

 


Re: Quilt reboot, and "compound" projects

Christopher Ferris <chrisfer@...>
 

Hart,
 
I am not suggesting that you bust up Ursa, though TBH, I have not looked closely at how you avoid bloat as we add more algorithms but a consumer only needs one of them.
 
I am saying that my understanding of some of the things being proposed to go into Quilt have nothing to do with ILP.
 
Quilt is not some panacea for blockchain interoperability. It is a Java implementation of the ILP protocol. I had heard that the Accenture folk were considering bringing the Helm chart stuff that made deploying Fabric or Sawtooth etc interoperable. Not the same thing.
 
Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Cognitive Applications
email: chrisfer@...
twitter: @christo4ferris
IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
phone: +1 508 667 0402
 
 

----- Original message -----
From: "Montgomery, Hart" <hmontgomery@...>
To: Christopher Ferris <chrisfer@...>, "bbehlendorf@..." <bbehlendorf@...>
Cc: "tsc@..." <tsc@...>
Subject: [EXTERNAL] RE: [Hyperledger TSC] Quilt reboot, and "compound" projects
Date: Fri, Jun 21, 2019 12:55 PM
 

Hi Chris,

 

I’m not sure I necessarily agree with this.  I don’t know the full details of the interoperability proposals, so I can’t say for sure, but I can elaborate from my experiences on Ursa.

 

Ursa is, essentially, one project for cryptography code.  It’s option (a) that you describe for cryptography.  We have sub-libraries that address different things:  right now, we have Ursa-lib for basic crypto and threshold signatures, and zmix for our zero knowledge primitives.  We may be adding multiparty computation soon as well.

 

We could have split it up into multiple projects, each of which addressed a particular portion of crypto code that people wanted to use, but that would have been very inefficient:  we reuse code between different modules, and separate projects probably would have resulted in a lot of needless duplication.  In addition, having one project rather than many allows us to concentrate our cryptographic talent all across the spectrum (from almost-mathematicians to engineers) in a single place.  Multiple projects would mean multiple, separate meetings, mailing lists, etc. for each project and coordination would be very, very difficult.  This would be frustrating if people were involved in many different small projects instead of one “umbrella” project (and, in Ursa, most people work on all of the sub-libraries to some extent).

 

I guess what I’m saying is that I don’t think the “five projects that address various aspects” of cryptography would have worked at all for Ursa, and I think it would have in fact been a nightmare to manage.

 

On the other hand, interoperability might be different.  If the small projects are working on completely different things and there isn’t any reuse of code between them, then it probably makes sense to have different projects (but again, this is a situation that isn’t indicative of good cross-platform cooperation).  On the other hand, if they are going to use each other’s code and contributors are planning on working on multiple different interoperability projects, then the small project approach probably doesn’t make sense.  So, while I don’t know what the correct solution is at this point for interoperability (we haven’t seen the proposals), I think it’s premature to assume that the multiple small projects approach will work better than the one “umbrella” project.

 

Does this make sense?  Thanks a lot for reading.

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Christopher Ferris
Sent: Friday, June 21, 2019 5:46 AM
To: bbehlendorf@...
Cc: tsc@...
Subject: Re: [Hyperledger TSC] Quilt reboot, and "compound" projects

 

So, I find myself thinking that we'd be better off with a number of smaller, component-level projects that can be (re)used and composed, than adding (or adding to) larger sprawling ones. I say this because a) it lowers the barrier to entry somewhat and b) it will (hopefully) spur more cross-project engagement and collaboration, along the lines of Transact or Ursa.

 

Think about it. Which sounds more compelling:

a) we have one project for interop

b) we have five projects that address various aspects of DLT interop

 

I find (b) more compelling. Interoperability is complex and has a number of aspects ranging from the underlying messaging protocol, to the transaction formats, to the shared domain-specific data standards.

 

It will mean that as a TSC, we will need to start tackling some of the x-project considerations. This was inevitable, but I think A Good Thing(tm).

 

Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Cognitive Applications
email: chrisfer@...
twitter: @christo4ferris

IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Brian Behlendorf" <bbehlendorf@...>
Sent by: tsc@...
To: "tsc@..." <tsc@...>
Cc:
Subject: [EXTERNAL] [Hyperledger TSC] Quilt reboot, and "compound" projects
Date: Thu, Jun 20, 2019 8:41 PM
 

Hi TSC, continuing the conversation we had started but didn't have
enough time to fully articulate on the call.  So that makes this the
"Quilt Update" due for today.

A few months ago, we started discussing the future of Quilt with its
current maintainers, as well as with a set of people who had expressed
to us an interest in the topic of cross-ledger inter-operability after
our call-out for such interest on a number of TSC calls for a "Quilt
reboot".  We also had heard of at least 2 new potential packages of code
that could come in, addressing "inter-operability" differently, but in
highly complementary ways to each other and to Quilt.  So we started to
get everyone talking, and talking with each other.  I want to emphasize
that the current Quilt maintainers welcomed this discussion and
participated actively.

Quilt itself, the Java implementation of the ILP spec, is not dead - it
has responsive maintainers and a small but active userbase. But the
current maintainers are just out of energy to do more than answer some
basic questions or fix security holes if any appeared.  And, it's been
tough to get Quilt's users interested in becoming contributors.  There
is still lots of work that could be done on Quilt, so it's not
complete.  Bugs do get fixed, sources updated.  It hasn't "taken off"
nor by itself grown to encompass other potential ways to build bridges
across different DLT system, but it's also something that continues to
create value, and where if bugs (particularly security holes) are found
and come with a PR, that does get attention.  But the two current
maintainers had sent a clear message they didn't have time to actively
recruit new users or do more than basic life support. So it's an odd
state of "quiet, but not dead" that doesn't necessarily deserve being
archived or effectively removed from the community, but isn't as active
as we'd probably all like it to be.

It was felt that new activity within the same project boundaries but on
different code might lead developers and thus improvements into a
"quilt-ilp-java". Also, these new projects weren't quite sure whether
their boundaries were clearly and firmly separate - that merging their
efforts might make sense, possibly in the short term, possibly in the
long term.

So instead of just asking "how do we reboot the Quilt project in
isolation", the question we posed to this group we had convened was
whether the Quilt developers felt there was value to combining all the
code together into a single repo, or alternately adding new
complementary sub-projects and repos within Quilt, making
"quilt-ilp-java" a peer to however many others.  And, whether those
projects would connect with each other and find common cause in the same
way we hope other sub-projects do already, though absent a major parent
project like e.g. fabric and fabric-sdk-*. We also asked the folks on
these other projects (like from Accenture, which as Tracy mentioned
today on the call has some code they'd like to bring in) whether they
felt better being part of a compound project, or would feel better
submitting as independently branded new top-level projects or through
Labs.  The sense on the call, from what we could tell, seemed to be in
favor of putting this together as a sub-projects within a single project
still called Quilt, still limited to the scope as approved by the TSC,
benefiting from the promotion we've done to date that Quilt is about
interop, and hoping that interest in one piece can drive attention or
more to another pieces.  It also seemed clear we should take any
proposal like this to the TSC for approval, since there was substantial
new code potentially coming in, and we didn't want folks thinking that
the ordinary function the TSC provides to review large new contributions
coming in was being routed around.  Essentially, a TSC vote on the
"Quilt Reboot" that included new code and maintainers but adhering to
the original scope and ideals, should still be held to the same
standards for any new project, with regards to code quality, likelihood
for a new community to grow around it, vendor neutrality, and so on.

After the call, I admit, we got busy.  CA team members got sick or went
on leave.  The followup to this meeting was on our shoulders to turn
into a proposal document for the TSC, and work with the existing Quilt
maintainers and these new potential maintainers to make that a
compelling proposal, and also coordinate with other TSC a bit ahead of
time as we often do with new project proposals so that when they're
proposed they have as few obvious issues as possible.  That work
progressed slowly. Plus, we were waiting for some of the proposed
contributions to actually become available for review.  We are coming
back around to this now.  This was one driver for the Chair discussion
we just had, as some participants felt it was important that the TSC not
feel like they were being handed a hard-to-manage situation with lots of
new faces, and it was something the CA's had started to feel would be
useful as a formal role anyways.  We didn't want to propose them at the
same time conflating the two issues.  With that Chair issue now
concluded by the TSC, we are hoping to make a Quilt reboot proposal soon
for the TSC's consideration.

Now, meanwhile, there is re-thinking going on about the project
lifecycle, and the role of sub-projects within those - we'll have to
align with that of course, but we hadn't yet seen in those discussions a
reason to stop this proposal.  I think defining the responsibility
sub-projects have to their parent/container and then to the TSC is still
important of course.  But I didn't sense that the TSC would do away with
sub-projects or require them to associate all subs with a parent
codebase as a policy matter.  And policing for such activity within
established projects is tough anyways.

That's where we are.  While I know Dan M has in general felt uneasy
about these sort of thematic "compound" projects (I know I would without
some of the constraints I mention above, like TSC approval for new major
components), I didn't want the TSC to be asked to consider a proposal
for or against such things in the abstract without a live example to
consider.  But if the TSC as a whole feels it's important to set a firm
policy here, we'll of course go along with that and recommend these
projects be submitted independently, and that some reasonable status
with the existing Quilt that covers the Java port of ILP be arrived at
which still allows its users to report bugs and make occasional releases
and new maintainers to emerge.

Thanks,

Brian

--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf





 

 

 

 


Re: Quilt reboot, and "compound" projects

hmontgomery@us.fujitsu.com <hmontgomery@...>
 

Hi Chris,

 

I’m not sure I necessarily agree with this.  I don’t know the full details of the interoperability proposals, so I can’t say for sure, but I can elaborate from my experiences on Ursa.

 

Ursa is, essentially, one project for cryptography code.  It’s option (a) that you describe for cryptography.  We have sub-libraries that address different things:  right now, we have Ursa-lib for basic crypto and threshold signatures, and zmix for our zero knowledge primitives.  We may be adding multiparty computation soon as well.

 

We could have split it up into multiple projects, each of which addressed a particular portion of crypto code that people wanted to use, but that would have been very inefficient:  we reuse code between different modules, and separate projects probably would have resulted in a lot of needless duplication.  In addition, having one project rather than many allows us to concentrate our cryptographic talent all across the spectrum (from almost-mathematicians to engineers) in a single place.  Multiple projects would mean multiple, separate meetings, mailing lists, etc. for each project and coordination would be very, very difficult.  This would be frustrating if people were involved in many different small projects instead of one “umbrella” project (and, in Ursa, most people work on all of the sub-libraries to some extent).

 

I guess what I’m saying is that I don’t think the “five projects that address various aspects” of cryptography would have worked at all for Ursa, and I think it would have in fact been a nightmare to manage.

 

On the other hand, interoperability might be different.  If the small projects are working on completely different things and there isn’t any reuse of code between them, then it probably makes sense to have different projects (but again, this is a situation that isn’t indicative of good cross-platform cooperation).  On the other hand, if they are going to use each other’s code and contributors are planning on working on multiple different interoperability projects, then the small project approach probably doesn’t make sense.  So, while I don’t know what the correct solution is at this point for interoperability (we haven’t seen the proposals), I think it’s premature to assume that the multiple small projects approach will work better than the one “umbrella” project.

 

Does this make sense?  Thanks a lot for reading.

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Christopher Ferris
Sent: Friday, June 21, 2019 5:46 AM
To: bbehlendorf@...
Cc: tsc@...
Subject: Re: [Hyperledger TSC] Quilt reboot, and "compound" projects

 

So, I find myself thinking that we'd be better off with a number of smaller, component-level projects that can be (re)used and composed, than adding (or adding to) larger sprawling ones. I say this because a) it lowers the barrier to entry somewhat and b) it will (hopefully) spur more cross-project engagement and collaboration, along the lines of Transact or Ursa.

 

Think about it. Which sounds more compelling:

a) we have one project for interop

b) we have five projects that address various aspects of DLT interop

 

I find (b) more compelling. Interoperability is complex and has a number of aspects ranging from the underlying messaging protocol, to the transaction formats, to the shared domain-specific data standards.

 

It will mean that as a TSC, we will need to start tackling some of the x-project considerations. This was inevitable, but I think A Good Thing(tm).

 

Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Cognitive Applications
email: chrisfer@...
twitter: @christo4ferris

IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Brian Behlendorf" <bbehlendorf@...>
Sent by: tsc@...
To: "tsc@..." <tsc@...>
Cc:
Subject: [EXTERNAL] [Hyperledger TSC] Quilt reboot, and "compound" projects
Date: Thu, Jun 20, 2019 8:41 PM
 

Hi TSC, continuing the conversation we had started but didn't have
enough time to fully articulate on the call.  So that makes this the
"Quilt Update" due for today.

A few months ago, we started discussing the future of Quilt with its
current maintainers, as well as with a set of people who had expressed
to us an interest in the topic of cross-ledger inter-operability after
our call-out for such interest on a number of TSC calls for a "Quilt
reboot".  We also had heard of at least 2 new potential packages of code
that could come in, addressing "inter-operability" differently, but in
highly complementary ways to each other and to Quilt.  So we started to
get everyone talking, and talking with each other.  I want to emphasize
that the current Quilt maintainers welcomed this discussion and
participated actively.

Quilt itself, the Java implementation of the ILP spec, is not dead - it
has responsive maintainers and a small but active userbase. But the
current maintainers are just out of energy to do more than answer some
basic questions or fix security holes if any appeared.  And, it's been
tough to get Quilt's users interested in becoming contributors.  There
is still lots of work that could be done on Quilt, so it's not
complete.  Bugs do get fixed, sources updated.  It hasn't "taken off"
nor by itself grown to encompass other potential ways to build bridges
across different DLT system, but it's also something that continues to
create value, and where if bugs (particularly security holes) are found
and come with a PR, that does get attention.  But the two current
maintainers had sent a clear message they didn't have time to actively
recruit new users or do more than basic life support. So it's an odd
state of "quiet, but not dead" that doesn't necessarily deserve being
archived or effectively removed from the community, but isn't as active
as we'd probably all like it to be.

It was felt that new activity within the same project boundaries but on
different code might lead developers and thus improvements into a
"quilt-ilp-java". Also, these new projects weren't quite sure whether
their boundaries were clearly and firmly separate - that merging their
efforts might make sense, possibly in the short term, possibly in the
long term.

So instead of just asking "how do we reboot the Quilt project in
isolation", the question we posed to this group we had convened was
whether the Quilt developers felt there was value to combining all the
code together into a single repo, or alternately adding new
complementary sub-projects and repos within Quilt, making
"quilt-ilp-java" a peer to however many others.  And, whether those
projects would connect with each other and find common cause in the same
way we hope other sub-projects do already, though absent a major parent
project like e.g. fabric and fabric-sdk-*. We also asked the folks on
these other projects (like from Accenture, which as Tracy mentioned
today on the call has some code they'd like to bring in) whether they
felt better being part of a compound project, or would feel better
submitting as independently branded new top-level projects or through
Labs.  The sense on the call, from what we could tell, seemed to be in
favor of putting this together as a sub-projects within a single project
still called Quilt, still limited to the scope as approved by the TSC,
benefiting from the promotion we've done to date that Quilt is about
interop, and hoping that interest in one piece can drive attention or
more to another pieces.  It also seemed clear we should take any
proposal like this to the TSC for approval, since there was substantial
new code potentially coming in, and we didn't want folks thinking that
the ordinary function the TSC provides to review large new contributions
coming in was being routed around.  Essentially, a TSC vote on the
"Quilt Reboot" that included new code and maintainers but adhering to
the original scope and ideals, should still be held to the same
standards for any new project, with regards to code quality, likelihood
for a new community to grow around it, vendor neutrality, and so on.

After the call, I admit, we got busy.  CA team members got sick or went
on leave.  The followup to this meeting was on our shoulders to turn
into a proposal document for the TSC, and work with the existing Quilt
maintainers and these new potential maintainers to make that a
compelling proposal, and also coordinate with other TSC a bit ahead of
time as we often do with new project proposals so that when they're
proposed they have as few obvious issues as possible.  That work
progressed slowly. Plus, we were waiting for some of the proposed
contributions to actually become available for review.  We are coming
back around to this now.  This was one driver for the Chair discussion
we just had, as some participants felt it was important that the TSC not
feel like they were being handed a hard-to-manage situation with lots of
new faces, and it was something the CA's had started to feel would be
useful as a formal role anyways.  We didn't want to propose them at the
same time conflating the two issues.  With that Chair issue now
concluded by the TSC, we are hoping to make a Quilt reboot proposal soon
for the TSC's consideration.

Now, meanwhile, there is re-thinking going on about the project
lifecycle, and the role of sub-projects within those - we'll have to
align with that of course, but we hadn't yet seen in those discussions a
reason to stop this proposal.  I think defining the responsibility
sub-projects have to their parent/container and then to the TSC is still
important of course.  But I didn't sense that the TSC would do away with
sub-projects or require them to associate all subs with a parent
codebase as a policy matter.  And policing for such activity within
established projects is tough anyways.

That's where we are.  While I know Dan M has in general felt uneasy
about these sort of thematic "compound" projects (I know I would without
some of the constraints I mention above, like TSC approval for new major
components), I didn't want the TSC to be asked to consider a proposal
for or against such things in the abstract without a live example to
consider.  But if the TSC as a whole feels it's important to set a firm
policy here, we'll of course go along with that and recommend these
projects be submitted independently, and that some reasonable status
with the existing Quilt that covers the Java port of ILP be arrived at
which still allows its users to report bugs and make occasional releases
and new maintainers to emerge.

Thanks,

Brian

--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf




 

 

 


Re: Quilt reboot, and "compound" projects

mark wagner <mwagner@...>
 

First, Thanks Brian for articulating this and explaining the history in more detail. It greatly helps me understand the rational a bit better.

Folks I am torn on this one and will enjoy following the dialogue. But, to play "Devils Advocate":

I think we also need to be aware of our "customers", the end users. Given our plethora of frameworks, I am sure there is already lots of confusion as to "which one should I go with". If we start having a lot of interop projects that do similar things, we need to be ready to help the users understand the differences and make it easier for them to select the best project for their use case. If they are confused and talk to a commercial product vendor, then they will be told what the solution is that they should go with, and it won't be a Hyperledger based product.

To the points raised by Mr Ferris, I am torn. I agree that big sprawling projects aren't great, smaller projects can be more nimble, and they can provide more "freedom" for the folks working on them,  However, I think that we need a way to make sure that the different projects are somewhat co-ordinated. In general, while the Linux method is having at four different projects / applications to do the same thing, we can get more "bang for the buck' by having some level of coordination between the different projects to promote code reuse, making sure we close gaps in coverage, etc. If these projects will need a UI, we should strive to have a fairly common and consistent UI as applicable. Overall, this typically allows greater progress to be made in a similar timeframe.

While this type of co-ordination typically comes from big projects, perhaps we could be revolutionary and have something to promote code reuse, coordination, etc across the interop projects without having one big project?

I look at how the different framework projects are now starting to work together to have shared code, libraries, etc. This is a "Good Thing".  Is there a way to do that with interop without waiting three years or do we need that time to see what shakes out ?

-mark


On Fri, Jun 21, 2019 at 8:46 AM Christopher Ferris <chrisfer@...> wrote:
So, I find myself thinking that we'd be better off with a number of smaller, component-level projects that can be (re)used and composed, than adding (or adding to) larger sprawling ones. I say this because a) it lowers the barrier to entry somewhat and b) it will (hopefully) spur more cross-project engagement and collaboration, along the lines of Transact or Ursa.
 
Think about it. Which sounds more compelling:
a) we have one project for interop
b) we have five projects that address various aspects of DLT interop
 
I find (b) more compelling. Interoperability is complex and has a number of aspects ranging from the underlying messaging protocol, to the transaction formats, to the shared domain-specific data standards.
 
It will mean that as a TSC, we will need to start tackling some of the x-project considerations. This was inevitable, but I think A Good Thing(tm).
 
Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Cognitive Applications
email: chrisfer@...
twitter: @christo4ferris
IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
phone: +1 508 667 0402
 
 
----- Original message -----
From: "Brian Behlendorf" <bbehlendorf@...>
Sent by: tsc@...
To: "tsc@..." <tsc@...>
Cc:
Subject: [EXTERNAL] [Hyperledger TSC] Quilt reboot, and "compound" projects
Date: Thu, Jun 20, 2019 8:41 PM
 
Hi TSC, continuing the conversation we had started but didn't have
enough time to fully articulate on the call.  So that makes this the
"Quilt Update" due for today.

A few months ago, we started discussing the future of Quilt with its
current maintainers, as well as with a set of people who had expressed
to us an interest in the topic of cross-ledger inter-operability after
our call-out for such interest on a number of TSC calls for a "Quilt
reboot".  We also had heard of at least 2 new potential packages of code
that could come in, addressing "inter-operability" differently, but in
highly complementary ways to each other and to Quilt.  So we started to
get everyone talking, and talking with each other.  I want to emphasize
that the current Quilt maintainers welcomed this discussion and
participated actively.

Quilt itself, the Java implementation of the ILP spec, is not dead - it
has responsive maintainers and a small but active userbase. But the
current maintainers are just out of energy to do more than answer some
basic questions or fix security holes if any appeared.  And, it's been
tough to get Quilt's users interested in becoming contributors.  There
is still lots of work that could be done on Quilt, so it's not
complete.  Bugs do get fixed, sources updated.  It hasn't "taken off"
nor by itself grown to encompass other potential ways to build bridges
across different DLT system, but it's also something that continues to
create value, and where if bugs (particularly security holes) are found
and come with a PR, that does get attention.  But the two current
maintainers had sent a clear message they didn't have time to actively
recruit new users or do more than basic life support. So it's an odd
state of "quiet, but not dead" that doesn't necessarily deserve being
archived or effectively removed from the community, but isn't as active
as we'd probably all like it to be.

It was felt that new activity within the same project boundaries but on
different code might lead developers and thus improvements into a
"quilt-ilp-java". Also, these new projects weren't quite sure whether
their boundaries were clearly and firmly separate - that merging their
efforts might make sense, possibly in the short term, possibly in the
long term.

So instead of just asking "how do we reboot the Quilt project in
isolation", the question we posed to this group we had convened was
whether the Quilt developers felt there was value to combining all the
code together into a single repo, or alternately adding new
complementary sub-projects and repos within Quilt, making
"quilt-ilp-java" a peer to however many others.  And, whether those
projects would connect with each other and find common cause in the same
way we hope other sub-projects do already, though absent a major parent
project like e.g. fabric and fabric-sdk-*. We also asked the folks on
these other projects (like from Accenture, which as Tracy mentioned
today on the call has some code they'd like to bring in) whether they
felt better being part of a compound project, or would feel better
submitting as independently branded new top-level projects or through
Labs.  The sense on the call, from what we could tell, seemed to be in
favor of putting this together as a sub-projects within a single project
still called Quilt, still limited to the scope as approved by the TSC,
benefiting from the promotion we've done to date that Quilt is about
interop, and hoping that interest in one piece can drive attention or
more to another pieces.  It also seemed clear we should take any
proposal like this to the TSC for approval, since there was substantial
new code potentially coming in, and we didn't want folks thinking that
the ordinary function the TSC provides to review large new contributions
coming in was being routed around.  Essentially, a TSC vote on the
"Quilt Reboot" that included new code and maintainers but adhering to
the original scope and ideals, should still be held to the same
standards for any new project, with regards to code quality, likelihood
for a new community to grow around it, vendor neutrality, and so on.

After the call, I admit, we got busy.  CA team members got sick or went
on leave.  The followup to this meeting was on our shoulders to turn
into a proposal document for the TSC, and work with the existing Quilt
maintainers and these new potential maintainers to make that a
compelling proposal, and also coordinate with other TSC a bit ahead of
time as we often do with new project proposals so that when they're
proposed they have as few obvious issues as possible.  That work
progressed slowly. Plus, we were waiting for some of the proposed
contributions to actually become available for review.  We are coming
back around to this now.  This was one driver for the Chair discussion
we just had, as some participants felt it was important that the TSC not
feel like they were being handed a hard-to-manage situation with lots of
new faces, and it was something the CA's had started to feel would be
useful as a formal role anyways.  We didn't want to propose them at the
same time conflating the two issues.  With that Chair issue now
concluded by the TSC, we are hoping to make a Quilt reboot proposal soon
for the TSC's consideration.

Now, meanwhile, there is re-thinking going on about the project
lifecycle, and the role of sub-projects within those - we'll have to
align with that of course, but we hadn't yet seen in those discussions a
reason to stop this proposal.  I think defining the responsibility
sub-projects have to their parent/container and then to the TSC is still
important of course.  But I didn't sense that the TSC would do away with
sub-projects or require them to associate all subs with a parent
codebase as a policy matter.  And policing for such activity within
established projects is tough anyways.

That's where we are.  While I know Dan M has in general felt uneasy
about these sort of thematic "compound" projects (I know I would without
some of the constraints I mention above, like TSC approval for new major
components), I didn't want the TSC to be asked to consider a proposal
for or against such things in the abstract without a live example to
consider.  But if the TSC as a whole feels it's important to set a firm
policy here, we'll of course go along with that and recommend these
projects be submitted independently, and that some reasonable status
with the existing Quilt that covers the Java port of ILP be arrived at
which still allows its users to report bugs and make occasional releases
and new maintainers to emerge.

Thanks,

Brian

--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf




 
 



--
Mark Wagner
Senior Principal Software Engineer
Performance and Scalability
Red Hat, Inc

1481 - 1500 of 3892