Date   

Re: RocketChat Downtime

Anton Baranov <abaranov@...>
 

Maintenance will start shortry


On Mon, May 6, 2019 at 4:51 PM Tim Johnson <tijohnson@...> wrote:
We will be upgrading RocketChat, Tue May 7th at 08:00 EST. It should be back on-line within 30mins.
Let me know if this time is objectionable.

Tim


RocketChat Downtime

Tim Johnson <tijohnson@...>
 

We will be upgrading RocketChat, Tue May 7th at 08:00 EST. It should be back on-line within 30mins.
Let me know if this time is objectionable.

Tim


Add VRF(Verifiable Random Functions) Into Ordering Service to Support Large-scale COnsensus NetWork

宣章炯 <xzj19922010@...>
 

My name is Zhangjiong Xuan. I come from Hangzhou Qulian Technology Co., Ltd. We have a team to research Algorand and VRF Algorithm. Now we have implement the VRF Algorithm in the Golang. And we think there is a good scenario in the Hyperledger Fabric. So we want to ask the communitty if it’s a good Idea to use VRF Algorithm into Ordering Service, to do a feature in the Ordering Service. I hope TSC group can have a discussion whether will receive this proposal. If both of you think it's a good idea .Maybe we can have a try to do this job .And make a more detailed design in the google docs.

Thanks.


Jira:

Google doc:


RocketChat Downtime

Tim Johnson <tijohnson@...>
 

We will be upgrading RocketChat, Tue May 7th at 08:00 EST. It should be back on-line within 30mins.
Let me know if this time is objectionable. I will send out another reminder on Mon afternoon.

Tim


Re: Transact Project Proposal

Dan Selman
 

