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
|
|
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.
Dan
From: <tsc@...> on behalf of Ry Jones <rjones@...>
-Fabric list +TSC
On Fri, May 3, 2019 at 12:21 AM Tim Johnson <tijohnson@...> wrote:
--
|
|
Re: [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.
|
|
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@...>
+1
On Tue, 30 Apr 2019 at 07:41, Arnaud Le Hors <lehors@...> wrote:
|
|
Projects and Subprojects
hmontgomery@us.fujitsu.com <hmontgomery@...>
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
|
|
Q2 Hyperledger Grid Update
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
toggle quoted messageShow quoted text
-- 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:
|
|
Re: Vote on Transact Proposal
+1!
On Tue, Apr 30, 2019 at 3:34 AM Christopher Ferris <chrisfer@...> wrote:
--
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: When: Organizer: Description:
|
|
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 -----
|
|
Re: Vote on Transact Proposal
Olson, Kelly M <kelly.m.olson@...>
+1
From: tsc@... [mailto:tsc@...]
On Behalf Of Ovidiu V. Drugan
+1 Ovidiu Valentin DRUGAN, PhD Teknisk fagansvarlig +47 950 67 884, ovidiu.drugan@... Eika Gruppen, Parkveien 61, 0254 Oslo
|
|
Re: Vote on Transact Proposal
Silona Bonewald <sbonewald@...>
Do you mean this? that has a link above the button to submit the form to this? It would be nice if people copied the old ones out of google docs but don't think they need to use the form. Just Import into a new page would work.
On Fri, Apr 26, 2019 at 11:20 AM Shawn Amundson <amundson@...> wrote:
--
|
|
Re: Vote on Transact Proposal
mark wagner <mwagner@...>
+1 -mr wagner
On Fri, Apr 26, 2019 at 5:55 PM Mic Bowman <cmickeyb@...> wrote:
-- Mark Wagner Senior Principal Software Engineer
|
|
Re: Vote on Transact Proposal
+1
On Fri, Apr 26, 2019 at 7:49 AM Middleton, Dan <dan.middleton@...> wrote:
|
|
Re: [Hyperledger Fabric] RocketChat Downtime
On Fri, Apr 26, 2019 at 10:46 AM Tim Johnson <tijohnson@...> wrote: We will be upgrading RockChat, Tue Apr 30th at 5PM EST. It should be
|
|
Re: Vote on Transact Proposal
Ovidiu V. Drugan
+1
toggle quoted messageShow quoted text
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:
|
|
Re: Vote on Transact Proposal
hmontgomery@us.fujitsu.com <hmontgomery@...>
+1 from me.
Thanks everyone! Looking forward to more interoperability.
Hart
From: tsc@... [mailto:tsc@...]
On Behalf Of Middleton, Dan
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
|
|