not sure whether this is more focused on “deploy / orchestration” side, or “contract / chaincode side” side, put this tradeoff / focus aside,  js / electron is good

在 2018年11月9日，下午3:51，Yi DENG <michaelyideng@...> 写道：

Dear TSC and all, 

It is Yi. Recently, we developed a desktop app for Fabric. It is general-purpose, in other words, an API tool with GUI. We would like to contribute it to Hyperledger. Looking forward to discussion at TSC meeting. I can make a 5-minutes demonstration about what it is and how to use it.

 

Proposal:

https://docs.google.com/document/d/1XX-I1uud0DV2TVRj6H5w8r5OaX0W0VCZqveeLqMBqBU/edit

 

Code repository:

https://github.com/blockchain-desktop/hyperledger-fabric-desktop

 

----

Yi DENG

Senior Software Engineer - Yonyou

Dear TSC and all, 

It is Yi. Recently, we developed a desktop app for Fabric. It is general-purpose, in other words, an API tool with GUI. We would like to contribute it to Hyperledger. Looking forward to discussion at TSC meeting. I can make a 5-minutes demonstration about what it is and how to use it.

 

Proposal:

https://docs.google.com/document/d/1XX-I1uud0DV2TVRj6H5w8r5OaX0W0VCZqveeLqMBqBU/edit

 

Code repository:

https://github.com/blockchain-desktop/hyperledger-fabric-desktop

 

----

Yi DENG

Senior Software Engineer - Yonyou

Hey Mark,

 

Thanks for sending this e-mail. I agree with Hart that a lot has changed in the past couple of years. I am generally in favor of applications being ‘projects’. The main reason is that I believe allowing applications will bring in new developers and increase deployments of Hyperledger projects. I think getting new contributors into Hyperledger is one of our biggest challenges and an inability to do that poses a risk to the long-term health of Hyperledger as a community.

 

The question of what exactly an ‘app’ is, is a bit fuzzy, but I haven’t yet seen a compelling reason for them to be out of scope. Ethereum has arguably the largest developer ecosystem, and many of its applications run on standardized smart contract logic (e.g. ERC20 and ERC721 contracts). By creating high-quality community-owned business logic, application development speed and security can be increased. The biggest issue I see is that the bar for developing an application is significantly lower than developing an entire blockchain stack, and so I think there are some governance questions around what are the criteria for accepting an application. This decision would also mean an expansion of the number of projects under the ‘umbrella’, which should cause us to re-think how we market and fund the projects (though that is probably better left to the board and marketing committee). I’d be interested in hearing other’s opinions on the potential downsides that they see by allowing applications.

 

On the second topic, I’m in favor of consolidating single-ledger tools into their top-level projects. It’s confusing that ‘Sawtooth Explorer’ supports Sawtooth, but ‘Hyperledger Explorer’ supports Fabric. These sorts of things continue to cause people to conflate Hyperledger the community with the Fabric project. However, if these projects were to move under their respective ledger, I think it raises some governance questions that need to be worked out. For example, ‘Hyperledger Explorer’ is predominately managed by DTTC maintainers last I checked, and I think it’s important that tool maintainers are able to keep their ‘sovereignty’ from the larger top-level projects. Similarly, top-level projects may want to protect their brand by not allowing tools under their project without first approving. In the event of a top-level project rejecting a tool, there should be a process to resolve that conflict at the TSC. I would support tools graduating to top-level projects as they support more than one ledger.

 

Finally, I think this leads to a question about whether apps should be top level projects or be under their respective ledgers. I would suggest following the same model as tools, where if the app is specifically designed around one ledger, then it should likely target being a subproject. If an app can be run across multiple ledgers (say an EVM-based smart contract) then it would be a good candidate for a top-level project as it could run across Burrow/Sawtooth/Fabric.

 

Kelly

 

