|
Re: Projects and Subprojects
I want to respond to one point specifically: On Fri, May 24, 2019 at 9:14 AM Shawn Amundson <amundson@...> wrote:
While this may not be a formal requirement, that is in fact what we're doing. I had a phone call yesterday with a company that is very eager to contribute some tools to manage Fabric. I proposed a set of steps:
Ry
|
||||||||
|
|
||||||||
|
Re: Projects and Subprojects
Shawn Amundson
Chris is right that the more mature large projects already kind of have sub-projects. In Sawtooth, we are usually careful to call them components to avoid confusion. But basically, each repo within Sawtooth (and there are a lot) have an independent maintainers list and most of those repos are distinct components (some are example apps). While there is a lot of overlap in maintainers, they do differ between component. There are specific people within the project coordinating for release purposes. An RFC process is used to propose/approve/discuss new components on various metrics: is it aligned with the project's long-term vision, will it be maintainable as part of the project long-term, is it interesting enough, would it be better if it were in labs or a separate project, etc. All the components are expected to behave in a uniform way (such as the PR process, build processes, etc.) so it's easy (for maintainers) to go between working on component A and component B. They are also expected to make up the overall vision of the project. All of these expectations mean they aren't really a separate project. And, they are normally proposed by existing maintainers (though this need not be the case, it can help w/long-term support). Deciding on whether to adopt a component can be very difficult as it has the potential to shift the core values of the project. For example, in Sawtooth we adopted both Raft and PBFT as components. Adopting Raft presented somewhat of a crisis in identity of the project, because part of Sawtooth's identity is a ledger that is truly distributed including solving BFT. Obviously, Raft fails that test. PBFT on the other hand, was easy, because it fit in with the vision. There are a lot of dimensions though - Raft we had a nice pre-existing Rust library, and PBFT we had to put in more coding effort. In the end, we accepted both Raft and PBFT primarily because it was consistent with another aspect of Sawtooth's identity which is modularity. I couldn't imagine delegating these decisions to the TSC because for any given project, a good portion of the TSC members are not deeply involved with that project day-to-day -- much better to let the project maintainers do it. (Would we have put a ton of effort into Sawtooth's iOS SDK if there was the possibility that the TSC would decide that Sawtooth shouldn't have an iOS component? Should Fabric folks be forced to accept new UI components that don't fit with the vision of the next major release? etc. etc.) So, I guess I'm against sub-projects in any sort of formalization sense. Seems completely unnecessary and potentially actively harmful. However. I do believe that more projects is better. But specifically, more projects geared toward reusable components like libraries. Because the those are the projects that will encourage cross-project code re-use and help unify Hyperledger as we move forward. I think the effort should be put into the taxonomy and classification of projects and to what extent HL focuses and markets them. Things like Ursa and Transact obviously need far less marketing than the "framework" projects. Another thought would be to strengthen labs. Remove any reason not to use labs. And maybe even require new projects exist in labs for a short time before becoming a project. -Shawn
On Thu, May 23, 2019 at 4:58 AM Christopher Ferris <chrisfer@...> wrote:
|
||||||||
|
|
||||||||
|
Re: Friday fun: Rusty python
Python is a very vigorous, and it is still evolving!
On Fri, May 24, 2019 at 11:28 PM Middleton, Dan <dan.middleton@...> wrote:
--
Best wishes! Baohua Yang
|
||||||||
|
|
||||||||
|
Friday fun: Rusty python
Middleton, Dan <dan.middleton@...>
I came across python like this in Indy:
def verify_multi_sig(self, signature: str, message: bytes, pks: Sequence[str]) -> bool:
[Link]
Are those types in the function parameters and a return type? In Python?? Yes! Technically old news (came out in python 3.5) but still pretty uncommon to see.
When you combined it with https://www.python.org/dev/peps/pep-0554/ which seeks to enhance concurrency, python starts looking just a little bit rusty. (Put down the flame throwers. I said, “a little bit.”)
Indy and Sawtooth are both doing a lot of python -> rust porting. Now some stronger weak typing and hope of a future concurrency model aren’t going to affect those plans, but still cool to see python’s constant evolution. Read more on python threading here.
You can hear from the former BDFL of Python in this October interview. He doesn’t get into any of these peps, but it’s interesting to hear him talk about governance. At the time code I link to he also talks about diversity and inclusion. https://youtu.be/qxMcGDnT8uc?t=1382
Happy Friday, Dan Middleton Intel Principal Engineer
|
||||||||
|
|
||||||||
|
Re: Gid DID spec work
Dave Huseby <dhuseby@...>
I forgot to add that I've been slowly writing a new signing tool called BetterSign that uses DIDDir keyrings for the identity information. It will be the first signing tool that Git will use to handle signing commits/tags. Nothing there at the moment, I'm about to upload my prototype: It is written in Rust and uses the diddir crate prototype I wrote: Dave
On Thu, May 23, 2019 at 12:34 PM Arnaud Le Hors <lehors@...> wrote: You're right, I was confused. Now, I understand. That's pretty cool!
|
||||||||
|
|
||||||||
|
Re: Gid DID spec work
Arnaud Le Hors
You're right, I was confused. Now, I understand.
That's pretty cool!
toggle quoted messageShow quoted text
Thanks. :-) -- Arnaud Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM From: David Huseby <dhuseby@...> To: Arnaud Le Hors <lehors@...> Cc: Hyperledger List <tsc@...> Date: 05/23/2019 07:28 PM Subject: [EXTERNAL] Re: [Hyperledger TSC] Gid DID spec work Hi Arnaud, Thanks for poking me this morning. I think you're confused about this. This isn't *Github* this is just Git. There is a Github DID method spec and also a Facebook one that I think suffers from the problem you point out. What HL is interested in is just the Git tool itself and is more about how to store identities with the code so that repos are self-verifying and have air-tight provenance. The effort is trying to accomplish the following: 1) Modify the core Git tool to have an abstracted commit/tag signing system that is not hard coded to GPG and is able to support multiple signing tools. This work could also include teaching Git how to understand and utilize multiple signatures on commits/tags but that's a stretch goal. I have a set of patches that I wrote last year that the intern for the Git DID signing project (https://wiki.hyperledger.org/display/INTERN/Git+signing+with+DIDs) will own, rebase, and oversee getting landed in the Git project. 2) Add a core Git porcelain command called "git did" that takes DID method strings (e.g. "git:did:<repo>:<identity>") and handles the CRUD operations specified in the DID method spec (https://github.com/dhuseby/did-git-spec/blob/master/did-git-spec.md). 3) Standardize how DID documents are stored in a Git repo. What we're really doing is defining a new keyring standard where the identities and key material are stored as DID documents in the filesystem (see DIDDir: https://github.com/dhuseby/did-git-spec/blob/master/did-dir-spec.md). The current proposal is that the keyring is just a Git repository and the files will organized and manipulated in standard ways--think: Maildir except with versioning handled by Git, using the 'git did' porcelain command. By defining the keyring as a repo means that it can be a stand-alone repo in a user's home directory storing private/personal identity information just like a GPG keyring, or it can be part of a repo that contains other data such as code for an open source project. 4) Standardize how governance documents (e.g. license, code of conduct, DCO, governance rules like 2+2 reviews) are stored as well as defining the rules for how maintainers and contributors manage the identities stored in the repo. As an example rule, new contributors will first have to "join" a project by sending a patch/PR that adds their public DID document--storing at least their public key and author string--to the repo along with a digital signature over the governing documents as acceptance of the license, CoC, DCO, etc. By combining that rule with one that requires all commits to be signed by an identity *already* stored in the repo, we can ensure that all commits are signed and contributed under the terms of the governing documents. We are having a meeting tomorrow to discuss the current state of the project at 11am pacific time on the hyperledger.community.backup zoom. I hope this fully addresses your question/concern. Cheers! Dave P.S. Just to head off the question "what happens to old repos that have long histories that weren't governed by this new system?" The answer is, the repos can be "blessed" at any point in their history to adopt this system. When the repo is blessed, all DCO and license issues must be resolved. It's the same as when one of our projects has to clean up all of their DCO issues. For projects that have already cleaned up their DCO issues and have maintained clean DCO histories since, then blessing the repo to use this new governance model is the same as if the repo was brand new. P.S.S. Once nice side effect of this is being able to make ZKPs that prove things based on identities and contribution history stored in repos. As long as the repos are publicly available, anybody would be able to cryptographically prove that they are a contributor to an HL project and therefore eligible to vote in the TSC election. How 'bout that? --- David Huseby Security Maven, Hyperledger The Linux Foundation +1-206-234-2392 dhuseby@...
On Mon, May 6, 2019 at 2:16 AM Arnaud Le Hors <lehors@...>
wrote:
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@...
|
||||||||
|
|
||||||||
|
Re: Gid DID spec work
Dave Huseby <dhuseby@...>
Hi Arnaud, Thanks for poking me this morning. I think you're confused about this. This isn't *Github* this is just Git. There is a Github DID method spec and also a Facebook one that I think suffers from the problem you point out. What HL is interested in is just the Git tool itself and is more about how to store identities with the code so that repos are self-verifying and have air-tight provenance. The effort is trying to accomplish the following: 1) Modify the core Git tool to have an abstracted commit/tag signing system that is not hard coded to GPG and is able to support multiple signing tools. This work could also include teaching Git how to understand and utilize multiple signatures on commits/tags but that's a stretch goal. I have a set of patches that I wrote last year that the intern for the Git DID signing project (https://wiki.hyperledger.org/display/INTERN/Git+signing+with+DIDs) will own, rebase, and oversee getting landed in the Git project. 2) Add a core Git porcelain command called "git did" that takes DID method strings (e.g. "git:did:<repo>:<identity>") and handles the CRUD operations specified in the DID method spec (https://github.com/dhuseby/did-git-spec/blob/master/did-git-spec.md). 3) Standardize how DID documents are stored in a Git repo. What we're really doing is defining a new keyring standard where the identities and key material are stored as DID documents in the filesystem (see DIDDir: https://github.com/dhuseby/did-git-spec/blob/master/did-dir-spec.md). The current proposal is that the keyring is just a Git repository and the files will organized and manipulated in standard ways--think: Maildir except with versioning handled by Git, using the 'git did' porcelain command. By defining the keyring as a repo means that it can be a stand-alone repo in a user's home directory storing private/personal identity information just like a GPG keyring, or it can be part of a repo that contains other data such as code for an open source project. 4) Standardize how governance documents (e.g. license, code of conduct, DCO, governance rules like 2+2 reviews) are stored as well as defining the rules for how maintainers and contributors manage the identities stored in the repo. As an example rule, new contributors will first have to "join" a project by sending a patch/PR that adds their public DID document--storing at least their public key and author string--to the repo along with a digital signature over the governing documents as acceptance of the license, CoC, DCO, etc. By combining that rule with one that requires all commits to be signed by an identity *already* stored in the repo, we can ensure that all commits are signed and contributed under the terms of the governing documents. We are having a meeting tomorrow to discuss the current state of the project at 11am pacific time on the hyperledger.community.backup zoom. I hope this fully addresses your question/concern. Cheers! Dave P.S. Just to head off the question "what happens to old repos that have long histories that weren't governed by this new system?" The answer is, the repos can be "blessed" at any point in their history to adopt this system. When the repo is blessed, all DCO and license issues must be resolved. It's the same as when one of our projects has to clean up all of their DCO issues. For projects that have already cleaned up their DCO issues and have maintained clean DCO histories since, then blessing the repo to use this new governance model is the same as if the repo was brand new. P.S.S. Once nice side effect of this is being able to make ZKPs that prove things based on identities and contribution history stored in repos. As long as the repos are publicly available, anybody would be able to cryptographically prove that they are a contributor to an HL project and therefore eligible to vote in the TSC election. How 'bout that?
On Mon, May 6, 2019 at 2:16 AM Arnaud Le Hors <lehors@...> wrote: Interesting idea but isn't depending on a fully centralized system owned by a corporation defeating the whole point of DIDs?
|
||||||||
|
|
||||||||
|
Brasil Bootcamp - Details and Ask
Karen Ottoni
Hi Everyone, My apologies I had sound issues on the call earlier today. To recap what Daniela said, we're organizing the next bootcamp to take place in São Paulo, Brazil on June 24-25th. We are currently bringing together a core set of session leaders to ensure we'll have enough base content for the bootcamp before we announce it publicly for session proposals and registration late next week. What we'd love from this community:
If you have any ideas or suggestions for the above please reach out to me, kottoni@... and Silona, sbonewald@.... Please also check out our Wiki to stay abreast of activities and how the agenda is being developed. Thank you, Karen Karen L. Ottoni hosted by The Linux Foundation Mobile: +1 919 699 8905 Website: http://hyperledger.org
|
||||||||
|
|
||||||||
|
Identity WG
Vipin Bharathan
Hello all, As we have had some cancellations of calls we have not had the opportunity to report on the Identity Working Group paper. We also have a backlog of presentations (see below). This is a rough road map for efforts for the short term. Please remember we will have a call on May 29th.
There has been some progress on the paper which I report below.
Additional work projected to be done by May 29 (which is the date for our next call) Fabric writeup MiFID review DiD writeup Calling for contributions from Burrow, Quilt and others, also reviews before we integrate the paper into github for more control (maybe in about a month) Please comment or respond to this email. Best, Vipin
|
||||||||
|
|
||||||||
|
Re: Projects and Subprojects
Christopher Ferris <chrisfer@...>
This is a good discussion, and I am sorry I will miss the call.
I think that sub-projects is an interesting thought, but we kind of have that now, do we not?
I agree that there isn't necessarily consistency, but that is due to the fact that we allowed projects
to expand their repo footprint to support not only new features but refactoring, etc.
I do agree that it would be useful to have a more formal relationship between (sub)projects such as SDKs and the related top-level project(s) such that there can be a more formal path to integration into the formal release process. Of course, as each top-level project has its own governance, it is less clear how this would play out.
Frankly, I think that before we add in any additional top level framework projects, we should have a good long think about the implications.
As to Hart's last point, I think that the TSC and community architects should invest more time and energy in working on how we can encourage more organic cross-project interaction/integration/etc and that discussion should include the maintainers/leads of the various top level projects as they are most certainly invested in any outcome and have important insights that we should take under advisement.
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: Projects and Subprojects
Silas Davis
Thanks for putting this together Hart, the history is useful. Sorry for taking nearly 3 weeks to respond to it. It seems like there are a few different resources that people are concerned with when thinking about projects, some of which are necessarily scarce and some of which are artificially scarce: - TSC time - Developer time - Community support - Political will - Brand value/Attention - Consumables (hosting, CI/CD, stickers, etc) To scale the number of projects we need away to allocate these resources fairly and to maximise the resources a project brings with it (in terms of developer and community effort). Looking at Brian's and other's previous statements it seems the desire for a flat project structure is motivated by giving all projects formal structures in terms of wiki, roadmap, maintainers and also opening the possibility of cross-project work. In practice it seems for the latter often amounts to wishful thinking in the absence of clear plans and motivation to do so. It seems to me (though I haven't been around here long) that often new projects tend to have their origins/support from people in an existing top-level project (I think this has to do with the political will resource...) in which case it might be natural for a new project to 'report to' or be associated with an established project for the purposes of quarterly reviews and elements of governance and perhaps sharing resources (consumables and developer time. This would have the effect of scaling the amount of projects we could support and would give some kind of responsibility to the 'mentoring' projects. The project/sub-project relationship seems to equate technical subsumption/sub-ordinance with an organisational subdivision. Could these concerns be meaningfully separated? Though it occurs to me as I write this that I might just be describing incubation with a twist... Also if a project is completely technically independent it might not make sense to shoe-horn TSC updates and testing under the same umbrella. Where there is significant overlap however, as with Transact and Sawtooth (at the time of writing), from a practical point of view it would probably work well, it''s just that that project has scope that is different to, and goes beyond Sawtooth in general. I think the other issue particularly for incumbent projects is what proliferation of top level projects does for the Hyperledger brand and the distribution of attention across projects. If there are projects that are less mature or lower quality at the top level what effect does that have on the perceived value of existing projects? What effect does that have on levels of contribution or use of projects in the wild? Another issue I think I raised on a TSC call is we don't really have a way to prune top level projects, which would be another way to address proliferation. Currently it would seem rather mean and drastic to strip a project of top-level status, perhaps we could address that and encourage more top-level project 'startups' - maybe they return to incubation or get decommissioned after a certain period of time. Maybe that kind of churn would degrade trust in Hyperledger. I have managed to write quite a few paragraphs there without providing any answers. So: - I broadly think sub-projects are a good idea (whether by that name or not) - If organising cacucusses of projects in a hierarchy for the purposes of reporting and governance (i.e. projects give TSC update together, projects share CI resources) makes sense in practice I would support it Perhaps we don't have a problem acute enough to be worth solving today. But I'd be interested in people's thoughts on the negative effects of project proliferation in terms of the types of resources listed above. Silas
|
||||||||
|
|
||||||||
|
Perf and Scale Q2 update
mark wagner <mwagner@...>
Sorry for the delay. The update is here : Some stuff we should probably have a discussion on at a TSC call in a week or two. -mark -- Mark Wagner Senior Principal Software Engineer
|
||||||||
|
|
||||||||
|
Re: Updated agenda for TSC call May 23, 2019
Christopher Ferris <chris.ferris@...>
Regrets, again. (sorry) Need to cover for someone at Congressional Blockchain Caucus Smart Contracts forum tomorrow.
toggle quoted messageShow quoted text
Chris
On May 22, 2019, at 3:05 PM, Middleton, Dan <dan.middleton@...> wrote:
|
||||||||
|
|
||||||||
|
Re: Updated agenda for TSC call May 23, 2019
Middleton, Dan <dan.middleton@...>
Thanks for putting this up, Dave.
How much time do you need for the DID topic?
Thanks, Dan
From: <tsc@...> on behalf of Dave Huseby <dhuseby@...>
Hi TSC,
The agenda for the TSC meeting this Thursday has been updated. Check it out here:
We've got lots of reports coming in and some excited updates on a potential DCO solution as well as community health and dev certs.
Cheers! Dave
---
|
||||||||
|
|
||||||||
|
Updated agenda for TSC call May 23, 2019
Dave Huseby <dhuseby@...>
Hi TSC, The agenda for the TSC meeting this Thursday has been updated. Check it out here: We've got lots of reports coming in and some excited updates on a potential DCO solution as well as community health and dev certs. Cheers! Dave
|
||||||||
|
|
||||||||
|
Upcoming Event: Hyperledger Technical WG China Quarterly Update Due #tsc-wg-update - Thu, 05/23/2019
#tsc-wg-update
#cal-reminder
tsc@lists.hyperledger.org Calendar <tsc@...>
Reminder: Hyperledger Technical WG China Quarterly Update Due #tsc-wg-update When: Thursday, 23 May 2019 Organizer: community-architects@... Description: The Hyperledger Technical WG China update to the TSC was due 20 May, 2019, and it will be presented to the TSC on 23 May, 2019. Please review prior to the meeting and bring your questions.
|
||||||||
|
|
||||||||
|
Upcoming Event: Hyperledger Explorer Quarterly Update Due #tsc-project-update - Thu, 05/23/2019
#tsc-project-update
#cal-reminder
tsc@lists.hyperledger.org Calendar <tsc@...>
Reminder: Hyperledger Explorer Quarterly Update Due #tsc-project-update When: Thursday, 23 May 2019 Organizer: community-architects@... Description: The Hyperledger Explorer update to the TSC was due May 20, 2019, and it will be presented to the TSC on May 23, 2019. Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.
|
||||||||
|
|
||||||||
|
Re: Hyperledger RocketChat is down
Tim Johnson <tijohnson@...>
Ricket Chat is back on-line.
toggle quoted messageShow quoted text
On 5/20/19 8:53 AM, Tim Johnson via Lists.Hyperledger.Org wrote:
We are aware of the outage and are working on getting it back on-line.
|
||||||||
|
|
||||||||
|
Hyperledger RocketChat is down
Tim Johnson <tijohnson@...>
We are aware of the outage and are working on getting it back on-line.
Tim
|
||||||||
|
|
||||||||
|
Gerrit Server Downtime
Tim Johnson <tijohnson@...>
The gerrit upgrade was completed last night. You should now be seeing the new WEB page when you access gerrit. Tim -------- Forwarded Message --------
What: Upgrade to Version 2.16.8 When: Sun May 19 23:00 Duration: 1hr We have already performed this upgrade at several other customers and so we expect the minimal problems with this upgrade. You will notice the biggest change, which is a revamped GUI. I will be sending out another reminder of this downtime on Sunday Tim
|
||||||||
|
|