Also excited by this. Within the Accord Project (http://accordproject.org) we maintain the Open Source Cicero runtime and Ergo Domain Specific Language for Smart Contracts. We've already experimented with embedding Cicero within Fabric (via compilation to Node.js and Java), but if compilation to Transact could open the door to supporting other ledgers that would be of great interest to the AP community.

How can we get involved?

Thanks,
Dan

On Thu, Apr 18, 2019 at 6:50 PM Brian Behlendorf <bbehlendorf@...> wrote:
I'm super excited about this, as I've long hoped for a intermediate layer between DLT and smart contracts that might allow better componentization within HL as a whole.  And I'm happy to see the very thoughtful description of how this would relate to other Hyperledger projects, both planned and possible.  It'd be great to hear on-list or as comments to the proposal from devs involved in these other projects, and people thinking about other smart contract engines (like DAML) that could be plugged in.  Very happy to see Gari's name on the proposal as a sponsor, and hope this indicates a willingness from the Fabric team to spend more time with this.

Brian

On 4/17/19 6:21 PM, Shawn Amundson wrote:
I'm happy to extend this proposal to the TSC for future consideration on behalf of its sponsors:


From the proposal: "Transact is a transaction execution platform designed to be used as a library or component when implementing distributed ledgers, including blockchains. Hyperledger framework-level projects and custom distributed ledgers can make use of Transact's advanced transaction execution and state management to simplify the transaction execution code required within their projects or to gain additional features."

Please provide feedback to help us enhance this proposal!

Thanks,

-Shawn


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



--

Dan Selman

CTO

Email: dan@...

Mobile: +44 7785-792717

clause.io

social

This message is confidential and its contents shall not be distributed to any third parties without the permission of the sender. Similarly any documents that are marked as private and confidential or similar are strictly not for distribution or disclosure to any unaddressed parties, without exception. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake, please let us know by e-mail reply and delete it from your system. You may not copy this message or disclose its contents to anyone. The integrity and security of this message cannot be guaranteed on the Internet.


Upcoming Event: Hyperledger Burrow Quarterly Update Due #tsc-project-update - Thu, 05/09/2019 #cal-reminder #tsc-project-update

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

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

When: Thursday, 9 May 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Burrow update to the TSC was due 6 May, 2019, and it will be presented to the TSC on 9 May, 2019. Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


Upcoming Event: Hyperledger Performance and Scalability WG Quarterly Update Due #tsc-wg-update - Thu, 05/09/2019 #cal-reminder #tsc-wg-update

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

Reminder: Hyperledger Performance and Scalability WG Quarterly Update Due #tsc-wg-update

When: Thursday, 9 May 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Performance and Scalability WG update to the TSC was due 6 May, 2019, and it will be presented to the TSC on 9 May, 2019. Please review the update at TSC Working Group Updates prior to the meeting and add your questions to the update.


Re: Gid DID spec work

Arnaud Le Hors
 

Interesting idea but isn't depending on a fully centralized system owned by a corporation defeating the whole point of DIDs?
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Dave Huseby" <dhuseby@...>
To:        Hyperledger List <tsc@...>
Date:        05/05/2019 09:50 PM
Subject:        [Hyperledger TSC] Gid DID spec work
Sent by:        tsc@...




Hi TSC,

I attended the Internet Identity Workshop last week and decided to organize sessions on a solution to the DCO problem that I've been chewing on for more than a year now. I proposed sessions to work out a Git DID method spec and all of the details around it. For those of you not familiar with what I'm talking about, you've got a lot of reading :) DID primer DID spec DID method registry Understanding DIDs

The short cut explanation is that this is an effort to teach Git how to understand digital signatures on commits made by self-sovereign identities and how to store those identities in the repo itself. Another aspect of this is how to encode governance rules (think: transaction validation/"smart contracts") into a Git repo to enforce legal (e.g. DCO) and governance (e.g. 2+2 sign-offs) rules so that we can have air-tight compliance.

The proposal generated a lot of attention and support and the effort has moved to github repos and a mailing list to keep the momentum. Since this doesn't fit neatly under the HL banner--is more systemic in nature--I haven't tried to set up a lab or anything, but I do want you to all be aware of it. All are welcome and I invite you to take a look and help. Currently the spec writing repo is here: https://github.com/dhuseby/did-git-specand the mailing list is here: https://groups.io/g/did-git/topics

I am planning on presenting this work at the next appropriate HL get-together and talk about how the HL community can use this to meet DCO and other governance requirements better.

Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...




Gid DID spec work

Dave Huseby <dhuseby@...>
 

Hi TSC,

I attended the Internet Identity Workshop last week and decided to organize sessions on a solution to the DCO problem that I've been chewing on for more than a year now. I proposed sessions to work out a Git DID method spec and all of the details around it. For those of you not familiar with what I'm talking about, you've got a lot of reading :) DID primer DID spec DID method registry Understanding DIDs

The short cut explanation is that this is an effort to teach Git how to understand digital signatures on commits made by self-sovereign identities and how to store those identities in the repo itself. Another aspect of this is how to encode governance rules (think: transaction validation/"smart contracts") into a Git repo to enforce legal (e.g. DCO) and governance (e.g. 2+2 sign-offs) rules so that we can have air-tight compliance.

The proposal generated a lot of attention and support and the effort has moved to github repos and a mailing list to keep the momentum. Since this doesn't fit neatly under the HL banner--is more systemic in nature--I haven't tried to set up a lab or anything, but I do want you to all be aware of it. All are welcome and I invite you to take a look and help. Currently the spec writing repo is here: https://github.com/dhuseby/did-git-spec and the mailing list is here: https://groups.io/g/did-git/topics

I am planning on presenting this work at the next appropriate HL get-together and talk about how the HL community can use this to meet DCO and other governance requirements better.

Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...


Re: [Hyperledger Fabric] RocketChat Downtime

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

Hi,

That’s still a heavy traffic time. Can we have the outage at a lower traffic time. I would guess after 17:00 PST would be quieter.


Thanks,

Dan

 

From: <tsc@...> on behalf of Ry Jones <rjones@...>
Date: Friday, May 3, 2019 at 5:35 AM
To: Hyperledger List <tsc@...>
Cc: Anton Baranov <abaranov@...>, Tim Johnson <tijohnson@...>, "community-architects@..." <community-architects@...>
Subject: Re: [Hyperledger TSC] [Hyperledger Fabric] RocketChat Downtime

 

-Fabric list

+TSC

 

 

On Fri, May 3, 2019 at 12:21 AM Tim Johnson <tijohnson@...> wrote:

We were unable to perform the update that was scheduled earlier.

If there are no objections we will be upgrading RocketChat Friday May 3
@ 16:00 EST. It is expected to be back on-line within 30mins.

Tim


 

--

Ry Jones

Community Architect, Hyperledger


Re: [Hyperledger Fabric] RocketChat Downtime

Ry Jones
 

-Fabric list
+TSC


On Fri, May 3, 2019 at 12:21 AM Tim Johnson <tijohnson@...> wrote:
We were unable to perform the update that was scheduled earlier.

If there are no objections we will be upgrading RocketChat Friday May 3
@ 16:00 EST. It is expected to be back on-line within 30mins.

Tim


--
Ry Jones
Community Architect, Hyperledger


Re: Vote on Transact Proposal

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

As announced during today’s TSC meeting this vote has closed and Hyperledger Transact is approved.

The vote was 10 in favor, 0 opposed, and 1 abstention or absence.

 

Regards,

Dan Middleton

TSC Chair

 

From: <tsc@...> on behalf of "Silas Davis via Lists.Hyperledger.Org" <silas=monax.io@...>
Reply-To: "silas@..." <silas@...>
Date: Thursday, May 2, 2019 at 5:23 AM
To: Arnaud Le Hors <lehors@...>
Cc: "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] Vote on Transact Proposal

 

+1

 

On Tue, 30 Apr 2019 at 07:41, Arnaud Le Hors <lehors@...> wrote:

I'm rather confused about how the vote is conducted but will go along with the crowd and cast my vote here: +1
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Nathan George" <nathan.george@...>
To:        "Middleton, Dan" <dan.middleton@...>
Cc:        "tsc@..." <tsc@...>
Date:        04/30/2019 02:15 AM
Subject:        Re: [Hyperledger TSC] Vote on Transact Proposal
Sent by:        tsc@...





+1

On Fri, Apr 26, 2019 at 8:49 AM Middleton, Dan <dan.middleton@...> wrote:
Good discussion on the Transact proposal yesterday. A clear theme was the cross project-interest in and support of the proposal.

https://lists.hyperledger.org/g/tsc/message/2161

 

TSC Members, please reply to this thread with your vote by May 1, 2019.

 

+1 In favor

0 Abstaining

-1 Against

 

My vote is +1 in favor of the proposal.

 

Regards,

Dan Middleton

TSC Chair




Projects and Subprojects

Hart Montgomery
 

Hi Everyone,

 

In light of today’s discussion at the TSC meeting, I wanted to write up some of my thoughts on the project approval process.  I apologize in advance for the wall of text, but I wanted to summarize a lot of things.  I’ll start with a bit of history (we have been around long enough for that to matter!) and then explain what I think we should do.

 

At some point two or (more like) three years ago, we had a number of discussions about new projects in Hyperledger.  We were beginning to get quite a lot of interest from people who wanted to have their own project.  At the time, the popular opinion was that we should be very inclusive as to what qualified for a project approval, and even things like SDKs for DLT platforms (i.e. a single language SDK for a single DLT platform) deserved their own projects.  For instance, here (https://lists.hyperledger.org/g/tsc/message/668?p=,,,20,0,0,0::relevance,,Fabric-Go-SDK,20,2,0,17551967) and here (https://lists.hyperledger.org/g/tsc/message/668?p=,,,20,0,0,0::relevance,,Fabric-Go-SDK,20,2,0,17551967 ) are archived emails from Brian explaining his thoughts on this.  I believe this was the most popular (or at least the most commonly expressed) opinion at the time.

 

However, there was some worry about too much project proliferation (which seems to be one of the main concerns today).  I recall proposing that we have a tiered project structure, with projects and sub-projects.  The goal of this was to allow for subproject independence (and to give subprojects all the independent tools they needed) without putting a huge burden on the TSC through too many projects.  I don’t know that I was the originator of this idea, but here is an email from me to TSC list at the time:  https://lists.hyperledger.org/g/tsc/message/681?p=,,,20,0,0,0::relevance,,RFC+1149,20,2,0,17551967.  This idea got shot down, though—people thought it was best to have a flat project hierarchy, in an approach more like Apache.

 

Of course, we all know what happened.  We approved a bunch of projects that really didn’t become independent at all.  Chris brought up Composer today in the TSC meeting as an example, but perhaps an even more illustrative example is the Fabric Java SDK.  From a purely rules-based perspective, this is still officially a top-level Hyperledger project!  You can see this email where we approved it:  https://lists.hyperledger.org/g/tsc/message/321?p=,,,20,0,0,0::relevance,,Fabric-Java-SDK,20,2,0,17551816.  It doesn’t function as a top-level project at all:  we have neglected to require updates from it at TSC meetings (or any of the other “new” requirements we have made of projects), and the governance, as far as I can tell, is done completely within Fabric.  But we also haven’t done anything official to take away its status as a fully independent, top-level Hyperledger project, so it is sitting in some kind of mixed state where it is officially an independent project but not one in practice at all.

 

And now we have come full circle.  Yet again, we are in a period where people have proposed a lot of new projects (which is definitely a good thing!) and others are worried about project proliferation.  Yet again, I’d like to bring up the topic of project tiers and sub-projects.  I am curious if opinions have changed over the past two or three years as Hyperledger has matured.

 

I would like to get people’s feedback on the following idea:  in the future, in addition to project proposals, we allow for sub-project proposals (and thus, sub-projects).  If you don’t like my naming conventions (looking at you Silona) please feel free to suggest something else.  We define a sub-project to be a project that is exclusively dependent on or forked from a single (higher-level) project. Sub-projects have all of the tools available to them that regular projects do, but could potentially have slightly different governance:  they could do some reporting to the higher-level project, rather than directly to the TSC (although the TSC can step in to manage disputes as necessary), which would decrease the burden on the TSC.  If a sub-project matures to the point where it works with/supports/is used for multiple higher tier projects, then it should be promoted to full project without extensive discussion.  We can also allow the TSC to (with fair warning) demote projects that only support one higher-tier project into sub-projects.

 

The upside of this is that Hyperledger could support more projects this way (even the Fabric-Java-SDK, for instance, could be a sub-project), giving people perhaps more incentive to take ownership and try building new things.  Outsiders could very clearly see the project structure and how things work as well, and we could market sub-projects effectively too if this was desired or needed.  The downside of the hierarchical project structure is that it may decrease cross-project interaction as people might see sub-projects as part of a different project and not something to interoperate with (this was my interpretation of the core of Brian’s argument two and a half years ago).  Over time, I think we have learned that cross-project interaction doesn’t really seem to happen organically or spontaneously—it takes a lot of effort and, at least for Hyperledger, seems to take some central planning by project maintainers.  So I’m not sure this argument turned out to be correct.  

 

What do people think about this?  Is this reasonable?  Should we just continue with the flat project hierarchy?  Is there some other way to gracefully handle project proliferation?  I am curious to hear what people think about this.  I’m substantially less experienced in open source projects than many of the other people here, some of whom have been working on open source for longer than I have been alive, so it’s entirely possible that I am just completely missing the boat, and I welcome critical feedback.

 

If you’ve made it this far, thank you for reading, and sorry again for the wall of text. 

 

Thanks,

Hart

 

 


Re: Vote on Transact Proposal

Silas Davis
 

+1

On Tue, 30 Apr 2019 at 07:41, Arnaud Le Hors <lehors@...> wrote:
I'm rather confused about how the vote is conducted but will go along with the crowd and cast my vote here: +1
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Nathan George" <nathan.george@...>
To:        "Middleton, Dan" <dan.middleton@...>
Cc:        "tsc@..." <tsc@...>
Date:        04/30/2019 02:15 AM
Subject:        Re: [Hyperledger TSC] Vote on Transact Proposal
Sent by:        tsc@...




+1

On Fri, Apr 26, 2019 at 8:49 AM Middleton, Dan <dan.middleton@...> wrote:
Good discussion on the Transact proposal yesterday. A clear theme was the cross project-interest in and support of the proposal.

https://lists.hyperledger.org/g/tsc/message/2161

 

TSC Members, please reply to this thread with your vote by May 1, 2019.

 

+1 In favor

0 Abstaining

-1 Against

 

My vote is +1 in favor of the proposal.

 

Regards,

Dan Middleton

TSC Chair





Q2 Hyperledger Grid Update

Dave Cecchi
 

The Q2 Hyperledger Grid Update has been posted:

 

  https://wiki.hyperledger.org/display/HYP/2019+Q2+Hyperledger+Grid

 

Thank you,

 

-dc

 


Re: Vote on Transact Proposal

Arnaud Le Hors
 

I'm rather confused about how the vote is conducted but will go along with the crowd and cast my vote here: +1
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Nathan George" <nathan.george@...>
To:        "Middleton, Dan" <dan.middleton@...>
Cc:        "tsc@..." <tsc@...>
Date:        04/30/2019 02:15 AM
Subject:        Re: [Hyperledger TSC] Vote on Transact Proposal
Sent by:        tsc@...




+1


On Fri, Apr 26, 2019 at 8:49 AM Middleton, Dan <dan.middleton@...> wrote:
Good discussion on the Transact proposal yesterday. A clear theme was the cross project-interest in and support of the proposal.

https://lists.hyperledger.org/g/tsc/message/2161

 

TSC Members, please reply to this thread with your vote by May 1, 2019.

 

+1 In favor

0 Abstaining

-1 Against

 

My vote is +1 in favor of the proposal.

 

Regards,

Dan Middleton

TSC Chair





Re: Vote on Transact Proposal

Nathan George <nathan.george@...>
 

+1

On Fri, Apr 26, 2019 at 8:49 AM Middleton, Dan <dan.middleton@...> wrote:

Good discussion on the Transact proposal yesterday. A clear theme was the cross project-interest in and support of the proposal.

https://lists.hyperledger.org/g/tsc/message/2161

 

TSC Members, please reply to this thread with your vote by May 1, 2019.

 

+1 In favor

0 Abstaining

-1 Against

 

My vote is +1 in favor of the proposal.

 

Regards,

Dan Middleton

TSC Chair


Re: Vote on Transact Proposal

Baohua Yang
 

+1!

On Tue, Apr 30, 2019 at 3:34 AM Christopher Ferris <chrisfer@...> wrote:
+1
 
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: "Olson, Kelly M" <kelly.m.olson@...>
Sent by: tsc@...
To: "Ovidiu V. Drugan" <ovidiu.drugan@...>, "tsc@..." <tsc@...>
Cc:
Subject: Re: [Hyperledger TSC] Vote on Transact Proposal
Date: Mon, Apr 29, 2019 2:14 PM
 

+1

 

From: tsc@... [mailto:tsc@...] On Behalf Of Ovidiu V. Drugan
Sent: Friday, April 26, 2019 10:43 AM
To: tsc@...
Subject: Re: [Hyperledger TSC] Vote on Transact Proposal

 

+1

Ovidiu Valentin DRUGAN, PhD

Teknisk fagansvarlig

+47 950 67 884, ovidiu.drugan@...

Eika Gruppen, Parkveien 61, 0254 Oslo


On 26 Apr 2019, at 16:49, Middleton, Dan <dan.middleton@...> wrote:

Good discussion on the Transact proposal yesterday. A clear theme was the cross project-interest in and support of the proposal.

https://lists.hyperledger.org/g/tsc/message/2161

 

TSC Members, please reply to this thread with your vote by May 1, 2019.

 

+1 In favor

0 Abstaining

-1 Against

 

My vote is +1 in favor of the proposal.

 

Regards,

Dan Middleton

TSC Chair

 

 



--
Best wishes!

Baohua Yang


Hyperledger Grid Quarterly Update Due #tsc-project-update - Thu, 05/02/2019 #tsc-project-update #cal-reminder

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

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

When:
Thursday, 2 May 2019

Organizer:
community-architects@...

Description:
The Hyperledger Grid project update to the TSC was due April 29, 2019, and it will be presented to the TSC on May 2, 2019. Please review prior to the meeting and bring your questions.

View Event


Re: Vote on Transact Proposal

Christopher Ferris <chrisfer@...>
 

+1
 
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: "Olson, Kelly M" <kelly.m.olson@...>
Sent by: tsc@...
To: "Ovidiu V. Drugan" <ovidiu.drugan@...>, "tsc@..." <tsc@...>
Cc:
Subject: Re: [Hyperledger TSC] Vote on Transact Proposal
Date: Mon, Apr 29, 2019 2:14 PM
 

+1

 

From: tsc@... [mailto:tsc@...] On Behalf Of Ovidiu V. Drugan
Sent: Friday, April 26, 2019 10:43 AM
To: tsc@...
Subject: Re: [Hyperledger TSC] Vote on Transact Proposal

 

+1

Ovidiu Valentin DRUGAN, PhD

Teknisk fagansvarlig

+47 950 67 884, ovidiu.drugan@...

Eika Gruppen, Parkveien 61, 0254 Oslo


On 26 Apr 2019, at 16:49, Middleton, Dan <dan.middleton@...> wrote:

Good discussion on the Transact proposal yesterday. A clear theme was the cross project-interest in and support of the proposal.

https://lists.hyperledger.org/g/tsc/message/2161

 

TSC Members, please reply to this thread with your vote by May 1, 2019.

 

+1 In favor

0 Abstaining

-1 Against

 

My vote is +1 in favor of the proposal.

 

Regards,

Dan Middleton

TSC Chair

 

 

1661 - 1680 of 3871