From: <tsc@...> on behalf of "hmontgomery@..." <hmontgomery@...>
Date: Wednesday, November 14, 2018 at 3:33 PM
To: mark wagner <mwagner@...>, Yi DENG <michaelyideng@...>
Cc: Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] New Project Proposal: Fabric Desktop

 

Hi Mark,

 

I’ll defer #1 for now, but I have a number of comments about #2.

 

If you do want to take the angle that proposals that are specific to a DLT (or other existing project) should be under the same umbrella as the project, then you’d probably want to start with the Fabric Go SDK, the Fabric Python SDK, and the Java Chaincode support for Hyperledger Fabric projects.  These were all passed as fully independent projects (before you were on the TSC) but are clearly Fabric-specific to a degree that even Composer is not.  Correct me if I am wrong here, but I believe they are still wholly independent, although the maintainers are heavily involved in Fabric directly as well.

 

However, we did discuss this quite a bit almost a year and a half ago.  I have a bunch of emails from March and April 2017 where we discussed essentially this exact issue.  Some examples:

• A thread on the Fabric Go SDK proposal:  https://lists.hyperledger.org/g/tsc/message/672?p=,,,20,0,0,0::relevance,,I+think+SDK+projects+as+top+level+projects+would+be+a+bit+of+a+departure+from+what+we%E2%80%99ve+done+for+the+last+year.,20,2,0,17551967
• A discussion about whether or not we should have a tiered or flat project structure, with a lot of rambling by me:  https://lists.hyperledger.org/g/tsc/message/745?p=,,,20,0,0,0::relevance,,All%2C+just+a+reminder+that+we+should+try+to+wrap+this+discussion+up+before+next+week%27s+TSC.+,20,2,0,17551990

 

There are a bunch of other relevant emails around that time on the TSC list that you can find if you’re interested and search a little bit (I’m still waiting for someone to comb all of these for an all-time “dumb things said in TSC emails” list, on which I will surely be prominently featured).  In the end, we decided around that time that independent projects and a flat structure were the best way to maximize contributions.  I’m not sure if this group wants to have that discussion again, but, to be fair, Hyperledger has changed a lot in the last year and a half.

 

Anyways, I hope this helps you (and others) who weren’t around when we had to walk uphill both ways to the TSC meetings navigate this issue.

 

Thanks,

Hart

 

 

 

From: tsc@... [mailto:tsc@...] On Behalf Of mark wagner
Sent: Wednesday, November 14, 2018 11:16 AM
To: Yi DENG <michaelyideng@...>
Cc: Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] New Project Proposal: Fabric Desktop

 

I would like the TSC to discuss two things that this proposal raises.

 

1) if its an app, can it be a project ?

iirc some previous discussions, our charter does not allow that.

 

2) If a new proposal is specific to an existing project, should it be under the umbrella of the existing project or standalone ?

I know that things like Composer are standalone but I have heard multiple folks voice that in reality Composer should have been a subproject of Fabric.

 

What do other members think ?

 

-mark

 

On Fri, Nov 9, 2018 at 2:51 AM, Yi DENG <michaelyideng@...> wrote:

Dear TSC and all, 

It is Yi. Recently, we developed a desktop app for Fabric. It is general-purpose, in other words, an API tool with GUI. We would like to contribute it to Hyperledger. Looking forward to discussion at TSC meeting. I can make a 5-minutes demonstration about what it is and how to use it.

 

Proposal:

https://docs.google.com/document/d/1XX-I1uud0DV2TVRj6H5w8r5OaX0W0VCZqveeLqMBqBU/edit

 

Code repository:

https://github.com/blockchain-desktop/hyperledger-fabric-desktop

 

----

Yi DENG

Senior Software Engineer - Yonyou

--

Mark Wagner

Senior Principal Software Engineer

Performance and Scalability

Red Hat, Inc

Hi Yi Deng,

 

Building on my initial reply: https://lists.hyperledger.org/g/tsc/message/1845

 

The TSC had some previous discussion which Hart has linked to.

In reviewing that discussion we decided that the best approach for proposals like yours is for you to first
“seek and document support from the maintainers of a project it depends on”.

 

Can I ask you to please post this proposal to the fabric mailing list?

Solicit feedback from the maintainers and then include that with your proposal.

The maintainers may ask you to include your code in the existing Fabric project or may decline your proposal. If they decline the proposal you are still free to raise it again to the TSC along with that context and we can help decide what the right path is.

 

Thanks,

Dan

 

 

From: <tsc@...> on behalf of Yi DENG <michaelyideng@...>
Date: Sunday, November 25, 2018 at 8:30 PM
To: "Olson, Kelly M" <kelly.m.olson@...>
Cc: "hmontgomery@..." <hmontgomery@...>, "mwagner@..." <mwagner@...>, "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] New Project Proposal: Fabric Desktop

 

Hi TSC and all,

 

I think Olson gave a great explanation. Firstly, as the project devoloper, I personally don't care about if it is a top-level or sub-level project, but I do care about the autonomy. 

 

Secondly, this app is general-purpose. You can also call it a tool, not an app. 

 

Thirdly, supporting multiple blockchain projects is promising. But so far, I don't see a great standard to abstract workflow models. It leads to some projects which claim it will support multiple framworks, but hard to implement. Or may it be better to support different blockchain frameworks by different projects? In the case of desktop tools, maybe it is. If we do want tools that are cross-framework, a standard is needed. 

 

 

On Thu, Nov 15, 2018 at 8:29 AM Olson, Kelly M <kelly.m.olson@...> wrote:

Hey Mark,

 

Thanks for sending this e-mail. I agree with Hart that a lot has changed in the past couple of years. I am generally in favor of applications being ‘projects’. The main reason is that I believe allowing applications will bring in new developers and increase deployments of Hyperledger projects. I think getting new contributors into Hyperledger is one of our biggest challenges and an inability to do that poses a risk to the long-term health of Hyperledger as a community.

 

The question of what exactly an ‘app’ is, is a bit fuzzy, but I haven’t yet seen a compelling reason for them to be out of scope. Ethereum has arguably the largest developer ecosystem, and many of its applications run on standardized smart contract logic (e.g. ERC20 and ERC721 contracts). By creating high-quality community-owned business logic, application development speed and security can be increased. The biggest issue I see is that the bar for developing an application is significantly lower than developing an entire blockchain stack, and so I think there are some governance questions around what are the criteria for accepting an application. This decision would also mean an expansion of the number of projects under the ‘umbrella’, which should cause us to re-think how we market and fund the projects (though that is probably better left to the board and marketing committee). I’d be interested in hearing other’s opinions on the potential downsides that they see by allowing applications.

 

On the second topic, I’m in favor of consolidating single-ledger tools into their top-level projects. It’s confusing that ‘Sawtooth Explorer’ supports Sawtooth, but ‘Hyperledger Explorer’ supports Fabric. These sorts of things continue to cause people to conflate Hyperledger the community with the Fabric project. However, if these projects were to move under their respective ledger, I think it raises some governance questions that need to be worked out. For example, ‘Hyperledger Explorer’ is predominately managed by DTTC maintainers last I checked, and I think it’s important that tool maintainers are able to keep their ‘sovereignty’ from the larger top-level projects. Similarly, top-level projects may want to protect their brand by not allowing tools under their project without first approving. In the event of a top-level project rejecting a tool, there should be a process to resolve that conflict at the TSC. I would support tools graduating to top-level projects as they support more than one ledger.

 

Finally, I think this leads to a question about whether apps should be top level projects or be under their respective ledgers. I would suggest following the same model as tools, where if the app is specifically designed around one ledger, then it should likely target being a subproject. If an app can be run across multiple ledgers (say an EVM-based smart contract) then it would be a good candidate for a top-level project as it could run across Burrow/Sawtooth/Fabric.

 

Kelly

 

From: <tsc@...> on behalf of "hmontgomery@..." <hmontgomery@...>
Date: Wednesday, November 14, 2018 at 3:33 PM
To: mark wagner <mwagner@...>, Yi DENG <michaelyideng@...>
Cc: Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] New Project Proposal: Fabric Desktop

 

Hi Mark,

 

I’ll defer #1 for now, but I have a number of comments about #2.

 

If you do want to take the angle that proposals that are specific to a DLT (or other existing project) should be under the same umbrella as the project, then you’d probably want to start with the Fabric Go SDK, the Fabric Python SDK, and the Java Chaincode support for Hyperledger Fabric projects.  These were all passed as fully independent projects (before you were on the TSC) but are clearly Fabric-specific to a degree that even Composer is not.  Correct me if I am wrong here, but I believe they are still wholly independent, although the maintainers are heavily involved in Fabric directly as well.

 

However, we did discuss this quite a bit almost a year and a half ago.  I have a bunch of emails from March and April 2017 where we discussed essentially this exact issue.  Some examples:

• A thread on the Fabric Go SDK proposal:  https://lists.hyperledger.org/g/tsc/message/672?p=,,,20,0,0,0::relevance,,I+think+SDK+projects+as+top+level+projects+would+be+a+bit+of+a+departure+from+what+we%E2%80%99ve+done+for+the+last+year.,20,2,0,17551967
• A discussion about whether or not we should have a tiered or flat project structure, with a lot of rambling by me:  https://lists.hyperledger.org/g/tsc/message/745?p=,,,20,0,0,0::relevance,,All%2C+just+a+reminder+that+we+should+try+to+wrap+this+discussion+up+before+next+week%27s+TSC.+,20,2,0,17551990

 

There are a bunch of other relevant emails around that time on the TSC list that you can find if you’re interested and search a little bit (I’m still waiting for someone to comb all of these for an all-time “dumb things said in TSC emails” list, on which I will surely be prominently featured).  In the end, we decided around that time that independent projects and a flat structure were the best way to maximize contributions.  I’m not sure if this group wants to have that discussion again, but, to be fair, Hyperledger has changed a lot in the last year and a half.

 

Anyways, I hope this helps you (and others) who weren’t around when we had to walk uphill both ways to the TSC meetings navigate this issue.

 

Thanks,

Hart

 

 

 

From: tsc@... [mailto:tsc@...] On Behalf Of mark wagner
Sent: Wednesday, November 14, 2018 11:16 AM
To: Yi DENG <michaelyideng@...>
Cc: Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] New Project Proposal: Fabric Desktop

 

I would like the TSC to discuss two things that this proposal raises.

 

1) if its an app, can it be a project ?

iirc some previous discussions, our charter does not allow that.

 

2) If a new proposal is specific to an existing project, should it be under the umbrella of the existing project or standalone ?

I know that things like Composer are standalone but I have heard multiple folks voice that in reality Composer should have been a subproject of Fabric.

 

What do other members think ?

 

-mark

 

On Fri, Nov 9, 2018 at 2:51 AM, Yi DENG <michaelyideng@...> wrote:

Dear TSC and all, 

It is Yi. Recently, we developed a desktop app for Fabric. It is general-purpose, in other words, an API tool with GUI. We would like to contribute it to Hyperledger. Looking forward to discussion at TSC meeting. I can make a 5-minutes demonstration about what it is and how to use it.

 

Proposal:

https://docs.google.com/document/d/1XX-I1uud0DV2TVRj6H5w8r5OaX0W0VCZqveeLqMBqBU/edit

 

Code repository:

https://github.com/blockchain-desktop/hyperledger-fabric-desktop

 

----

Yi DENG

Senior Software Engineer - Yonyou

--

Mark Wagner

Senior Principal Software Engineer

Performance and Scalability

Red Hat, Inc

 

--

_________________________

邓羿

Yi DENG

Hi Yi Deng,

 

Building on my initial reply: https://lists.hyperledger.org/g/tsc/message/1845

 

The TSC had some previous discussion which Hart has linked to.

In reviewing that discussion we decided that the best approach for proposals like yours is for you to first
“seek and document support from the maintainers of a project it depends on”.

 

Can I ask you to please post this proposal to the fabric mailing list?

Solicit feedback from the maintainers and then include that with your proposal.

The maintainers may ask you to include your code in the existing Fabric project or may decline your proposal. If they decline the proposal you are still free to raise it again to the TSC along with that context and we can help decide what the right path is.

 

Thanks,

Dan

 

 

From: <tsc@...> on behalf of Yi DENG <michaelyideng@...>
Date: Sunday, November 25, 2018 at 8:30 PM
To: "Olson, Kelly M" <kelly.m.olson@...>
Cc: "hmontgomery@..." <hmontgomery@...>, "mwagner@..." <mwagner@...>, "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] New Project Proposal: Fabric Desktop

 

Hi TSC and all,

 

I think Olson gave a great explanation. Firstly, as the project devoloper, I personally don't care about if it is a top-level or sub-level project, but I do care about the autonomy. 

 

Secondly, this app is general-purpose. You can also call it a tool, not an app. 

 

Thirdly, supporting multiple blockchain projects is promising. But so far, I don't see a great standard to abstract workflow models. It leads to some projects which claim it will support multiple framworks, but hard to implement. Or may it be better to support different blockchain frameworks by different projects? In the case of desktop tools, maybe it is. If we do want tools that are cross-framework, a standard is needed. 

 

 

On Thu, Nov 15, 2018 at 8:29 AM Olson, Kelly M <kelly.m.olson@...> wrote:

Hey Mark,

 

Thanks for sending this e-mail. I agree with Hart that a lot has changed in the past couple of years. I am generally in favor of applications being ‘projects’. The main reason is that I believe allowing applications will bring in new developers and increase deployments of Hyperledger projects. I think getting new contributors into Hyperledger is one of our biggest challenges and an inability to do that poses a risk to the long-term health of Hyperledger as a community.

 

The question of what exactly an ‘app’ is, is a bit fuzzy, but I haven’t yet seen a compelling reason for them to be out of scope. Ethereum has arguably the largest developer ecosystem, and many of its applications run on standardized smart contract logic (e.g. ERC20 and ERC721 contracts). By creating high-quality community-owned business logic, application development speed and security can be increased. The biggest issue I see is that the bar for developing an application is significantly lower than developing an entire blockchain stack, and so I think there are some governance questions around what are the criteria for accepting an application. This decision would also mean an expansion of the number of projects under the ‘umbrella’, which should cause us to re-think how we market and fund the projects (though that is probably better left to the board and marketing committee). I’d be interested in hearing other’s opinions on the potential downsides that they see by allowing applications.

 

On the second topic, I’m in favor of consolidating single-ledger tools into their top-level projects. It’s confusing that ‘Sawtooth Explorer’ supports Sawtooth, but ‘Hyperledger Explorer’ supports Fabric. These sorts of things continue to cause people to conflate Hyperledger the community with the Fabric project. However, if these projects were to move under their respective ledger, I think it raises some governance questions that need to be worked out. For example, ‘Hyperledger Explorer’ is predominately managed by DTTC maintainers last I checked, and I think it’s important that tool maintainers are able to keep their ‘sovereignty’ from the larger top-level projects. Similarly, top-level projects may want to protect their brand by not allowing tools under their project without first approving. In the event of a top-level project rejecting a tool, there should be a process to resolve that conflict at the TSC. I would support tools graduating to top-level projects as they support more than one ledger.

 

Finally, I think this leads to a question about whether apps should be top level projects or be under their respective ledgers. I would suggest following the same model as tools, where if the app is specifically designed around one ledger, then it should likely target being a subproject. If an app can be run across multiple ledgers (say an EVM-based smart contract) then it would be a good candidate for a top-level project as it could run across Burrow/Sawtooth/Fabric.

 

Kelly

 

From: <tsc@...> on behalf of "hmontgomery@..." <hmontgomery@...>
Date: Wednesday, November 14, 2018 at 3:33 PM
To: mark wagner <mwagner@...>, Yi DENG <michaelyideng@...>
Cc: Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] New Project Proposal: Fabric Desktop

 

Hi Mark,

 

I’ll defer #1 for now, but I have a number of comments about #2.

 

If you do want to take the angle that proposals that are specific to a DLT (or other existing project) should be under the same umbrella as the project, then you’d probably want to start with the Fabric Go SDK, the Fabric Python SDK, and the Java Chaincode support for Hyperledger Fabric projects.  These were all passed as fully independent projects (before you were on the TSC) but are clearly Fabric-specific to a degree that even Composer is not.  Correct me if I am wrong here, but I believe they are still wholly independent, although the maintainers are heavily involved in Fabric directly as well.

 

However, we did discuss this quite a bit almost a year and a half ago.  I have a bunch of emails from March and April 2017 where we discussed essentially this exact issue.  Some examples:

• A thread on the Fabric Go SDK proposal:  https://lists.hyperledger.org/g/tsc/message/672?p=,,,20,0,0,0::relevance,,I+think+SDK+projects+as+top+level+projects+would+be+a+bit+of+a+departure+from+what+we%E2%80%99ve+done+for+the+last+year.,20,2,0,17551967
• A discussion about whether or not we should have a tiered or flat project structure, with a lot of rambling by me:  https://lists.hyperledger.org/g/tsc/message/745?p=,,,20,0,0,0::relevance,,All%2C+just+a+reminder+that+we+should+try+to+wrap+this+discussion+up+before+next+week%27s+TSC.+,20,2,0,17551990

 

There are a bunch of other relevant emails around that time on the TSC list that you can find if you’re interested and search a little bit (I’m still waiting for someone to comb all of these for an all-time “dumb things said in TSC emails” list, on which I will surely be prominently featured).  In the end, we decided around that time that independent projects and a flat structure were the best way to maximize contributions.  I’m not sure if this group wants to have that discussion again, but, to be fair, Hyperledger has changed a lot in the last year and a half.

 

Anyways, I hope this helps you (and others) who weren’t around when we had to walk uphill both ways to the TSC meetings navigate this issue.

 

Thanks,

Hart

 

 

 

From: tsc@... [mailto:tsc@...] On Behalf Of mark wagner
Sent: Wednesday, November 14, 2018 11:16 AM
To: Yi DENG <michaelyideng@...>
Cc: Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] New Project Proposal: Fabric Desktop

 

I would like the TSC to discuss two things that this proposal raises.

 

1) if its an app, can it be a project ?

iirc some previous discussions, our charter does not allow that.

 

2) If a new proposal is specific to an existing project, should it be under the umbrella of the existing project or standalone ?

I know that things like Composer are standalone but I have heard multiple folks voice that in reality Composer should have been a subproject of Fabric.

 

What do other members think ?

 

-mark

 

On Fri, Nov 9, 2018 at 2:51 AM, Yi DENG <michaelyideng@...> wrote:

Dear TSC and all, 

It is Yi. Recently, we developed a desktop app for Fabric. It is general-purpose, in other words, an API tool with GUI. We would like to contribute it to Hyperledger. Looking forward to discussion at TSC meeting. I can make a 5-minutes demonstration about what it is and how to use it.

 

Proposal:

https://docs.google.com/document/d/1XX-I1uud0DV2TVRj6H5w8r5OaX0W0VCZqveeLqMBqBU/edit

 

Code repository:

https://github.com/blockchain-desktop/hyperledger-fabric-desktop

 

----

Yi DENG

Senior Software Engineer - Yonyou

--

Mark Wagner

Senior Principal Software Engineer

Performance and Scalability

Red Hat, Inc

 

--

_________________________

邓羿

Yi DENG