Date   

Re: Test net thinking

Duc Trinh <duc.m.trinh@...>
 

Both would useful. However, if there is a need to prioritize, I would like to throw a +1 for standing up a test net - especially for Fabric. I think the motivations for having a test are similar to what has been articulated for Stellar (@ https://www.stellar.org/developers/guides/concepts/test-net.html)

To keep hosting costs in check, HL can reset the network periodically (again, similar to what Stellar does).

Cheers,
Duc

On 10/25/18, 11:13 AM, "tsc@... on behalf of David Huseby" <tsc@... on behalf of dhuseby@...> wrote:

I think all of you are making very good points. There seem to be two
camps of "itches":

1) chaincode and developer UX focused "let me quickly test this".
2) developer/integration testing of an instance of a blockchain for
purposes of running it through the gamut of tests and letting it soak
to test stability over time.

I draw the lines there because addressing #1 is not really a concern
of test nets. I would think that something like a universal HL
Composer would be the way to go. Or better yet, a plugin for VSCode
or Vim/Emacs that allows for quick deployment of chaincode to a
running blockchain and then has useful hooks for testing. Again, this
is more developer interfacing than test nets and outside of the scope
of the proposal.

#2 is absolutely test nets and I think the correct way to address this
is for HL to pay for managed Kubernetes infrastructure that teams can
use Kubernetes configs and/or Helm charts to deploy a blockchain
network on for whatever they need to do, be it chaos testing, load
testing, or just a soak test. We have already begun the effort to
standardize Kubernetes configs/Helm charts in several projects. The
HL Cello meeting is where those people have been congregating and the
next step there is to have the different blockchain projects start
publishing official, composable configs/charts as part of their build
process and published outputs. This would make it trivial for a
developer/tester to "kubectl apply fabric-1.3.yaml" on Amazon EKS or
GCE or whatever Kubernetes infrastructure we set up.

I prefer Amazon because it has a very good cost predictor calculator
that can be used to see how much the tests would cost to run and it
would help with our accounting.

As for HL managment, my plan is that we only have very minimal
management that is focused around giving out credentials to use the
Kubernetes infrastructure and handling re-embursements for the bills.
I think it should be entirely upon the user/tester to handle spinning
up/down their blockchain. IMO HL shouldn't be in the business of
being IT for everybody who wants to spin up a blockchain for testing.
The cost of that would be huge and the time spent on that would
greatly impact our ability to grow the community in all other ways.

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

On Thu, Oct 25, 2018 at 8:28 AM Casey Kuhlman <casey@...> wrote:
>
> From the burrow perspective, we'd be very interested in test networks to actually run testing in terms of performance testing, chaos testing, soak testing, long-lived network testing which a simple CI run post merge cannot really handle.
>
> While I think both Dan and Chris make valid points in terms of positioning the test networks as things to help users get started faster, our interest from the burrow team is less in that area and more in having an HL managed infrastructure which can help us.... test.
>
> My point, and the reason that Silas brought this up a few months ago to the TSC is that from a testing and performance perspective I think we could do much better as a community. CCNF and the Kubernetes project have a super clean and easy to approach CI system that made it dead simple for me as a contributor when I started making contributions to helm. From my perspective we'd be very interested to see if HL could coordinate with CCNF (as Ry mentioned on RocketChat).
> ____________________________________
>
> Casey Kuhlman, Monax
> CEO
> Site: https://monax.io
> Twitter: @monaxhq, @compleatang
> Email: casey@...
> Phone (US): +1-423-523-9531; (UK): +44-75-073-96359
> ____________________________________
>
>
> On Thu, Oct 25, 2018 at 4:03 PM Christopher Ferris <chris.ferris@...> wrote:
>>
>> Dan, yes, but my response to that would be that Fabric should improve its UX around deploying and engaging chaincode/smart contract.
>> Having a testnet does nothing to improve that experience IMNSHO.
>>
>> Chris
>>
>> On Thu, Oct 25, 2018 at 10:18 AM Dan Selman <dan@...> wrote:
>>>
>>> Chris,
>>>
>>> I think you raise some very valid points regarding operating a test net. I'd like to inject an end user perspective if I may.
>>>
>>> I think Ethereum wins from an ease of use perspective because people can easily write a smart contract and deploy it to a test network. That's what the vast majority of developers want to get done when they first encounter blockchain and IMO that is where Fabric (and others) fall down. HLF v1.3 has made it (relatively) easy to *start* the network on your laptop, but once you actually want to deploy chaincode and interact with it, it is a whole different story: you start hacking on fabcar and trying to understand how ./startFabric.sh, enrollAdrmin.js, registerUser.js, hlf-key-store, docker etc all work. Contrast with using http://remix.ethereum.org running in the browser, or connected to https://infura.io or https://kaleido.io for writing your first Solidity code.
>>>
>>> There's an opportunity to do something similar to remix using the Composer Playground connected to a test net which is worth exploring imo. I don't know if that should be the remit of HL/TSC but there's clearly a need for something like that to attract more developers.
>>>
>>> Sincerely,
>>> Dan
>>>
>>>
>>> On Thu, Oct 25, 2018 at 2:54 PM Christopher Ferris <chris.ferris@...> wrote:
>>>>
>>>> I think that we need to consider what we think a "test net" is. Is it a whole network that a developer spins up themselves? Is it a pre-existing network that we have launched and that developers can use to deploy a smart contract and kick the tires? Is it permissioned? Permissionless? What are the implications? Will there be likelihood of noisy neighbor situations? Crypto Kitties? Who will monitor the experience? What if it gets really bogged down? Who is monitoring that it is running? Will users walk away from a bad experience with a bad taste in their mouths? How will the experience reflect on the project and the organization?
>>>>
>>>> I don't disagree that we want to make it dead simple to engage with the various projects. However, I can say that for Fabric, the process could not be simpler.
>>>>
>>>> download fabric-samples repo, images and binaries (one click)
>>>> cd first-network
>>>> byfn.sh up
>>>>
>>>> three commands and you have it running on your laptop.
>>>>
>>>> Could we create some helm charts that could be used to deploy our various projects to K8s? Let people deal with finding the compute however they like (maybe point at alternatives) but we don't host/pay?
>>>>
>>>> I ask because I really don't understand what problem we think we are solving with a test net, nor do I believe that we have considered the broader implications of running a cloud service on a volunteer basis.
>>>>
>>>> Chris
>>>>
>>>> On Wed, Oct 24, 2018 at 5:56 PM David Huseby <dhuseby@...> wrote:
>>>>>
>>>>> Hi TSC,
>>>>>
>>>>> I had a discussion with Ry this week while manning the booth at ATO in Raleigh and we both think the right way to go is a two pronged approach:
>>>>>
>>>>> The first prong will be to engage with the free kubernetes hosting being paid for by (I think) the CNCF project. Ry knows more about it than I do.
>>>>>
>>>>> The second prong would be to set aside some budget to cover the cost of people running networks on Amazon EKS. We could set some rule like we cover the cost up to $200 for the first month with an opportunity to get additional months with approval.
>>>>>
>>>>> I agree with Chris and Ry and I’m concerned about the human overhead of trying to run test nets for people. I think the best compromise is to just cover the bills for people spinning up test networks on hosted kubernetes platforms. The oversight needs to be an easy application and approval process as well as an easy renewal process. I was thinking that $20k would be enough to cover. That’s at least 10 networks per month for a year.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Dave
>>>>> --
>>>>> ---
>>>>> David Huseby
>>>>> Security Maven, Hyperledger
>>>>> The Linux Foundation
>>>>> +1-206-234-2392
>>>>> dhuseby@...
>>>
>>>
>>>
>>> --
>>> Dan Selman
>>> CTO, Clause Inc.
>>> @danielselman
>>>
>>


Re: Test net thinking

David Huseby <dhuseby@...>
 

I think all of you are making very good points. There seem to be two
camps of "itches":

1) chaincode and developer UX focused "let me quickly test this".
2) developer/integration testing of an instance of a blockchain for
purposes of running it through the gamut of tests and letting it soak
to test stability over time.

I draw the lines there because addressing #1 is not really a concern
of test nets. I would think that something like a universal HL
Composer would be the way to go. Or better yet, a plugin for VSCode
or Vim/Emacs that allows for quick deployment of chaincode to a
running blockchain and then has useful hooks for testing. Again, this
is more developer interfacing than test nets and outside of the scope
of the proposal.

#2 is absolutely test nets and I think the correct way to address this
is for HL to pay for managed Kubernetes infrastructure that teams can
use Kubernetes configs and/or Helm charts to deploy a blockchain
network on for whatever they need to do, be it chaos testing, load
testing, or just a soak test. We have already begun the effort to
standardize Kubernetes configs/Helm charts in several projects. The
HL Cello meeting is where those people have been congregating and the
next step there is to have the different blockchain projects start
publishing official, composable configs/charts as part of their build
process and published outputs. This would make it trivial for a
developer/tester to "kubectl apply fabric-1.3.yaml" on Amazon EKS or
GCE or whatever Kubernetes infrastructure we set up.

I prefer Amazon because it has a very good cost predictor calculator
that can be used to see how much the tests would cost to run and it
would help with our accounting.

As for HL managment, my plan is that we only have very minimal
management that is focused around giving out credentials to use the
Kubernetes infrastructure and handling re-embursements for the bills.
I think it should be entirely upon the user/tester to handle spinning
up/down their blockchain. IMO HL shouldn't be in the business of
being IT for everybody who wants to spin up a blockchain for testing.
The cost of that would be huge and the time spent on that would
greatly impact our ability to grow the community in all other ways.

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

On Thu, Oct 25, 2018 at 8:28 AM Casey Kuhlman <casey@...> wrote:

From the burrow perspective, we'd be very interested in test networks to actually run testing in terms of performance testing, chaos testing, soak testing, long-lived network testing which a simple CI run post merge cannot really handle.

While I think both Dan and Chris make valid points in terms of positioning the test networks as things to help users get started faster, our interest from the burrow team is less in that area and more in having an HL managed infrastructure which can help us.... test.

My point, and the reason that Silas brought this up a few months ago to the TSC is that from a testing and performance perspective I think we could do much better as a community. CCNF and the Kubernetes project have a super clean and easy to approach CI system that made it dead simple for me as a contributor when I started making contributions to helm. From my perspective we'd be very interested to see if HL could coordinate with CCNF (as Ry mentioned on RocketChat).
____________________________________

Casey Kuhlman, Monax
CEO
Site: https://monax.io
Twitter: @monaxhq, @compleatang
Email: casey@...
Phone (US): +1-423-523-9531; (UK): +44-75-073-96359
____________________________________


On Thu, Oct 25, 2018 at 4:03 PM Christopher Ferris <chris.ferris@...> wrote:

Dan, yes, but my response to that would be that Fabric should improve its UX around deploying and engaging chaincode/smart contract.
Having a testnet does nothing to improve that experience IMNSHO.

Chris

On Thu, Oct 25, 2018 at 10:18 AM Dan Selman <dan@...> wrote:

Chris,

I think you raise some very valid points regarding operating a test net. I'd like to inject an end user perspective if I may.

I think Ethereum wins from an ease of use perspective because people can easily write a smart contract and deploy it to a test network. That's what the vast majority of developers want to get done when they first encounter blockchain and IMO that is where Fabric (and others) fall down. HLF v1.3 has made it (relatively) easy to *start* the network on your laptop, but once you actually want to deploy chaincode and interact with it, it is a whole different story: you start hacking on fabcar and trying to understand how ./startFabric.sh, enrollAdrmin.js, registerUser.js, hlf-key-store, docker etc all work. Contrast with using http://remix.ethereum.org running in the browser, or connected to https://infura.io or https://kaleido.io for writing your first Solidity code.

There's an opportunity to do something similar to remix using the Composer Playground connected to a test net which is worth exploring imo. I don't know if that should be the remit of HL/TSC but there's clearly a need for something like that to attract more developers.

Sincerely,
Dan


On Thu, Oct 25, 2018 at 2:54 PM Christopher Ferris <chris.ferris@...> wrote:

I think that we need to consider what we think a "test net" is. Is it a whole network that a developer spins up themselves? Is it a pre-existing network that we have launched and that developers can use to deploy a smart contract and kick the tires? Is it permissioned? Permissionless? What are the implications? Will there be likelihood of noisy neighbor situations? Crypto Kitties? Who will monitor the experience? What if it gets really bogged down? Who is monitoring that it is running? Will users walk away from a bad experience with a bad taste in their mouths? How will the experience reflect on the project and the organization?

I don't disagree that we want to make it dead simple to engage with the various projects. However, I can say that for Fabric, the process could not be simpler.

download fabric-samples repo, images and binaries (one click)
cd first-network
byfn.sh up

three commands and you have it running on your laptop.

Could we create some helm charts that could be used to deploy our various projects to K8s? Let people deal with finding the compute however they like (maybe point at alternatives) but we don't host/pay?

I ask because I really don't understand what problem we think we are solving with a test net, nor do I believe that we have considered the broader implications of running a cloud service on a volunteer basis.

Chris

On Wed, Oct 24, 2018 at 5:56 PM David Huseby <dhuseby@...> wrote:

Hi TSC,

I had a discussion with Ry this week while manning the booth at ATO in Raleigh and we both think the right way to go is a two pronged approach:

The first prong will be to engage with the free kubernetes hosting being paid for by (I think) the CNCF project. Ry knows more about it than I do.

The second prong would be to set aside some budget to cover the cost of people running networks on Amazon EKS. We could set some rule like we cover the cost up to $200 for the first month with an opportunity to get additional months with approval.

I agree with Chris and Ry and I’m concerned about the human overhead of trying to run test nets for people. I think the best compromise is to just cover the bills for people spinning up test networks on hosted kubernetes platforms. The oversight needs to be an easy application and approval process as well as an easy renewal process. I was thinking that $20k would be enough to cover. That’s at least 10 networks per month for a year.

Thoughts?

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


--
Dan Selman
CTO, Clause Inc.
@danielselman


Re: Test net thinking

Casey Kuhlman
 

From the burrow perspective, we'd be very interested in test networks to actually run testing in terms of performance testing, chaos testing, soak testing, long-lived network testing which a simple CI run post merge cannot really handle. 

While I think both Dan and Chris make valid points in terms of positioning the test networks as things to help users get started faster, our interest from the burrow team is less in that area and more in having an HL managed infrastructure which can help us.... test.

My point, and the reason that Silas brought this up a few months ago to the TSC is that from a testing and performance perspective I think we could do much better as a community. CCNF and the Kubernetes project have a super clean and easy to approach CI system that made it dead simple for me as a contributor when I started making contributions to helm. From my perspective we'd be very interested to see if HL could coordinate with CCNF (as Ry mentioned on RocketChat).
____________________________________

Casey Kuhlman, Monax
CEO
Email: casey@... 
Phone (US): +1-423-523-9531(UK): +44-75-073-96359
____________________________________


On Thu, Oct 25, 2018 at 4:03 PM Christopher Ferris <chris.ferris@...> wrote:
Dan, yes, but my response to that would be that Fabric should improve its UX around deploying and engaging chaincode/smart contract.
Having a testnet does nothing to improve that experience IMNSHO.

Chris

On Thu, Oct 25, 2018 at 10:18 AM Dan Selman <dan@...> wrote:
Chris,

I think you raise some very valid points regarding operating a test net. I'd like to inject an end user perspective if I may. 

I think Ethereum wins from an ease of use perspective because people can easily write a smart contract and deploy it to a test network. That's what the vast majority of developers want to get done when they first encounter blockchain and IMO that is where Fabric (and others) fall down. HLF v1.3 has made it (relatively) easy to *start* the network on your laptop, but once you actually want to deploy chaincode and interact with it, it is a whole different story: you start hacking on fabcar and trying to understand how ./startFabric.sh, enrollAdrmin.js, registerUser.js, hlf-key-store, docker etc all work. Contrast with using http://remix.ethereum.org running in the browser, or connected to https://infura.io or https://kaleido.io for writing your first Solidity code.

There's an opportunity to do something similar to remix using the Composer Playground connected to a test net which is worth exploring imo. I don't know if that should be the remit of HL/TSC but there's clearly a need for something like that to attract more developers.

Sincerely,
Dan


On Thu, Oct 25, 2018 at 2:54 PM Christopher Ferris <chris.ferris@...> wrote:
I think that we need to consider what we think a "test net" is. Is it a whole network that a developer spins up themselves? Is it a pre-existing network that we have launched and that developers can use to deploy a smart contract and kick the tires? Is it permissioned? Permissionless? What are the implications? Will there be likelihood of noisy neighbor situations? Crypto Kitties? Who will monitor the experience? What if it gets really bogged down? Who is monitoring that it is running? Will users walk away from a bad experience with a bad taste in their mouths? How will the experience reflect on the project and the organization?

I don't disagree that we want to make it dead simple to engage with the various projects. However, I can say that for Fabric, the process could not be simpler.

download fabric-samples repo, images and binaries (one click)
cd first-network
byfn.sh up

three commands and you have it running on your laptop.

Could we create some helm charts that could be used to deploy our various projects to K8s? Let people deal with finding the compute however they like (maybe point at alternatives) but we don't host/pay?

I ask because I really don't understand what problem we think we are solving with a test net, nor do I believe that we have considered the broader implications of running a cloud service on a volunteer basis.

Chris

On Wed, Oct 24, 2018 at 5:56 PM David Huseby <dhuseby@...> wrote:
Hi TSC,

I had a discussion with Ry this week while manning the booth at ATO in Raleigh and we both think the right way to go is a two pronged approach:

The first prong will be to engage with the free kubernetes hosting being paid for by (I think) the CNCF project. Ry knows more about it than I do. 

The second prong would be to set aside some budget to cover the cost of people running networks on Amazon EKS. We could set some rule like we cover the cost up to $200 for the first month with an opportunity to get additional months with approval. 

I agree with Chris and Ry and I’m concerned about the human overhead of trying to run test nets for people. I think the best compromise is to just cover the bills for people spinning up test networks on hosted kubernetes platforms. The oversight needs to be an easy application and approval process as well as an easy renewal process. I was thinking that $20k would be enough to cover. That’s at least 10 networks per month for a year. 

Thoughts?

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


--
Dan Selman
CTO, Clause Inc.
@danielselman


Re: Test net thinking

Christopher Ferris <chris.ferris@...>
 

Dan, yes, but my response to that would be that Fabric should improve its UX around deploying and engaging chaincode/smart contract.
Having a testnet does nothing to improve that experience IMNSHO.

Chris


On Thu, Oct 25, 2018 at 10:18 AM Dan Selman <dan@...> wrote:
Chris,

I think you raise some very valid points regarding operating a test net. I'd like to inject an end user perspective if I may. 

I think Ethereum wins from an ease of use perspective because people can easily write a smart contract and deploy it to a test network. That's what the vast majority of developers want to get done when they first encounter blockchain and IMO that is where Fabric (and others) fall down. HLF v1.3 has made it (relatively) easy to *start* the network on your laptop, but once you actually want to deploy chaincode and interact with it, it is a whole different story: you start hacking on fabcar and trying to understand how ./startFabric.sh, enrollAdrmin.js, registerUser.js, hlf-key-store, docker etc all work. Contrast with using http://remix.ethereum.org running in the browser, or connected to https://infura.io or https://kaleido.io for writing your first Solidity code.

There's an opportunity to do something similar to remix using the Composer Playground connected to a test net which is worth exploring imo. I don't know if that should be the remit of HL/TSC but there's clearly a need for something like that to attract more developers.

Sincerely,
Dan


On Thu, Oct 25, 2018 at 2:54 PM Christopher Ferris <chris.ferris@...> wrote:
I think that we need to consider what we think a "test net" is. Is it a whole network that a developer spins up themselves? Is it a pre-existing network that we have launched and that developers can use to deploy a smart contract and kick the tires? Is it permissioned? Permissionless? What are the implications? Will there be likelihood of noisy neighbor situations? Crypto Kitties? Who will monitor the experience? What if it gets really bogged down? Who is monitoring that it is running? Will users walk away from a bad experience with a bad taste in their mouths? How will the experience reflect on the project and the organization?

I don't disagree that we want to make it dead simple to engage with the various projects. However, I can say that for Fabric, the process could not be simpler.

download fabric-samples repo, images and binaries (one click)
cd first-network
byfn.sh up

three commands and you have it running on your laptop.

Could we create some helm charts that could be used to deploy our various projects to K8s? Let people deal with finding the compute however they like (maybe point at alternatives) but we don't host/pay?

I ask because I really don't understand what problem we think we are solving with a test net, nor do I believe that we have considered the broader implications of running a cloud service on a volunteer basis.

Chris

On Wed, Oct 24, 2018 at 5:56 PM David Huseby <dhuseby@...> wrote:
Hi TSC,

I had a discussion with Ry this week while manning the booth at ATO in Raleigh and we both think the right way to go is a two pronged approach:

The first prong will be to engage with the free kubernetes hosting being paid for by (I think) the CNCF project. Ry knows more about it than I do. 

The second prong would be to set aside some budget to cover the cost of people running networks on Amazon EKS. We could set some rule like we cover the cost up to $200 for the first month with an opportunity to get additional months with approval. 

I agree with Chris and Ry and I’m concerned about the human overhead of trying to run test nets for people. I think the best compromise is to just cover the bills for people spinning up test networks on hosted kubernetes platforms. The oversight needs to be an easy application and approval process as well as an easy renewal process. I was thinking that $20k would be enough to cover. That’s at least 10 networks per month for a year. 

Thoughts?

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



--
Dan Selman
CTO, Clause Inc.
@danielselman


Re: Test net thinking

Dan Selman
 

Chris,

I think you raise some very valid points regarding operating a test net. I'd like to inject an end user perspective if I may. 

I think Ethereum wins from an ease of use perspective because people can easily write a smart contract and deploy it to a test network. That's what the vast majority of developers want to get done when they first encounter blockchain and IMO that is where Fabric (and others) fall down. HLF v1.3 has made it (relatively) easy to *start* the network on your laptop, but once you actually want to deploy chaincode and interact with it, it is a whole different story: you start hacking on fabcar and trying to understand how ./startFabric.sh, enrollAdrmin.js, registerUser.js, hlf-key-store, docker etc all work. Contrast with using http://remix.ethereum.org running in the browser, or connected to https://infura.io or https://kaleido.io for writing your first Solidity code.

There's an opportunity to do something similar to remix using the Composer Playground connected to a test net which is worth exploring imo. I don't know if that should be the remit of HL/TSC but there's clearly a need for something like that to attract more developers.

Sincerely,
Dan


On Thu, Oct 25, 2018 at 2:54 PM Christopher Ferris <chris.ferris@...> wrote:
I think that we need to consider what we think a "test net" is. Is it a whole network that a developer spins up themselves? Is it a pre-existing network that we have launched and that developers can use to deploy a smart contract and kick the tires? Is it permissioned? Permissionless? What are the implications? Will there be likelihood of noisy neighbor situations? Crypto Kitties? Who will monitor the experience? What if it gets really bogged down? Who is monitoring that it is running? Will users walk away from a bad experience with a bad taste in their mouths? How will the experience reflect on the project and the organization?

I don't disagree that we want to make it dead simple to engage with the various projects. However, I can say that for Fabric, the process could not be simpler.

download fabric-samples repo, images and binaries (one click)
cd first-network
byfn.sh up

three commands and you have it running on your laptop.

Could we create some helm charts that could be used to deploy our various projects to K8s? Let people deal with finding the compute however they like (maybe point at alternatives) but we don't host/pay?

I ask because I really don't understand what problem we think we are solving with a test net, nor do I believe that we have considered the broader implications of running a cloud service on a volunteer basis.

Chris

On Wed, Oct 24, 2018 at 5:56 PM David Huseby <dhuseby@...> wrote:
Hi TSC,

I had a discussion with Ry this week while manning the booth at ATO in Raleigh and we both think the right way to go is a two pronged approach:

The first prong will be to engage with the free kubernetes hosting being paid for by (I think) the CNCF project. Ry knows more about it than I do. 

The second prong would be to set aside some budget to cover the cost of people running networks on Amazon EKS. We could set some rule like we cover the cost up to $200 for the first month with an opportunity to get additional months with approval. 

I agree with Chris and Ry and I’m concerned about the human overhead of trying to run test nets for people. I think the best compromise is to just cover the bills for people spinning up test networks on hosted kubernetes platforms. The oversight needs to be an easy application and approval process as well as an easy renewal process. I was thinking that $20k would be enough to cover. That’s at least 10 networks per month for a year. 

Thoughts?

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



--
Dan Selman
CTO, Clause Inc.
@danielselman


Re: Test net thinking

Christopher Ferris <chris.ferris@...>
 

I think that we need to consider what we think a "test net" is. Is it a whole network that a developer spins up themselves? Is it a pre-existing network that we have launched and that developers can use to deploy a smart contract and kick the tires? Is it permissioned? Permissionless? What are the implications? Will there be likelihood of noisy neighbor situations? Crypto Kitties? Who will monitor the experience? What if it gets really bogged down? Who is monitoring that it is running? Will users walk away from a bad experience with a bad taste in their mouths? How will the experience reflect on the project and the organization?

I don't disagree that we want to make it dead simple to engage with the various projects. However, I can say that for Fabric, the process could not be simpler.

download fabric-samples repo, images and binaries (one click)
cd first-network
byfn.sh up

three commands and you have it running on your laptop.

Could we create some helm charts that could be used to deploy our various projects to K8s? Let people deal with finding the compute however they like (maybe point at alternatives) but we don't host/pay?

I ask because I really don't understand what problem we think we are solving with a test net, nor do I believe that we have considered the broader implications of running a cloud service on a volunteer basis.

Chris


On Wed, Oct 24, 2018 at 5:56 PM David Huseby <dhuseby@...> wrote:
Hi TSC,

I had a discussion with Ry this week while manning the booth at ATO in Raleigh and we both think the right way to go is a two pronged approach:

The first prong will be to engage with the free kubernetes hosting being paid for by (I think) the CNCF project. Ry knows more about it than I do. 

The second prong would be to set aside some budget to cover the cost of people running networks on Amazon EKS. We could set some rule like we cover the cost up to $200 for the first month with an opportunity to get additional months with approval. 

I agree with Chris and Ry and I’m concerned about the human overhead of trying to run test nets for people. I think the best compromise is to just cover the bills for people spinning up test networks on hosted kubernetes platforms. The oversight needs to be an easy application and approval process as well as an easy renewal process. I was thinking that $20k would be enough to cover. That’s at least 10 networks per month for a year. 

Thoughts?

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


Agenda for October 25th, 2018

Todd Benzies <tbenzies@...>
 

  • Event Reminders

  • Quarterly project updates
    • Hyperledger Iroha update
    • November 1st:  Hyperledger Composer update
  • Quarterly WG updates
    • Technical WG China update
    • November 1st:  Training and Education WG update
  • crypto-lib proposal proposal (Hart Montgomery)
  • Testnet discussion/proposal (Dave Huseby)

--
Todd Benzies
Sr. Director, Program Management & Operations
The Linux Foundation
+1 (415) 412-0310 (m)


Test net thinking

David Huseby <dhuseby@...>
 

Hi TSC,

I had a discussion with Ry this week while manning the booth at ATO in Raleigh and we both think the right way to go is a two pronged approach:

The first prong will be to engage with the free kubernetes hosting being paid for by (I think) the CNCF project. Ry knows more about it than I do. 

The second prong would be to set aside some budget to cover the cost of people running networks on Amazon EKS. We could set some rule like we cover the cost up to $200 for the first month with an opportunity to get additional months with approval. 

I agree with Chris and Ry and I’m concerned about the human overhead of trying to run test nets for people. I think the best compromise is to just cover the bills for people spinning up test networks on hosted kubernetes platforms. The oversight needs to be an easy application and approval process as well as an easy renewal process. I was thinking that $20k would be enough to cover. That’s at least 10 networks per month for a year. 

Thoughts?

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


Re: Devcon in Prague

Brian Behlendorf
 

That's great.  And yes my ask was of anyone following the list, not just TSC members.  :)  See you in SG.

Brian

On 10/23/18 6:47 PM, Duncan Johnston-Watt wrote:
Brian

I appreciate that we are not TSC members but FWIW myself and Kai Davenport will be at SG Fintech Festival where we will be delivering a two day workshop as part of their industry events program Nov 15&16 - https://fintechfestival.sg/festival-line-up/industry/ - which we will be promoting shortly.

If you or Julian know of folk locally in SG who would benefit from this but workshop who don't have the budget please connect us and we will give them a discount code.

Best

Duncan

On Wed, Oct 24, 2018 at 2:35 AM Brian Behlendorf <bbehlendorf@...> wrote:
Who will be at DevCon in Prague in two weeks?  I'll be there but only
Thursday the 1st through Sunday morning.  Happy to meet up with anyone
there.  We are also doing a Meetup on Friday night:
https://www.meetup.com/Hyperledger-Prague/events/255766163/  Marta will
be there I believe all week.  Let me know if you'll be there.

Or in Hong Kong next week for HK Fintech week?  Or Singapore for SG
Fintech Week the 11th-14th?

Brian

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






--


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


Re: Devcon in Prague

Duncan Johnston-Watt
 

Brian

I appreciate that we are not TSC members but FWIW myself and Kai Davenport will be at SG Fintech Festival where we will be delivering a two day workshop as part of their industry events program Nov 15&16 - https://fintechfestival.sg/festival-line-up/industry/ - which we will be promoting shortly.

If you or Julian know of folk locally in SG who would benefit from this but workshop who don't have the budget please connect us and we will give them a discount code.

Best

Duncan


On Wed, Oct 24, 2018 at 2:35 AM Brian Behlendorf <bbehlendorf@...> wrote:
Who will be at DevCon in Prague in two weeks?  I'll be there but only
Thursday the 1st through Sunday morning.  Happy to meet up with anyone
there.  We are also doing a Meetup on Friday night:
https://www.meetup.com/Hyperledger-Prague/events/255766163/  Marta will
be there I believe all week.  Let me know if you'll be there.

Or in Hong Kong next week for HK Fintech week?  Or Singapore for SG
Fintech Week the 11th-14th?

Brian

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







Devcon in Prague

Brian Behlendorf
 

Who will be at DevCon in Prague in two weeks?  I'll be there but only Thursday the 1st through Sunday morning.  Happy to meet up with anyone there.  We are also doing a Meetup on Friday night: https://www.meetup.com/Hyperledger-Prague/events/255766163/  Marta will be there I believe all week.  Let me know if you'll be there.

Or in Hong Kong next week for HK Fintech week?  Or Singapore for SG Fintech Week the 11th-14th?

Brian

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


Hyperledger Iroha Quarterly Update Due #tsc-project-update - Thu, 10/25/18 #tsc-project-update #cal-reminder

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

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

When:
Thursday, 25 October 2018

Description:
The Hyperledger Iroha project update to the TSC was due October 22, 2018, and it will be presented to the TSC on October 25, 2018. Please review prior to the meeting and bring your questions.

View Event.


Hyperledger Training and Education WG Quarterly Update Due #tsc-wg-update - Thu, 10/25/18 #tsc-wg-update #cal-reminder

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

Reminder:
Hyperledger Training and Education WG Quarterly Update Due #tsc-wg-update

When:
Thursday, 25 October 2018

Description:
The Hyperledger Training and Education WG update to the TSC was due October 22, 2018, and it will be presented to the TSC on October 25, 2018. Please review prior to the meeting and bring your questions.

View Event.


Re: Montreal Hackfest / TSC Agenda / Community Health / SIGs

David Boswell
 

Chris,

Thanks for bringing up the Ambassador program.  I think activating Ambassadors to do tasks that support community health is an important piece of what we need to do going forward.

If the TSC has guidance or suggestions for how Ambassadors can help out, let's document that and then we can make that information available to Ambassadors and encourage them to take those actions.  For instance, if asking them to be moderators on chat would be helpful, let's write that up.

We just recently started a section on the Ambassador wiki where we're building out a playbook -- what are the specific actions we encourage Ambassadors to do.  Feel free to take a look through that and either update the wiki directly or send me notes and suggestions and I can add to it.


Thanks,
David

On Wed, Oct 17, 2018 at 1:12 PM, Christopher Ferris <chris.ferris@...> wrote:
It occurred to me that we do have a formal Hyperledger Ambassadors program.

Their responsibilities include (taken from the wiki):
  • Answer questions on Mail-lists, Rocketchat, Twitter, Quora, Stack Overflow, at events, etc
  • Help onboard new contributors

  • How do we help the ambassadors to help us in this regard?

    I noticed that some avatars on RC have 'moderator' tags. Can we add a tag for 'ambassador'?
    Or, maybe for this we could give ambassadors moderator tags for the main channels we want them
    to help out with?

    How might we better identify who our ambassadors are, making them more visible?

    We also talked about gamifying things. Maybe we could track people's progress on SO?
    Have some form of recognition of people who have done the most for the community?

    Chris



    On Wed, Oct 17, 2018 at 3:04 PM David Boswell <dboswell@...> wrote:
    To follow up about the community health discussions held during the Member Summit and Hackfest, Tracy, Ry and I put a report together that summarizes the main take-aways and recommended next steps.  That is at:


    For everyone who was at the event, please review, edit and update the doc to fill in or fix details.

    For anyone who wasn't at the event, I encourage you to read through this since there is really valuable feedback and ideas about how we can improve participation and the experience of contributing.

    The report is a quick read, but I'll pull out the main items to make sure the highlights are covered in this email:

    Main take-aways
    * The number of people participating in these discussions was relatively small so we’ll need to look at how to broaden interest in this topic
    * The community is overwhelming
    * The community is intimidating
    * The community is unsure how to address many of these issues

    Recommended next steps
    * Implement a pilot of a mentoring program to test ways to improve diversity
    * Improve the developer journey experience
    * Move forward with the Community Health effort

    Since the TSC agenda for tomorrow looks full, perhaps this is a good opportunity to see how far we can take a discussion asynchronously outside of a meeting.  What do people think about this feedback and the recommended next steps?

    Thanks,
    David

    On Mon, Oct 8, 2018 at 10:17 AM, Middleton, Dan <dan.middleton@...> wrote:

    # Community Health

    There were several sessions on community health.

    I don’t know if anyone was able to participate in all of them? Maybe some of the LF staff?
    It would be nice to get a report out on those if someone would like to volunteer.

    From the sessions that I participated in – and some initially unrelated discussions – I did hear reinforcement of the idea that teleconferences are bad. Asynchronous communication (e.g. email) can be more inclusive when written thoughtfully.

     

    To that end, a few weeks ago, we also discussed the need for all the maintainers and WG leads to subscribe to the TSC list so there is at least one common channel of discussion.

     

    Thumbing through the minutes I don’t see that we made a concrete action item though. Did one of the community architects already infer that action item and convey that desire to the maintainers and leads?

     

     

    # SIGs

    On a loosely related topic the board discussed the opportunities around SIGs and decided to take those on directly. Where we have sector specific groups (like Healthcare) those will now be facilitated by Hyperledger Staff and approvals managed through the Governing Board. They were not originally part of the TSC charter and going forward the board will handle that oversight.

     

    When those interest groups produce useful artifacts like requirements the TSC does want to see and benefit from those.

     

    As far as technical working groups like Architecture, Performance, and Identity, there is no change in our existing procedures. If anything we will now have more time to focus on those.

     

    To tie back in with the top of this email, a Community Health Work Group had been previously suggested. As observed earlier, community health is well within the TSC’s charter. Should that concept move forward it would continue as a TSC activity.

     

    Thanks,

    Dan




    Re: Minutes / October 18th, 2018

    Christopher B Ferris <chrisfer@...>
     

    Thanks!
     
    Cheers,

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

    ----- Original message -----
    From: Ry Jones <rjones@...>
    To: Christopher Ferris <chrisfer@...>
    Cc: Hart Montgomery <hmontgomery@...>, bob@..., tbenzies@..., tsc@...
    Subject: Re: [Hyperledger TSC] Minutes / October 18th, 2018
    Date: Thu, Oct 18, 2018 5:47 PM
     
    I'll file a ticket
     
    On Thu, Oct 18, 2018, 15:52 Christopher B Ferris <chrisfer@...> wrote:
    When we get Confluence, we can have a much sexier version. As to the mandatory login, AFAIK it isn't unless you access a non-public link. Of course, looking at the page with an incognito tab, I see that the filters themselves are visible only to logged in users (le sigh).
     
    Hey Ry/Tracy, can we get the default to be PUBLIC for new filters?
     
    I have since made everything on that page public so no login should be necessary. Thanks for raising this to my attention.
     
    Cheers,

    Christopher Ferris
    IBM Distinguished Engineer, CTO Open Technology
    IBM Digital Business Group, Open Technologies
    email: chrisfer@...
    twitter: @christo4ferris
     
     
    ----- Original message -----
    From: "Montgomery, Hart" <hmontgomery@...>
    To: "bob@..." <bob@...>, Todd Benzies <tbenzies@...>, Christopher Ferris <chrisfer@...>
    Cc: Hyperledger List <tsc@...>
    Subject: RE: [Hyperledger TSC] Minutes / October 18th, 2018
    Date: Thu, Oct 18, 2018 2:34 PM
     

    +1 to this.

     

    I have frustrated a number of business people when they have asked about future plans for Fabric and I have sent them the link to the jira.  It’s great for technical folks, but suboptimal for the business people.

     

    Thanks,

    Hart

     

    From: tsc@... [mailto:tsc@...] On Behalf Of Bob Summerwill
    Sent: Thursday, October 18, 2018 11:30 AM
    To: Todd Benzies <tbenzies@...>; Christopher Ferris <chrisfer@...>
    Cc: Hyperledger List <tsc@...>
    Subject: Re: [Hyperledger TSC] Minutes / October 18th, 2018

     

    Chris,

     

    On the JIRA Roadmap comment on your Fabric update, my own experience has been that the compulsory JIRA login is a real barrier to entry.

     

    This will just be down to the JIRA configuration which the LF has set up.  We had similar problems with comprehension of EIPs for Ethereum when we were just using GitHub issues.  It you are very comfortable with JIRA or GitHub then you are probably fine, but many other people would like something a little more human.

     

    Even just a little investment into a custom read only view onto issue tracking systems can be hugely impactful - to remove all barriers to engagement and provide a bit of "soft niceness" around our techie tools.

     

    See https://eips.ethereum.org for a really lightweight view onto the same GitHub data, but which helped immensely for EIPs.

     

    Maybe a custom roadmap view at https://fabricroadmap.hyperledger.org or whatever would make a big difference?

     

    On Thu., Oct. 18, 2018, 10:57 a.m. Todd Benzies, <tbenzies@...> wrote:

    Hyperledger Project

    Technical Steering Committee (TSC) Meeting

    October 18, 2018 (7:00am - 8:00am PT)

    via Zoom

     

    TSC Members

    Arnaud Le Hors

    Yes

    Baohua Yang

    Yes

    Binh Nguyen

    Yes

    Christopher Ferris

    Yes

    Dan Middleton

    Yes

    Hart Montgomery

    Yes

    Kelly Olson

    Yes

    Mark Wagner

    Yes

    Mic Bowman

    Yes

    Nathan George

    Yes

    Silas Davis

    Yes

     

    Resources:

    ·  Rocket.Chat:  chat.hyperledger.org (you can use your LFID to login)

    ·  Github:  www.github.com/hyperledger

    ·  Wiki:  https://wiki.hyperledger.org/

    ·  Public lists:  lists.hyperledger.org

    ·  Meetings:  wiki.hyperledger.org/community/calendar-public-meetings

     

    Event Reminders

    ·  APAC Hackfest -- week of March 4th (details coming soon)

    ·  Schedule announced for Hyperledger Global Forum, December 12-15 (Basel, Switzerland)

     

    Supply Chain proposal

    ·  Dave Cecchi provided an overview of the proposal

    ·  Are there more details on generic components being built that could be more widely shared?  Supply chain is a very general term that encompasses many thing -- what is your definition and specific set of capabilities?

    o The motivations are supply chain centric, but certainly components from this type of framework may have applicability to other market models.  Typical use cases deal with logistics, track and trace, as well as multi-party distributed supply chain business enablement. Want to solve distributed supply chain problems.

    ·  Would it be useful for Hyperledger to define a transaction format that is generic enough to be used in a wide range of environments with similar commonalities (i.e. format with sender/receiver addresses with backpointers)

    o These problems have been solved outside of blockchain -- businesses have been transacting for a while.  Looking for reusable components. As a platform, the components all need to work together.

    ·  What code currently exists?  If this was put into incubation, what would land on Day 0?  A lot seems to be centered around business process -- is supply chain as an umbrella project the best path?

    o Some code exists, but not production ready -- this is for incubation.  Code from track and trace usage linked in proposal, as well.

    o Customer, counterparty/party, product or material -- reusable components that can be assembled into an application that would tie these primitives together.

    ·  Why wouldn’t existing standards for supply chain apply?

    o Yes, the standards exists… but, why aren’t they implemented and in open source (or Hyperledger implementation) yet.

    ·  Compare Hyperledger Composer with the scope of this proposal?

    o Composer is a tool to help people get ramped into blockchain and do code generation of business considerations.

    o For this supply chain project, not code generation, but to still facilitate coding business level concerns in delivering an application.

    ·  A suggestion was made to add this into the proposal.

    ·  A suggestion was made to create a non-generic name (not “supply chain”)

    ·  A suggestion was made to have some references to existing standards, and sequencing expectations on deliverables

    ·  Questions as to whether it is limited to this vertical or more broadly encompassing

    ·  Continue discussion via chat and mailing list

     

    Quarterly project updates

    ·  Victor Hu provided the Hyperledger Caliper update

    o What is current level of communication between Caliper and PSWG?

    § For each PSWG meeting, one rep from Caliper will be there

    ·  Chris Ferris provided the Hyperledger Fabric update

    ·  Andi Gunderson provided the Hyperledger Sawtooth update

    o Is there a plan for testnet?

    § Loose plan was to get a starter testnet going where we raise nodes in different organizations, and do some basic integration testing across organizational boundaries -- then, look at more security-focused use of testnet

    o Are we still looking at testnet at a Hyperledger-level?

    § Dave Huseby is pulling together thoughts and a proposal for 2019 budget planning

    § ADD for TSC call next week

    ·  October 25th:  Hyperledger Iroha update

     

    Quarterly WG updates

    ·  No updates this week

    ·  October 25th:  Technical WG China update and Training and Education WG update

     

    --

    Todd Benzies

    Sr. Director, Program Management & Operations

    The Linux Foundation
    +1 (415) 412-0310 (m)

     

     
     

     

     

     


    Re: Project Proposal: Supply Chain

    Silas Davis
     

    I think Mic's and Shawn's references to compose situated it as such. It came up on the call when the idea of this project providing standard data types for supply chain came up, which sounds like a data modelling and language binding concern, exactly like what CML; a domain neutral (insofar as DLT is not a domain) modelling language would be just the thing in which to implement supply-chain related structures.

    On Fri, Oct 19, 2018 at 2:16 PM Dan Selman via Lists.Hyperledger.Org <dan=clause.io@...> wrote:
    I've seen Composer mentioned a couple of times in this thread: Composer is not an application, and is completely domain neutral. It is a model-based framework for *developing* applications. It allows you to model your domain using a schema language and then you benefit from declarative data validation, serialisation, query and access control.

    On Thu, Oct 18, 2018 at 2:18 PM Christopher Ferris <chris.ferris@...> wrote:
    From hyperledger.org site (and countless presentations made by staff and members alike):

    "Hyperledger is an open source collaborative effort created to advance cross-industry blockchain technologies. It is a global collaboration, hosted by The Linux Foundation, including leaders in finance, banking, IoT, supply chain, manufacturing and technology."

    (highlighting mine).

    It does not read "industry-specific solutions" for a reason. We created the organization to focus on the development of the underlying technology and leaving the space of solutions to consortia and vendors alike.

    Indy was deemed a fit because identity is an enabling technology for permissioned blockchain. It actually is somewhat of a moebius loop in that regard as it needs a blockchain to anchor its claims. I guess you could argue that we erred in deciding to incubate Indy, but at the time, we actually did follow the logic that while it was an application, it was itself a relevant technology. There is active discussion and exploration on how to integrate verifiable claims as identity in Fabric and I suspect other projects. You can't make the same case for supply-chain, food traceability, shipping, trade finance, cross-border payments, etc.

    Cheers

    Chris




    On Thu, Oct 18, 2018 at 8:50 AM Christopher Ferris <chris.ferris@...> wrote:
    Agreed, this isn't about technical merit, or even ability to deliver. It is about the scope of what we do. Blythe has basically teed this up for a board-level discussion. Mark suggested that maybe the Board and TSC jointly address this, which seems a reasonable suggestion as there are both technical and business implications.

    Chris

    On Wed, Oct 17, 2018 at 5:51 PM hmontgomery@... <hmontgomery@...> wrote:

    I don’t think the technical merit of the proposed project is in doubt.  Building an interoperable, supply chain-focused blockchain platform is certainly a worthy goal (would anyone here disagree?) and the sponsors are people who have delivered before.  If we were just judging this project on abstract technical merit, I suspect it would pass without much discussion. 

     

    However, I think it would be good to get a firm grip on what the TSC (and, more importantly, the broader Hyperledger community) thinks about the charter and how high up the application layer Hyperledger should go.  You can certainly make the case that Indy is an “application” rather than a base DLT, and I don’t think anyone here is going to suggest that Indy is inappropriate as a project.   Composer was also brought up earlier in this thread as an “application.”  The question is, as others have alluded to, where we want to draw the line. 

     

    So I think we should either

    1)      Talk about Hyperledger philosophy and the charter, because I suspect that this (rather than the technical merit) will be what is potentially a stumbling block for some folks.

    2)      Defer to the board on the philosophy and charter, and wait for them to get back to us.

     

    I’d prefer 1.  If the board is going to decide on this, it wouldn’t hurt for them to know what we think as a community, even if there isn’t broad consensus.

     

    Thanks,

    Hart

     

    From: tsc@... [mailto:tsc@...] On Behalf Of Middleton, Dan
    Sent: Wednesday, October 17, 2018 1:48 PM
    To: mark wagner <mwagner@...>; blythe@...
    Cc: vipin bharathan <vipinsun@...>; Hyperledger List <tsc@...>
    Subject: Re: [Hyperledger TSC] Project Proposal: Supply Chain

     

    Yes, I think that would be good.

    Tomorrow at the TSC meeting we’ll also hear from the other sponsors of the project. That will be a good opportunity to discuss the technology. If at all possible I’d prefer we focus our time in that meeting on those technical aspects of the specific proposal rather than the general discussion about charter.

     

    Thanks

    Dan

     

    From: <tsc@...> on behalf of mark wagner <mwagner@...>
    Date: Wednesday, October 17, 2018 at 3:38 PM
    To: "blythe@..." <blythe@...>
    Cc: vipin bharathan <vipinsun@...>, Hyperledger List <tsc@...>
    Subject: Re: [Hyperledger TSC] Project Proposal: Supply Chain

     

    How about a bit more "bottom up" discussion on the TSC list as well and then possibly a collaboration between the TSC and the board ?

     

    As has been discussed, the technology lines get blurred pretty quickly as you move up the stack. Also as Vipin mentioned, the fact that we are considering things a bit higher up the stack is, IMHO,  a good thing for Hyperledger as it means we are more comfortable with the foundation that has been laid.

     

    -mark

     

    On Wed, Oct 17, 2018 at 4:21 PM, Blythe Masters via Lists.Hyperledger.Org <blythe=digitalasset.com@...> wrote:

    All great points! 

    I don't want to impose upon the territory of the TSC, nor am I advancing a point of view.  It just seems to me this has broad implications and should be discussed at the board level because if we don't reach clear agreement on a framework for such boundary decisions the argument will come up again and again. 

    Rgds

    Blythe

    Blythe Masters
    Chief Executive Officer
    c: +1 917 880 7829
    e: blythe@... 


    On Oct 17, 2018, at 3:22 PM, vipin bharathan <vipinsun@...> wrote:

    Hi all,

     

    As the DLT stacks have the base layer implementing DLT itself (consensus, messaging, smart contract support(VMs running SCs), plus storage) and the higher layers are meant to be implementing "the application layer". This may include UIs, specific smart contracts, Identity Management etc. 

    The problem is that there is no neat separation between these layers as often happens, for example Identity management reach into deeper layers in permissioned ledgers. 

      

    So if you consider what is quoted as out of scope in Arnaud's slide (I could not find it in the link : https://www.hyperledger.org/about/charter)

     

    API Libraries and GUIs- API Libraries are certainly part of all the incubated frameworks, in the case of Indy we also have Agents/Wallets. 

    Membership Policies - Membership Service Provider as well as policy support in Fabric and in all other incubated projects.

    Specialized Consensus Layers- Pluggable consensus and different consensus layers in HL projects

    Operations Dashboard - Cello + Explorer

    Performance monitoring-Caliper

     

    All of these seem like they are in scope since we incubate projects that are putatively out of scope. If the charter written in 2016 does not match with reality, then it can be changed or at least re-evaluated. 

     

    Business modeling- Composer and in the case of the DAH platform (albeit not incubated in HL) DAML and the DAML UI is a first class part of their solution.

     

    We need usability and ease of deployment and operations support. These should be our concerns, if we expect DLT adoption to take-off.

     

    The supply chain solution if generic enough gets my support for incubation since it will have to solve an entire class of problems (including interoperability) from the application view point. 

     

    Signs of DLT maturity include focus on higher levels of the stack. This latest proposal bodes well for the future of Hyperledger. Plus the fact that we are having these debates in the open.

     

    Best,

    Vipin

     

     

     

     

    On Wed, Oct 17, 2018 at 1:09 PM Blythe Masters via Lists.Hyperledger.Org <blythe=digitalasset.com@...> wrote:

    All

    It seems to me that this has produced sufficient debate to be worthy of addressing at the Governing Board level.

    Brian - if you agree, can we please add it to the agenda for the next meeting?

    Rgds

    Blythe

    Blythe Masters
    Chief Executive Officer
    c: 
    +1 917-880-7829
    e: 
    blythe@... 

     

    On Oct 17, 2018, at 1:01 PM, Middleton, Dan <dan.middleton@...> wrote:

     

    I should note that the Governing Board has had Supply Chain on their pipeline radar since this summer. The board has not raised any scope concerns.

     

    Building on the cross-platform thoughts, this proposal does tease interaction with Indy. I think it also builds on discussions started in Amsterdam on wasm compatibility. I do think that this type of project is well suited to help us explore cross-platform questions. One component may rely on features provided by one stack and need to interact with capabilities provided by another.  

     

    --dan

     

    From: <tsc@...> on behalf of Mic Bowman <mic.bowman@...>
    Date: Wednesday, October 17, 2018 at 10:58 AM
    To: "tsc@..." <tsc@...>
    Subject: Re: [Hyperledger TSC] Project Proposal: Supply Chain

     

    Supply chain certainly feels more like a vertical application rather than an extension of platforms capabilities (e.g. composer). Where we put the bar for platform vs app is, I think, an open question & should be discussed.

     

    My interest in the supply chain comes more from a conversation with Brian in Montreal. (Grossly over-generalizing the conversation…) We were talking about how to enable some level of independence between applications and platforms. What would it take to build an app for Fabric which could be migrated to Sawtooth or Iroha at a later time (with minimal pain & suffering) or vice versa.  Supply chain, because it is an application domain I think we would all agree to be interesting, could serve as a cross-platform “demonstration” (or maybe more accurately… an application to drive interoperability requirements).

     

    --mic

     

     

    From: tsc@... [mailto:tsc@...] On Behalf Of Arnaud Le Hors
    Sent: Wednesday, October 17, 2018 7:30 AM
    To: Shawn Amundson <amundson@...>
    Cc: Middleton, Dan <dan.middleton@...>; tsc@...
    Subject: Re: [Hyperledger TSC] Project Proposal: Supply Chain

     

    Drawing boundaries between layers is always a bit challenging. What's application related to one person can often be seen as infrastructure by someone else but, for what it's worth, I'd say that supply chain is higher up the stack than what Composer provides.

    Composer is closer to the application than Fabric but totally generic in its applicability across application domains. You can use Composer to define a supply chain solution. But it is not itself specific to supply chain or any other application domain.
    --
    Arnaud  Le Hors - Senior Technical Staff Member, Web & Blockchain Open Technologies - IBM




    From:        "Shawn Amundson" <amundson@...>
    To:        Arnaud Le Hors <lehors@...>
    Cc:        "Middleton, Dan" <dan.middleton@...>, tsc@...
    Date:        10/16/2018 10:13 PM
    Subject:        Re: [Hyperledger TSC] Project Proposal: Supply Chain
    Sent by:        tsc@...





    One of the reasons we wanted to bring this as a top level project is that it had grown beyond it’s early use as an application example. In laying the groundwork for broader usage this project has become a framework/platform for building apps, it is not an application itself. Kind of similar to Composer in the stack - above low-level frameworks but below applications.

    -Shawn

    On Tue, Oct 16, 2018 at 1:30 PM Arnaud Le Hors <lehors@...> wrote:
    Hi Dan,
    Doesn't that this fall in the application layer which is outside the scope of Hyperledger?


    https://www.hyperledger.org/about/charter
    a.      create an enterprise grade, open source distributed ledger framework and code base, upon which users can build and run robust, industry-specific applications, platforms and hardware systems to support business transactions.



    --
    Arnaud  Le Hors - Senior Technical Staff Member, Web & Blockchain Open Technologies - IBM





    From:        
    "Middleton, Dan" <dan.middleton@...>
    To:        
    Nathan George <
    nathan.george@...>
    Cc:        
    "
    tsc@..." <tsc@...>
    Date:        
    10/16/2018 07:07 PM
    Subject:        
    Re: [Hyperledger TSC] Project Proposal: Supply Chain
    Sent by:        
    tsc@...





    Hi Nathan,
    Thanks, it looks like I lost a link to the code in the proposal. I’ve fixed that now (
    https://github.com/hyperledger/sawtooth-supply-chain).

    Yes, this is a coding project and not a SIG. The code did originate from sawtooth, but the common point of interoperation for components in the supply chain framework will be the contract interpreter. One of the interesting technical aspects of this code is that the contracts are written in rust in such a way that they can be deployed as native code or interpreted via WASM.
     
    Thanks,
    Dan
     

    From: 
    Nathan George <nathan.george@...>
    Date: 
    Tuesday, October 16, 2018 at 11:36 AM
    To: 
    Dan Middleton <
    dan.middleton@...>
    Cc: 
    "
    tsc@..." <tsc@...>
    Subject: 
    Re: [Hyperledger TSC] Project Proposal: Supply Chain

     
    Dan, can you elaborate where you see this relative to the SIGs vs a code project?  It is clear that this project isn't focused on only the use-cases of supply chains like some of the other interest groups, but also isn't clear from the proposal whether it is driven by a particular code base or any one framework.  What is the stance of the project in terms of dependencies?  I'm guessing it is Sawtooth-centric judging by the sponsors, but it seems that as a top-level project there are some points of clarification to be had about exactly how you view its evolution going forward.
     
    On Tue, Oct 16, 2018 at 9:58 AM Middleton, Dan <
    dan.middleton@...> wrote:
    This proposal is submitted on behalf of contributors at Cargill, Bitwise IO, and Intel:

    https://docs.google.com/document/d/1b6ES0bKUK30E2iZizy3vjVEhPn7IvsW5buDo7nFXBE0/edit?usp=sharing
     
    We propose a new project focused on supply chain, one of the most promising areas for blockchains. This project will encompass an ecosystem of technologies including some existing Hyperledger projects that harmonize to deliver useful and cohesive supply chain capabilities.
     
    I look forward to discussion at the next TSC meeting.
     
    Regards,
    Dan

     

     


    This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.


    This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.




    --

    Mark Wagner

    Senior Principal Software Engineer

    Performance and Scalability

    Red Hat, Inc



    --
    Dan Selman
    CTO, Clause Inc.
    @danielselman


    Re: Project Proposal: Supply Chain

    Dan Selman
     

    I've seen Composer mentioned a couple of times in this thread: Composer is not an application, and is completely domain neutral. It is a model-based framework for *developing* applications. It allows you to model your domain using a schema language and then you benefit from declarative data validation, serialisation, query and access control.


    On Thu, Oct 18, 2018 at 2:18 PM Christopher Ferris <chris.ferris@...> wrote:
    From hyperledger.org site (and countless presentations made by staff and members alike):

    "Hyperledger is an open source collaborative effort created to advance cross-industry blockchain technologies. It is a global collaboration, hosted by The Linux Foundation, including leaders in finance, banking, IoT, supply chain, manufacturing and technology."

    (highlighting mine).

    It does not read "industry-specific solutions" for a reason. We created the organization to focus on the development of the underlying technology and leaving the space of solutions to consortia and vendors alike.

    Indy was deemed a fit because identity is an enabling technology for permissioned blockchain. It actually is somewhat of a moebius loop in that regard as it needs a blockchain to anchor its claims. I guess you could argue that we erred in deciding to incubate Indy, but at the time, we actually did follow the logic that while it was an application, it was itself a relevant technology. There is active discussion and exploration on how to integrate verifiable claims as identity in Fabric and I suspect other projects. You can't make the same case for supply-chain, food traceability, shipping, trade finance, cross-border payments, etc.

    Cheers

    Chris




    On Thu, Oct 18, 2018 at 8:50 AM Christopher Ferris <chris.ferris@...> wrote:
    Agreed, this isn't about technical merit, or even ability to deliver. It is about the scope of what we do. Blythe has basically teed this up for a board-level discussion. Mark suggested that maybe the Board and TSC jointly address this, which seems a reasonable suggestion as there are both technical and business implications.

    Chris

    On Wed, Oct 17, 2018 at 5:51 PM hmontgomery@... <hmontgomery@...> wrote:

    I don’t think the technical merit of the proposed project is in doubt.  Building an interoperable, supply chain-focused blockchain platform is certainly a worthy goal (would anyone here disagree?) and the sponsors are people who have delivered before.  If we were just judging this project on abstract technical merit, I suspect it would pass without much discussion. 

     

    However, I think it would be good to get a firm grip on what the TSC (and, more importantly, the broader Hyperledger community) thinks about the charter and how high up the application layer Hyperledger should go.  You can certainly make the case that Indy is an “application” rather than a base DLT, and I don’t think anyone here is going to suggest that Indy is inappropriate as a project.   Composer was also brought up earlier in this thread as an “application.”  The question is, as others have alluded to, where we want to draw the line. 

     

    So I think we should either

    1)      Talk about Hyperledger philosophy and the charter, because I suspect that this (rather than the technical merit) will be what is potentially a stumbling block for some folks.

    2)      Defer to the board on the philosophy and charter, and wait for them to get back to us.

     

    I’d prefer 1.  If the board is going to decide on this, it wouldn’t hurt for them to know what we think as a community, even if there isn’t broad consensus.

     

    Thanks,

    Hart

     

    From: tsc@... [mailto:tsc@...] On Behalf Of Middleton, Dan
    Sent: Wednesday, October 17, 2018 1:48 PM
    To: mark wagner <mwagner@...>; blythe@...
    Cc: vipin bharathan <vipinsun@...>; Hyperledger List <tsc@...>
    Subject: Re: [Hyperledger TSC] Project Proposal: Supply Chain

     

    Yes, I think that would be good.

    Tomorrow at the TSC meeting we’ll also hear from the other sponsors of the project. That will be a good opportunity to discuss the technology. If at all possible I’d prefer we focus our time in that meeting on those technical aspects of the specific proposal rather than the general discussion about charter.

     

    Thanks

    Dan

     

    From: <tsc@...> on behalf of mark wagner <mwagner@...>
    Date: Wednesday, October 17, 2018 at 3:38 PM
    To: "blythe@..." <blythe@...>
    Cc: vipin bharathan <vipinsun@...>, Hyperledger List <tsc@...>
    Subject: Re: [Hyperledger TSC] Project Proposal: Supply Chain

     

    How about a bit more "bottom up" discussion on the TSC list as well and then possibly a collaboration between the TSC and the board ?

     

    As has been discussed, the technology lines get blurred pretty quickly as you move up the stack. Also as Vipin mentioned, the fact that we are considering things a bit higher up the stack is, IMHO,  a good thing for Hyperledger as it means we are more comfortable with the foundation that has been laid.

     

    -mark

     

    On Wed, Oct 17, 2018 at 4:21 PM, Blythe Masters via Lists.Hyperledger.Org <blythe=digitalasset.com@...> wrote:

    All great points! 

    I don't want to impose upon the territory of the TSC, nor am I advancing a point of view.  It just seems to me this has broad implications and should be discussed at the board level because if we don't reach clear agreement on a framework for such boundary decisions the argument will come up again and again. 

    Rgds

    Blythe

    Blythe Masters
    Chief Executive Officer
    c: +1 917 880 7829
    e: blythe@... 


    On Oct 17, 2018, at 3:22 PM, vipin bharathan <vipinsun@...> wrote:

    Hi all,

     

    As the DLT stacks have the base layer implementing DLT itself (consensus, messaging, smart contract support(VMs running SCs), plus storage) and the higher layers are meant to be implementing "the application layer". This may include UIs, specific smart contracts, Identity Management etc. 

    The problem is that there is no neat separation between these layers as often happens, for example Identity management reach into deeper layers in permissioned ledgers. 

      

    So if you consider what is quoted as out of scope in Arnaud's slide (I could not find it in the link : https://www.hyperledger.org/about/charter)

     

    API Libraries and GUIs- API Libraries are certainly part of all the incubated frameworks, in the case of Indy we also have Agents/Wallets. 

    Membership Policies - Membership Service Provider as well as policy support in Fabric and in all other incubated projects.

    Specialized Consensus Layers- Pluggable consensus and different consensus layers in HL projects

    Operations Dashboard - Cello + Explorer

    Performance monitoring-Caliper

     

    All of these seem like they are in scope since we incubate projects that are putatively out of scope. If the charter written in 2016 does not match with reality, then it can be changed or at least re-evaluated. 

     

    Business modeling- Composer and in the case of the DAH platform (albeit not incubated in HL) DAML and the DAML UI is a first class part of their solution.

     

    We need usability and ease of deployment and operations support. These should be our concerns, if we expect DLT adoption to take-off.

     

    The supply chain solution if generic enough gets my support for incubation since it will have to solve an entire class of problems (including interoperability) from the application view point. 

     

    Signs of DLT maturity include focus on higher levels of the stack. This latest proposal bodes well for the future of Hyperledger. Plus the fact that we are having these debates in the open.

     

    Best,

    Vipin

     

     

     

     

    On Wed, Oct 17, 2018 at 1:09 PM Blythe Masters via Lists.Hyperledger.Org <blythe=digitalasset.com@...> wrote:

    All

    It seems to me that this has produced sufficient debate to be worthy of addressing at the Governing Board level.

    Brian - if you agree, can we please add it to the agenda for the next meeting?

    Rgds

    Blythe

    Blythe Masters
    Chief Executive Officer
    c: 
    +1 917-880-7829
    e: 
    blythe@... 

     

    On Oct 17, 2018, at 1:01 PM, Middleton, Dan <dan.middleton@...> wrote:

     

    I should note that the Governing Board has had Supply Chain on their pipeline radar since this summer. The board has not raised any scope concerns.

     

    Building on the cross-platform thoughts, this proposal does tease interaction with Indy. I think it also builds on discussions started in Amsterdam on wasm compatibility. I do think that this type of project is well suited to help us explore cross-platform questions. One component may rely on features provided by one stack and need to interact with capabilities provided by another.  

     

    --dan

     

    From: <tsc@...> on behalf of Mic Bowman <mic.bowman@...>
    Date: Wednesday, October 17, 2018 at 10:58 AM
    To: "tsc@..." <tsc@...>
    Subject: Re: [Hyperledger TSC] Project Proposal: Supply Chain

     

    Supply chain certainly feels more like a vertical application rather than an extension of platforms capabilities (e.g. composer). Where we put the bar for platform vs app is, I think, an open question & should be discussed.

     

    My interest in the supply chain comes more from a conversation with Brian in Montreal. (Grossly over-generalizing the conversation…) We were talking about how to enable some level of independence between applications and platforms. What would it take to build an app for Fabric which could be migrated to Sawtooth or Iroha at a later time (with minimal pain & suffering) or vice versa.  Supply chain, because it is an application domain I think we would all agree to be interesting, could serve as a cross-platform “demonstration” (or maybe more accurately… an application to drive interoperability requirements).

     

    --mic

     

     

    From: tsc@... [mailto:tsc@...] On Behalf Of Arnaud Le Hors
    Sent: Wednesday, October 17, 2018 7:30 AM
    To: Shawn Amundson <amundson@...>
    Cc: Middleton, Dan <dan.middleton@...>; tsc@...
    Subject: Re: [Hyperledger TSC] Project Proposal: Supply Chain

     

    Drawing boundaries between layers is always a bit challenging. What's application related to one person can often be seen as infrastructure by someone else but, for what it's worth, I'd say that supply chain is higher up the stack than what Composer provides.

    Composer is closer to the application than Fabric but totally generic in its applicability across application domains. You can use Composer to define a supply chain solution. But it is not itself specific to supply chain or any other application domain.
    --
    Arnaud  Le Hors - Senior Technical Staff Member, Web & Blockchain Open Technologies - IBM




    From:        "Shawn Amundson" <amundson@...>
    To:        Arnaud Le Hors <lehors@...>
    Cc:        "Middleton, Dan" <dan.middleton@...>, tsc@...
    Date:        10/16/2018 10:13 PM
    Subject:        Re: [Hyperledger TSC] Project Proposal: Supply Chain
    Sent by:        tsc@...





    One of the reasons we wanted to bring this as a top level project is that it had grown beyond it’s early use as an application example. In laying the groundwork for broader usage this project has become a framework/platform for building apps, it is not an application itself. Kind of similar to Composer in the stack - above low-level frameworks but below applications.

    -Shawn

    On Tue, Oct 16, 2018 at 1:30 PM Arnaud Le Hors <lehors@...> wrote:
    Hi Dan,
    Doesn't that this fall in the application layer which is outside the scope of Hyperledger?


    https://www.hyperledger.org/about/charter
    a.      create an enterprise grade, open source distributed ledger framework and code base, upon which users can build and run robust, industry-specific applications, platforms and hardware systems to support business transactions.



    --
    Arnaud  Le Hors - Senior Technical Staff Member, Web & Blockchain Open Technologies - IBM





    From:        
    "Middleton, Dan" <dan.middleton@...>
    To:        
    Nathan George <
    nathan.george@...>
    Cc:        
    "
    tsc@..." <tsc@...>
    Date:        
    10/16/2018 07:07 PM
    Subject:        
    Re: [Hyperledger TSC] Project Proposal: Supply Chain
    Sent by:        
    tsc@...





    Hi Nathan,
    Thanks, it looks like I lost a link to the code in the proposal. I’ve fixed that now (
    https://github.com/hyperledger/sawtooth-supply-chain).

    Yes, this is a coding project and not a SIG. The code did originate from sawtooth, but the common point of interoperation for components in the supply chain framework will be the contract interpreter. One of the interesting technical aspects of this code is that the contracts are written in rust in such a way that they can be deployed as native code or interpreted via WASM.
     
    Thanks,
    Dan
     

    From: 
    Nathan George <nathan.george@...>
    Date: 
    Tuesday, October 16, 2018 at 11:36 AM
    To: 
    Dan Middleton <
    dan.middleton@...>
    Cc: 
    "
    tsc@..." <tsc@...>
    Subject: 
    Re: [Hyperledger TSC] Project Proposal: Supply Chain

     
    Dan, can you elaborate where you see this relative to the SIGs vs a code project?  It is clear that this project isn't focused on only the use-cases of supply chains like some of the other interest groups, but also isn't clear from the proposal whether it is driven by a particular code base or any one framework.  What is the stance of the project in terms of dependencies?  I'm guessing it is Sawtooth-centric judging by the sponsors, but it seems that as a top-level project there are some points of clarification to be had about exactly how you view its evolution going forward.
     
    On Tue, Oct 16, 2018 at 9:58 AM Middleton, Dan <
    dan.middleton@...> wrote:
    This proposal is submitted on behalf of contributors at Cargill, Bitwise IO, and Intel:

    https://docs.google.com/document/d/1b6ES0bKUK30E2iZizy3vjVEhPn7IvsW5buDo7nFXBE0/edit?usp=sharing
     
    We propose a new project focused on supply chain, one of the most promising areas for blockchains. This project will encompass an ecosystem of technologies including some existing Hyperledger projects that harmonize to deliver useful and cohesive supply chain capabilities.
     
    I look forward to discussion at the next TSC meeting.
     
    Regards,
    Dan

     

     


    This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.


    This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.




    --

    Mark Wagner

    Senior Principal Software Engineer

    Performance and Scalability

    Red Hat, Inc



    --
    Dan Selman
    CTO, Clause Inc.
    @danielselman


    Re: Project Proposal: Supply Chain

    Arnaud Le Hors
     

    On the point about applications driving infrastructure, I have to say the article Brian referenced brings nothing new. There was an MIT professor who gave a presentation on this very topic at a conference I spoke at over 10 years ago and it's not like our current developments within hyperledger aren't driven by application needs. Just because the applications aren't developed here doesn't mean they don't exist and don't inform how the platforms should evolve. It is certainly the case for Fabric and I assume it is the same for the other frameworks.

    I still think we're outside the scope of our charter but if we were to pursue this, it's worth noting that there actually is an existing repo that can be used to further experiment on this: namely the one referenced in the proposal: https://github.com/hyperledger/sawtooth-supply-chain

    Maybe more work could be done there to see what can be made platform independent and worthy of an independent project? This would at least help answer the question of what the project would really encompass.
    --
    Arnaud  Le Hors - Senior Technical Staff Member, Web & Blockchain Open Technologies - IBM




    From:        Silas Davis <silas@...>
    To:        Shawn Amundson <amundson@...>
    Cc:        Baohua Yang <yangbaohua@...>, "Jonathan Levi (HACERA)" <jonathan@...>, Arnaud Le Hors <lehors@...>, Blythe Masters <blythe@...>, Christopher Ferris <chris.ferris@...>, "Middleton, Dan" <dan.middleton@...>, Hart Montgomery <hmontgomery@...>, Mark Wagner <mwagner@...>, tsc@..., vipinsun@...
    Date:        10/19/2018 01:31 PM
    Subject:        Re: [Hyperledger TSC] Project Proposal: Supply Chain




    I agree wholeheartedly with the idea of applications driving infrastructure/frameworks, practice driving theory, etc as Brian describes. I also think that allowing Hyperledger to include work on 'use cases' makes sense (and already happens within individual projects, as we see in Sawtooth around supply chain already). It does seem like a good idea to avoid Hyperledger competing with its own members at the sharp end of end-product, with the disincentives to contribute that may entail. I'm sure the board can provide a decision on this and principles for judging the boundary.

    Turning to this proposal itself - I'm convinced there is merit in implementing standards from the supply chain world as open source software - and the work on Sabre, PBFT, etc that has come out of Sawtooth's supply chain work is very interesting. My issue with the proposal as it stands is I have a hard time understanding the limits of the scope of this project, and the thread that binds it together. It may be that for a supply chain insider it is more obvious, but without specific code to look at or more detail it is hard to pin down. The principle guiding this objection is that project sprawl and vagueness will lead to confused contributor base, fragmentation, and slower progress. Focused projects are often well defined by what they do not do. I have a hard time from the proposal understanding what is obviously not in scope for this project. I concede that supply chain is a broad and nebulous area of business, and so a project that supports may inherit some of these characteristics, but here are some suggestions for making the proposal more understandable and taking it to the next step:

    - Could we explicitly reference the existing standards (cited on the call) that might form the kernel of the work around which this project could form? If there are reasonably object models/types/nouns to start implementing I'd like to see that as an explicit first goal for the project.

    - Does this need to be a single project with the remit of 'supply chain'? Where there are existing code/ideas about order fulfilment, business processes (this is an cross-cutting area across more than just supply chain that I think is interesting), track and trace would they be better starting points rather than assuming supply chain is going to be a good cross-section of functionality from an engineering point of view. If it's not possible or desirable to break down some of these functionalities (which are meant to be modular) then it would be helpful to have an explanation of why they are indivisible.

    - Rather than starting a top-level green-field project (I understand there is existing code that Cargill will be kind enough to donate at some point - but we don't have that to look at now), could we look starting one or multiple labs projects to: provide a home for the OSS code, gauge engagement with the ideas, and once there is a bit of meat on the bone it will probably clearer what an good constellation of supply chain libraries might look like. It may be that we want to make supply chain a top level project comprising multiple ideas fleshed out in labs. Will we have lost anything by taking an incremental approach?

    I have no knowledge of supply chain specs, but took a look at SCOR since Chris Ferris mentioned it (see: https://docs.huihoo.com/scm/supply-chain-operations-reference-model-r11.0.pdf). It's nearly a thousand pages long, but some of the common syntax and definitions  it provides around the level-3 'Make' and 'Deliver' process areas seem like they could be a good place to start defining reusable objects.

    Finally, in answer to Brian's challenge for a weird, unmarketable, yet unreserved name for such a project, and since we have form in this department. I'd like to propose 'Hyperledger Scurry'

    Silas


    On Thu, Oct 18, 2018 at 6:29 PM Shawn Amundson <amundson@...> wrote:

    The project will certainly have a very good mechanism to capture proposals -- probably similar to the Sawtooth RFC process (which itself was derived from the Rust RFC process). The relationship between WGs and this project could potentially be via that mechanism.

    We are already well underway in this effort, with no intentions of slowing down -- we actually want a larger community to speed it up, and I think this project will help create a rally point for that community. Things like Sabre (WASM smart contracts), Pike (Sabre WASM smart permissions), PBFT (for Sawtooth Consensus Engine API), etc. are all driven by requirements related to this proposed project. To points already made about higher-level projects driving features of lower-level projects -- it's absolutely true.

    -Shawn


    On Thu, Oct 18, 2018 at 9:30 AM Baohua Yang <yangbaohua@...> wrote:
    Supply chain is a very important usage scenario for DLT. I believe the work is valuable.

    how about we have some supply chain WG first? like the PSWG, then it can cook more code&practices and propose as a project (like caliper does) later. 

    On Thu, Oct 18, 2018 at 10:03 PM Jonathan Levi (HACERA) <jonathan@...> wrote:
    Luckily we have a Governing Board ;-)

    More seriously:

    Friends, if don't start playing nice(r) with each other, just as I discussed two years ago at the Members Summit - "Community Investment as a Strategic Investment"... a lot of our/your efforts will go down the drain.

    -- Jonathan Levi

    HACERA - To Blockchain with Confidence
    https://unbounded.hacera.com- To Network with Networks

    On Thu, Oct 18, 2018, 4:54 PM Arnaud Le Hors <lehors@...> wrote:
    This is a slippery slope though. Next we'll have a payment platform because, heck, that's a pattern that is used by many/all industries?
    --
    Arnaud  Le Hors - Senior Technical Staff Member, Web & Blockchain Open Technologies - IBM





    From:        
    "Shawn Amundson" <amundson@...>
    To:        
    Christopher Ferris <chris.ferris@...>
    Cc:        
    Hart Montgomery <hmontgomery@...>, "Middleton, Dan" <dan.middleton@...>, Mark Wagner <mwagner@...>, Blythe Masters <blythe@...>, vipinsun@..., tsc@...
    Date:        
    10/18/2018 03:35 PM
    Subject:        
    Re: [Hyperledger TSC] Project Proposal: Supply Chain
    Sent by:        
    tsc@...





    The project is proposing cross-industry blockchain technologies in the form of a platform that implements common supply chain patterns/components. I don't see supply chain as industry-specific, but a set of common patterns used by several industries.

    -Shawn


    On Thu, Oct 18, 2018 at 8:18 AM Christopher Ferris <chris.ferris@...> wrote:
    From hyperledger.orgsite (and countless presentations made by staff and members alike):
    "Hyperledger is an open source collaborative effort created to advance cross-industry blockchain technologies. It is a global collaboration, hosted by The Linux Foundation, including leaders in finance, banking, IoT, supply chain, manufacturing and technology."

    (highlighting mine).

    It does not read "industry-specific solutions" for a reason. We created the organization to focus on the development of the underlying technology and leaving the space of solutions to consortia and vendors alike.

    Indy was deemed a fit because identity is an enabling technology for permissioned blockchain. It actually is somewhat of a moebius loop in that regard as it needs a blockchain to anchor its claims. I guess you could argue that we erred in deciding to incubate Indy, but at the time, we actually did follow the logic that while it was an application, it was itself a relevant technology. There is active discussion and exploration on how to integrate verifiable claims as identity in Fabric and I suspect other projects. You can't make the same case for supply-chain, food traceability, shipping, trade finance, cross-border payments, etc.

    Cheers

    Chris



    On Thu, Oct 18, 2018 at 8:50 AM Christopher Ferris <chris.ferris@...> wrote:
    Agreed, this isn't about technical merit, or even ability to deliver. It is about the scope of what we do. Blythe has basically teed this up for a board-level discussion. Mark suggested that maybe the Board and TSC jointly address this, which seems a reasonable suggestion as there are both technical and business implications.

    Chris

    On Wed, Oct 17, 2018 at 5:51 PM hmontgomery@...<hmontgomery@...> wrote:
    I don’t think the technical merit of the proposed project is in doubt.  Building an interoperable, supply chain-focused blockchain platform is certainly a worthy goal (would anyone here disagree?) and the sponsors are people who have delivered before.  If we were just judging this project on abstract technical merit, I suspect it would pass without much discussion. 

     

    However, I think it would be good to get a firm grip on what the TSC (and, more importantly, the broader Hyperledger community) thinks about the charter and how high up the application layer Hyperledger should go.  You can certainly make the case that Indy is an “application” rather than a base DLT, and I don’t think anyone here is going to suggest that Indy is inappropriate as a project.   Composer was also brought up earlier in this thread as an “application.”  The question is, as others have alluded to, where we want to draw the line. 

     

    So I think we should either

    1)      Talk about Hyperledger philosophy and the charter, because I suspect that this (rather than the technical merit) will be what is potentially a stumbling block for some folks.

    2)      Defer to the board on the philosophy and charter, and wait for them to get back to us.

     

    I’d prefer 1.  If the board is going to decide on this, it wouldn’t hurt for them to know what we think as a community, even if there isn’t broad consensus.

     

    Thanks,

    Hart

     

    From: tsc@...[mailto:tsc@...] On Behalf Of Middleton, Dan
    Sent:
    Wednesday, October 17, 2018 1:48 PM
    To:
    mark wagner <mwagner@...>; blythe@...
    Cc:
    vipin bharathan <vipinsun@...>; Hyperledger List <tsc@...>
    Subject:
    Re: [Hyperledger TSC] Project Proposal: Supply Chain

     

    Yes, I think that would be good.

    Tomorrow at the TSC meeting we’ll also hear from the other sponsors of the project. That will be a good opportunity to discuss the technology. If at all possible I’d prefer we focus our time in that meeting on those technical aspects of the specific proposal rather than the general discussion about charter.

     

    Thanks

    Dan

     

    From: <tsc@...> on behalf of mark wagner <mwagner@...>
    Date:
    Wednesday, October 17, 2018 at 3:38 PM
    To:
    "blythe@..." <blythe@...>
    Cc:
    vipin bharathan <vipinsun@...>, Hyperledger List <tsc@...>
    Subject:
    Re: [Hyperledger TSC] Project Proposal: Supply Chain

     

    How about a bit more "bottom up" discussion on the TSC list as well and then possibly a collaboration between the TSC and the board ?

     

    As has been discussed, the technology lines get blurred pretty quickly as you move up the stack. Also as Vipin mentioned, the fact that we are considering things a bit higher up the stack is, IMHO,  a good thing for Hyperledger as it means we are more comfortable with the foundation that has been laid.

     

    -mark

     

    On Wed, Oct 17, 2018 at 4:21 PM, Blythe Masters via Lists.Hyperledger.Org<blythe=digitalasset.com@...> wrote:
    All great points! 

    I don't want to impose upon the territory of the TSC, nor am I advancing a point of view.  It just seems to me this has broad implications and should be discussed at the board level because if we don't reach clear agreement on a framework for such boundary decisions the argument will come up again and again. 

    Rgds

    Blythe

    Blythe Masters
    Chief Executive Officer
    c:
     +1 917 880 7829
    e:
     blythe@... 

    Digital Asset Holdings, LLC
    96 Spring Street, 8th Floor
    New York, NY 10012, USA
    digitalasset.com


    On Oct 17, 2018, at 3:22 PM, vipin bharathan <vipinsun@...> wrote:

    Hi all,

     

    As the DLT stacks have the base layer implementing DLT itself (consensus, messaging, smart contract support(VMs running SCs), plus storage) and the higher layers are meant to be implementing "the application layer". This may include UIs, specific smart contracts, Identity Management etc. 

    The problem is that there is no neat separation between these layers as often happens, for example Identity management reach into deeper layers in permissioned ledgers. 

      

    So if you consider what is quoted as out of scope in Arnaud's slide (I could not find it in the link : https://www.hyperledger.org/about/charter)

     

    API Libraries and GUIs- API Libraries are certainly part of all the incubated frameworks, in the case of Indy we also have Agents/Wallets. 

    Membership Policies - Membership Service Provider as well as policy support in Fabric and in all other incubated projects.

    Specialized Consensus Layers- Pluggable consensus and different consensus layers in HL projects

    Operations Dashboard - Cello + Explorer

    Performance monitoring-Caliper

     

    All of these seem like they are in scope since we incubate projects that are putatively out of scope. If the charter written in 2016 does not match with reality, then it can be changed or at least re-evaluated. 

     

    Business modeling- Composer and in the case of the DAH platform (albeit not incubated in HL) DAML and the DAML UI is a first class part of their solution.

     

    We need usability and ease of deployment and operations support. These should be our concerns, if we expect DLT adoption to take-off.

     

    The supply chain solution if generic enough gets my support for incubation since it will have to solve an entire class of problems (including interoperability) from the application view point. 

     

    Signs of DLT maturity include focus on higher levels of the stack. This latest proposal bodes well for the future of Hyperledger. Plus the fact that we are having these debates in the open.

     

    Best,

    Vipin

     

     

     

     

    On Wed, Oct 17, 2018 at 1:09 PM Blythe Masters via Lists.Hyperledger.Org<blythe=digitalasset.com@...> wrote:
    All

    It seems to me that this has produced sufficient debate to be worthy of addressing at the Governing Board level.

    Brian - if you agree, can we please add it to the agenda for the next meeting?

    Rgds

    Blythe

    Blythe Masters
    Chief Executive Officer
    c:
     
    +1 917-880-7829
    e:
     
    blythe@... 

    Digital Asset Holdings, LLC
    96 Spring Street, 7th Floor
    New York, NY 10012, USA
    digitalasset.com

     

    On Oct 17, 2018, at 1:01 PM, Middleton, Dan <dan.middleton@...> wrote:

     

    I should note that the Governing Board has had Supply Chain on their pipeline radar since this summer. The board has not raised any scope concerns.

     

    Building on the cross-platform thoughts, this proposal does tease interaction with Indy. I think it also builds on discussions started in Amsterdam on wasm compatibility. I do think that this type of project is well suited to help us explore cross-platform questions. One component may rely on features provided by one stack and need to interact with capabilities provided by another.  

     

    --dan

     

    From: <tsc@...> on behalf of Mic Bowman <mic.bowman@...>
    Date: 
    Wednesday, October 17, 2018 at 10:58 AM
    To: 
    "
    tsc@..." <tsc@...>
    Subject: 
    Re: [Hyperledger TSC] Project Proposal: Supply Chain

     

    Supply chain certainly feels more like a vertical application rather than an extension of platforms capabilities (e.g. composer). Where we put the bar for platform vs app is, I think, an open question & should be discussed.

     

    My interest in the supply chain comes more from a conversation with Brian in Montreal. (Grossly over-generalizing the conversation…) We were talking about how to enable some level of independence between applications and platforms. What would it take to build an app for Fabric which could be migrated to Sawtooth or Iroha at a later time (with minimal pain & suffering) or vice versa.  Supply chain, because it is an application domain I think we would all agree to be interesting, could serve as a cross-platform “demonstration” (or maybe more accurately… an application to drive interoperability requirements).

     

    --mic

     

     

    From: tsc@... [mailto:tsc@...On Behalf Of Arnaud Le Hors
    Sent:
     Wednesday, October 17, 2018 7:30 AM
    To:
     Shawn Amundson <amundson@...>
    Cc:
     Middleton, Dan <dan.middleton@...>; tsc@...
    Subject:
     Re: [Hyperledger TSC] Project Proposal: Supply Chain

     

    Drawing boundaries between layers is always a bit challenging. What's application related to one person can often be seen as infrastructure by someone else but, for what it's worth, I'd say that supply chain is higher up the stack than what Composer provides.

    Composer is closer to the application than Fabric but totally generic in its applicability across application domains. You can use Composer to define a supply chain solution. But it is not itself specific to supply chain or any other application domain.
    --
    Arnaud  Le Hors - Senior Technical Staff Member, Web & Blockchain Open Technologies - IBM





    From:        
    "Shawn Amundson" <amundson@...>
    To:        
    Arnaud Le Hors <lehors@...>
    Cc:        
    "Middleton, Dan" <dan.middleton@...>, tsc@...
    Date:        
    10/16/2018 10:13 PM
    Subject:        
    Re: [Hyperledger TSC] Project Proposal: Supply Chain
    Sent by:        
    tsc@...





    One of the reasons we wanted to bring this as a top level project is that it had grown beyond it’s early use as an application example. In laying the groundwork for broader usage this project has become a framework/platform for building apps, it is not an application itself. Kind of similar to Composer in the stack - above low-level frameworks but below applications.

    -Shawn

    On Tue, Oct 16, 2018 at 1:30 PM Arnaud Le Hors <
    lehors@...> wrote:
    Hi Dan,
    Doesn't that this fall in the application layer which is outside the scope of Hyperledger?


    https://www.hyperledger.org/about/charter
    a.      create an enterprise grade, open source distributed ledger framework and code base, upon which users can build and run robust, industry-specific applications, platforms and hardware systems to support business transactions.




    --
    Arnaud  Le Hors - Senior Technical Staff Member, Web & Blockchain Open Technologies - IBM





    From:        
    "Middleton, Dan" <dan.middleton@...>
    To:        
    Nathan George <nathan.george@...>
    Cc:        
    "tsc@..." <tsc@...>
    Date:        
    10/16/2018 07:07 PM
    Subject:        
    Re: [Hyperledger TSC] Project Proposal: Supply Chain
    Sent by:        
    tsc@...





    Hi Nathan,
    Thanks, it looks like I lost a link to the code in the proposal. I’ve fixed that now (https://github.com/hyperledger/sawtooth-supply-chain).

    Yes, this is a coding project and not a SIG. The code did originate from sawtooth, but the common point of interoperation for components in the supply chain framework will be the contract interpreter. One of the interesting technical aspects of this code is that the contracts are written in rust in such a way that they can be deployed as native code or interpreted via WASM.
     
    Thanks,
    Dan
     
    From: 
    Nathan George <nathan.george@...>
    Date: 
    Tuesday, October 16, 2018 at 11:36 AM
    To: 
    Dan Middleton <dan.middleton@...>
    Cc: 
    "tsc@..." <tsc@...>
    Subject: 
    Re: [Hyperledger TSC] Project Proposal: Supply Chain
     
    Dan, can you elaborate where you see this relative to the SIGs vs a code project?  It is clear that this project isn't focused on only the use-cases of supply chains like some of the other interest groups, but also isn't clear from the proposal whether it is driven by a particular code base or any one framework.  What is the stance of the project in terms of dependencies?  I'm guessing it is Sawtooth-centric judging by the sponsors, but it seems that as a top-level project there are some points of clarification to be had about exactly how you view its evolution going forward.
     
    On Tue, Oct 16, 2018 at 9:58 AM Middleton, Dan <dan.middleton@...> wrote:
    This proposal is submitted on behalf of contributors at Cargill, Bitwise IO, and Intel:
    https://docs.google.com/document/d/1b6ES0bKUK30E2iZizy3vjVEhPn7IvsW5buDo7nFXBE0/edit?usp=sharing
     
    We propose a new project focused on supply chain, one of the most promising areas for blockchains. This project will encompass an ecosystem of technologies including some existing Hyperledger projects that harmonize to deliver useful and cohesive supply chain capabilities.
     
    I look forward to discussion at the next TSC meeting.
     
    Regards,
    Dan

     

     


    This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at 
    http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.


    This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at 
    http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.




    --

    Mark Wagner

    Senior Principal Software Engineer

    Performance and Scalability

    Red Hat, Inc





    --
    Best wishes!

    Baohua Yang





    Re: Project Proposal: Supply Chain

    Silas Davis
     

    I agree wholeheartedly with the idea of applications driving infrastructure/frameworks, practice driving theory, etc as Brian describes. I also think that allowing Hyperledger to include work on 'use cases' makes sense (and already happens within individual projects, as we see in Sawtooth around supply chain already). It does seem like a good idea to avoid Hyperledger competing with its own members at the sharp end of end-product, with the disincentives to contribute that may entail. I'm sure the board can provide a decision on this and principles for judging the boundary.

    Turning to this proposal itself - I'm convinced there is merit in implementing standards from the supply chain world as open source software - and the work on Sabre, PBFT, etc that has come out of Sawtooth's supply chain work is very interesting. My issue with the proposal as it stands is I have a hard time understanding the limits of the scope of this project, and the thread that binds it together. It may be that for a supply chain insider it is more obvious, but without specific code to look at or more detail it is hard to pin down. The principle guiding this objection is that project sprawl and vagueness will lead to confused contributor base, fragmentation, and slower progress. Focused projects are often well defined by what they do not do. I have a hard time from the proposal understanding what is obviously not in scope for this project. I concede that supply chain is a broad and nebulous area of business, and so a project that supports may inherit some of these characteristics, but here are some suggestions for making the proposal more understandable and taking it to the next step:

    - Could we explicitly reference the existing standards (cited on the call) that might form the kernel of the work around which this project could form? If there are reasonably object models/types/nouns to start implementing I'd like to see that as an explicit first goal for the project.

    - Does this need to be a single project with the remit of 'supply chain'? Where there are existing code/ideas about order fulfilment, business processes (this is an cross-cutting area across more than just supply chain that I think is interesting), track and trace would they be better starting points rather than assuming supply chain is going to be a good cross-section of functionality from an engineering point of view. If it's not possible or desirable to break down some of these functionalities (which are meant to be modular) then it would be helpful to have an explanation of why they are indivisible.

    - Rather than starting a top-level green-field project (I understand there is existing code that Cargill will be kind enough to donate at some point - but we don't have that to look at now), could we look starting one or multiple labs projects to: provide a home for the OSS code, gauge engagement with the ideas, and once there is a bit of meat on the bone it will probably clearer what an good constellation of supply chain libraries might look like. It may be that we want to make supply chain a top level project comprising multiple ideas fleshed out in labs. Will we have lost anything by taking an incremental approach?

    I have no knowledge of supply chain specs, but took a look at SCOR since Chris Ferris mentioned it (see: https://docs.huihoo.com/scm/supply-chain-operations-reference-model-r11.0.pdf). It's nearly a thousand pages long, but some of the common syntax and definitions  it provides around the level-3 'Make' and 'Deliver' process areas seem like they could be a good place to start defining reusable objects.

    Finally, in answer to Brian's challenge for a weird, unmarketable, yet unreserved name for such a project, and since we have form in this department. I'd like to propose 'Hyperledger Scurry'

    Silas


    On Thu, Oct 18, 2018 at 6:29 PM Shawn Amundson <amundson@...> wrote:

    The project will certainly have a very good mechanism to capture proposals -- probably similar to the Sawtooth RFC process (which itself was derived from the Rust RFC process). The relationship between WGs and this project could potentially be via that mechanism.

    We are already well underway in this effort, with no intentions of slowing down -- we actually want a larger community to speed it up, and I think this project will help create a rally point for that community. Things like Sabre (WASM smart contracts), Pike (Sabre WASM smart permissions), PBFT (for Sawtooth Consensus Engine API), etc. are all driven by requirements related to this proposed project. To points already made about higher-level projects driving features of lower-level projects -- it's absolutely true.

    -Shawn


    On Thu, Oct 18, 2018 at 9:30 AM Baohua Yang <yangbaohua@...> wrote:
    Supply chain is a very important usage scenario for DLT. I believe the work is valuable.

    how about we have some supply chain WG first? like the PSWG, then it can cook more code&practices and propose as a project (like caliper does) later. 

    On Thu, Oct 18, 2018 at 10:03 PM Jonathan Levi (HACERA) <jonathan@...> wrote:
    Luckily we have a Governing Board ;-)

    More seriously:

    Friends, if don't start playing nice(r) with each other, just as I discussed two years ago at the Members Summit - "Community Investment as a Strategic Investment"... a lot of our/your efforts will go down the drain.

    -- Jonathan Levi

    HACERA - To Blockchain with Confidence
    https://unbounded.hacera.com - To Network with Networks

    On Thu, Oct 18, 2018, 4:54 PM Arnaud Le Hors <lehors@...> wrote:
    This is a slippery slope though. Next we'll have a payment platform because, heck, that's a pattern that is used by many/all industries?
    --
    Arnaud  Le Hors - Senior Technical Staff Member, Web & Blockchain Open Technologies - IBM




    From:        "Shawn Amundson" <amundson@...>
    To:        Christopher Ferris <chris.ferris@...>
    Cc:        Hart Montgomery <hmontgomery@...>, "Middleton, Dan" <dan.middleton@...>, Mark Wagner <mwagner@...>, Blythe Masters <blythe@...>, vipinsun@..., tsc@...
    Date:        10/18/2018 03:35 PM
    Subject:        Re: [Hyperledger TSC] Project Proposal: Supply Chain
    Sent by:        tsc@...





    The project is proposing cross-industry blockchain technologies in the form of a platform that implements common supply chain patterns/components. I don't see supply chain as industry-specific, but a set of common patterns used by several industries.

    -Shawn


    On Thu, Oct 18, 2018 at 8:18 AM Christopher Ferris <chris.ferris@...> wrote:
    From hyperledger.orgsite (and countless presentations made by staff and members alike):

    "Hyperledger is an open source collaborative effort created to advance cross-industry blockchain technologies. It is a global collaboration, hosted by The Linux Foundation, including leaders in finance, banking, IoT, supply chain, manufacturing and technology."

    (highlighting mine).

    It does not read "industry-specific solutions" for a reason. We created the organization to focus on the development of the underlying technology and leaving the space of solutions to consortia and vendors alike.

    Indy was deemed a fit because identity is an enabling technology for permissioned blockchain. It actually is somewhat of a moebius loop in that regard as it needs a blockchain to anchor its claims. I guess you could argue that we erred in deciding to incubate Indy, but at the time, we actually did follow the logic that while it was an application, it was itself a relevant technology. There is active discussion and exploration on how to integrate verifiable claims as identity in Fabric and I suspect other projects. You can't make the same case for supply-chain, food traceability, shipping, trade finance, cross-border payments, etc.

    Cheers

    Chris



    On Thu, Oct 18, 2018 at 8:50 AM Christopher Ferris <chris.ferris@...> wrote:
    Agreed, this isn't about technical merit, or even ability to deliver. It is about the scope of what we do. Blythe has basically teed this up for a board-level discussion. Mark suggested that maybe the Board and TSC jointly address this, which seems a reasonable suggestion as there are both technical and business implications.

    Chris

    On Wed, Oct 17, 2018 at 5:51 PM hmontgomery@...<hmontgomery@...> wrote:
    I don’t think the technical merit of the proposed project is in doubt.  Building an interoperable, supply chain-focused blockchain platform is certainly a worthy goal (would anyone here disagree?) and the sponsors are people who have delivered before.  If we were just judging this project on abstract technical merit, I suspect it would pass without much discussion. 

     

    However, I think it would be good to get a firm grip on what the TSC (and, more importantly, the broader Hyperledger community) thinks about the charter and how high up the application layer Hyperledger should go.  You can certainly make the case that Indy is an “application” rather than a base DLT, and I don’t think anyone here is going to suggest that Indy is inappropriate as a project.   Composer was also brought up earlier in this thread as an “application.”  The question is, as others have alluded to, where we want to draw the line. 

     

    So I think we should either

    1)      Talk about Hyperledger philosophy and the charter, because I suspect that this (rather than the technical merit) will be what is potentially a stumbling block for some folks.

    2)      Defer to the board on the philosophy and charter, and wait for them to get back to us.

     

    I’d prefer 1.  If the board is going to decide on this, it wouldn’t hurt for them to know what we think as a community, even if there isn’t broad consensus.

     

    Thanks,

    Hart

     

    From: tsc@...[mailto:tsc@...] On Behalf Of Middleton, Dan
    Sent:
    Wednesday, October 17, 2018 1:48 PM
    To:
    mark wagner <mwagner@...>; blythe@...
    Cc:
    vipin bharathan <vipinsun@...>; Hyperledger List <tsc@...>
    Subject:
    Re: [Hyperledger TSC] Project Proposal: Supply Chain

     

    Yes, I think that would be good.

    Tomorrow at the TSC meeting we’ll also hear from the other sponsors of the project. That will be a good opportunity to discuss the technology. If at all possible I’d prefer we focus our time in that meeting on those technical aspects of the specific proposal rather than the general discussion about charter.

     

    Thanks

    Dan

     

    From: <tsc@...> on behalf of mark wagner <mwagner@...>
    Date:
    Wednesday, October 17, 2018 at 3:38 PM
    To:
    "blythe@..." <blythe@...>
    Cc:
    vipin bharathan <vipinsun@...>, Hyperledger List <tsc@...>
    Subject:
    Re: [Hyperledger TSC] Project Proposal: Supply Chain

     

    How about a bit more "bottom up" discussion on the TSC list as well and then possibly a collaboration between the TSC and the board ?

     

    As has been discussed, the technology lines get blurred pretty quickly as you move up the stack. Also as Vipin mentioned, the fact that we are considering things a bit higher up the stack is, IMHO,  a good thing for Hyperledger as it means we are more comfortable with the foundation that has been laid.

     

    -mark

     

    On Wed, Oct 17, 2018 at 4:21 PM, Blythe Masters via Lists.Hyperledger.Org<blythe=digitalasset.com@...> wrote:
    All great points! 

    I don't want to impose upon the territory of the TSC, nor am I advancing a point of view.  It just seems to me this has broad implications and should be discussed at the board level because if we don't reach clear agreement on a framework for such boundary decisions the argument will come up again and again. 

    Rgds

    Blythe

    Blythe Masters
    Chief Executive Officer
    c:
     +1 917 880 7829
    e:
     blythe@... 

    Digital Asset Holdings, LLC
    96 Spring Street, 8th Floor
    New York, NY 10012, USA
    digitalasset.com


    On Oct 17, 2018, at 3:22 PM, vipin bharathan <vipinsun@...> wrote:

    Hi all,

     

    As the DLT stacks have the base layer implementing DLT itself (consensus, messaging, smart contract support(VMs running SCs), plus storage) and the higher layers are meant to be implementing "the application layer". This may include UIs, specific smart contracts, Identity Management etc. 

    The problem is that there is no neat separation between these layers as often happens, for example Identity management reach into deeper layers in permissioned ledgers. 

      

    So if you consider what is quoted as out of scope in Arnaud's slide (I could not find it in the link : https://www.hyperledger.org/about/charter)

     

    API Libraries and GUIs- API Libraries are certainly part of all the incubated frameworks, in the case of Indy we also have Agents/Wallets. 

    Membership Policies - Membership Service Provider as well as policy support in Fabric and in all other incubated projects.

    Specialized Consensus Layers- Pluggable consensus and different consensus layers in HL projects

    Operations Dashboard - Cello + Explorer

    Performance monitoring-Caliper

     

    All of these seem like they are in scope since we incubate projects that are putatively out of scope. If the charter written in 2016 does not match with reality, then it can be changed or at least re-evaluated. 

     

    Business modeling- Composer and in the case of the DAH platform (albeit not incubated in HL) DAML and the DAML UI is a first class part of their solution.

     

    We need usability and ease of deployment and operations support. These should be our concerns, if we expect DLT adoption to take-off.

     

    The supply chain solution if generic enough gets my support for incubation since it will have to solve an entire class of problems (including interoperability) from the application view point. 

     

    Signs of DLT maturity include focus on higher levels of the stack. This latest proposal bodes well for the future of Hyperledger. Plus the fact that we are having these debates in the open.

     

    Best,

    Vipin

     

     

     

     

    On Wed, Oct 17, 2018 at 1:09 PM Blythe Masters via Lists.Hyperledger.Org<blythe=digitalasset.com@...> wrote:
    All

    It seems to me that this has produced sufficient debate to be worthy of addressing at the Governing Board level.

    Brian - if you agree, can we please add it to the agenda for the next meeting?

    Rgds

    Blythe

    Blythe Masters
    Chief Executive Officer
    c:
     
    +1 917-880-7829
    e:
     
    blythe@... 

    Digital Asset Holdings, LLC
    96 Spring Street, 7th Floor
    New York, NY 10012, USA
    digitalasset.com

     

    On Oct 17, 2018, at 1:01 PM, Middleton, Dan <dan.middleton@...> wrote:

     

    I should note that the Governing Board has had Supply Chain on their pipeline radar since this summer. The board has not raised any scope concerns.

     

    Building on the cross-platform thoughts, this proposal does tease interaction with Indy. I think it also builds on discussions started in Amsterdam on wasm compatibility. I do think that this type of project is well suited to help us explore cross-platform questions. One component may rely on features provided by one stack and need to interact with capabilities provided by another.  

     

    --dan

     

    From: <tsc@...> on behalf of Mic Bowman <mic.bowman@...>
    Date: 
    Wednesday, October 17, 2018 at 10:58 AM
    To: 
    "
    tsc@..." <tsc@...>
    Subject: 
    Re: [Hyperledger TSC] Project Proposal: Supply Chain

     

    Supply chain certainly feels more like a vertical application rather than an extension of platforms capabilities (e.g. composer). Where we put the bar for platform vs app is, I think, an open question & should be discussed.

     

    My interest in the supply chain comes more from a conversation with Brian in Montreal. (Grossly over-generalizing the conversation…) We were talking about how to enable some level of independence between applications and platforms. What would it take to build an app for Fabric which could be migrated to Sawtooth or Iroha at a later time (with minimal pain & suffering) or vice versa.  Supply chain, because it is an application domain I think we would all agree to be interesting, could serve as a cross-platform “demonstration” (or maybe more accurately… an application to drive interoperability requirements).

     

    --mic

     

     

    From: tsc@... [mailto:tsc@...On Behalf Of Arnaud Le Hors
    Sent:
     Wednesday, October 17, 2018 7:30 AM
    To:
     Shawn Amundson <amundson@...>
    Cc:
     Middleton, Dan <dan.middleton@...>; tsc@...
    Subject:
     Re: [Hyperledger TSC] Project Proposal: Supply Chain

     

    Drawing boundaries between layers is always a bit challenging. What's application related to one person can often be seen as infrastructure by someone else but, for what it's worth, I'd say that supply chain is higher up the stack than what Composer provides.

    Composer is closer to the application than Fabric but totally generic in its applicability across application domains. You can use Composer to define a supply chain solution. But it is not itself specific to supply chain or any other application domain.
    --
    Arnaud  Le Hors - Senior Technical Staff Member, Web & Blockchain Open Technologies - IBM





    From:        
    "Shawn Amundson" <amundson@...>
    To:        
    Arnaud Le Hors <lehors@...>
    Cc:        
    "Middleton, Dan" <dan.middleton@...>, tsc@...
    Date:        
    10/16/2018 10:13 PM
    Subject:        
    Re: [Hyperledger TSC] Project Proposal: Supply Chain
    Sent by:        
    tsc@...





    One of the reasons we wanted to bring this as a top level project is that it had grown beyond it’s early use as an application example. In laying the groundwork for broader usage this project has become a framework/platform for building apps, it is not an application itself. Kind of similar to Composer in the stack - above low-level frameworks but below applications.

    -Shawn

    On Tue, Oct 16, 2018 at 1:30 PM Arnaud Le Hors <
    lehors@...> wrote:
    Hi Dan,
    Doesn't that this fall in the application layer which is outside the scope of Hyperledger?


    https://www.hyperledger.org/about/charter
    a.      create an enterprise grade, open source distributed ledger framework and code base, upon which users can build and run robust, industry-specific applications, platforms and hardware systems to support business transactions.



    --
    Arnaud  Le Hors - Senior Technical Staff Member, Web & Blockchain Open Technologies - IBM





    From:        
    "Middleton, Dan" <dan.middleton@...>
    To:        
    Nathan George <nathan.george@...>
    Cc:        
    "tsc@..." <tsc@...>
    Date:        
    10/16/2018 07:07 PM
    Subject:        
    Re: [Hyperledger TSC] Project Proposal: Supply Chain
    Sent by:        
    tsc@...





    Hi Nathan,
    Thanks, it looks like I lost a link to the code in the proposal. I’ve fixed that now (https://github.com/hyperledger/sawtooth-supply-chain).

    Yes, this is a coding project and not a SIG. The code did originate from sawtooth, but the common point of interoperation for components in the supply chain framework will be the contract interpreter. One of the interesting technical aspects of this code is that the contracts are written in rust in such a way that they can be deployed as native code or interpreted via WASM.
     
    Thanks,
    Dan
     
    From: 
    Nathan George <nathan.george@...>
    Date: 
    Tuesday, October 16, 2018 at 11:36 AM
    To: 
    Dan Middleton <dan.middleton@...>
    Cc: 
    "tsc@..." <tsc@...>
    Subject: 
    Re: [Hyperledger TSC] Project Proposal: Supply Chain
     
    Dan, can you elaborate where you see this relative to the SIGs vs a code project?  It is clear that this project isn't focused on only the use-cases of supply chains like some of the other interest groups, but also isn't clear from the proposal whether it is driven by a particular code base or any one framework.  What is the stance of the project in terms of dependencies?  I'm guessing it is Sawtooth-centric judging by the sponsors, but it seems that as a top-level project there are some points of clarification to be had about exactly how you view its evolution going forward.
     
    On Tue, Oct 16, 2018 at 9:58 AM Middleton, Dan <dan.middleton@...> wrote:
    This proposal is submitted on behalf of contributors at Cargill, Bitwise IO, and Intel:
    https://docs.google.com/document/d/1b6ES0bKUK30E2iZizy3vjVEhPn7IvsW5buDo7nFXBE0/edit?usp=sharing
     
    We propose a new project focused on supply chain, one of the most promising areas for blockchains. This project will encompass an ecosystem of technologies including some existing Hyperledger projects that harmonize to deliver useful and cohesive supply chain capabilities.
     
    I look forward to discussion at the next TSC meeting.
     
    Regards,
    Dan

     

     


    This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at 
    http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.


    This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at 
    http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.




    --

    Mark Wagner

    Senior Principal Software Engineer

    Performance and Scalability

    Red Hat, Inc






    --
    Best wishes!

    Baohua Yang


    Re: Minutes / October 18th, 2018

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

    [chair hat off; sawtooth hat on]

    There’s two issues from the Sawtooth update that we didn’t have time to discuss but I would appreciate assistance with:

     

    A little hand holding from a community architect might help us get this over the line:

    §  Porting build from Intel provided servers to LF/HL. No change.

     

     

    Food for thought for the community health discussions…

    §  As the community grows communication becomes a risk. We’ve dropped a sprint planning call and there is currently no single meeting that gathers all maintainers.

    We have a geographically diverse contributor pool. Keeping everyone in healthy communication is tough. Email is low bandwidth, meetings are never convenient, and chat scrolls by / still closely aligned with time zones. Subteams on different repos / subprojects add another dimension.

     

    Thanks,

    Dan

     

    From: <tsc@...> on behalf of greg m <greg_not_so@...>
    Date: Thursday, October 18, 2018 at 4:35 PM
    To: "hmontgomery@..." <hmontgomery@...>, "bob@..." <bob@...>, Todd Benzies <tbenzies@...>, Christopher Ferris <chrisfer@...>
    Cc: Hyperledger List <tsc@...>
    Subject: Re: [Hyperledger TSC] Minutes / October 18th, 2018

     

    I think Jira is great for business especially if business needs to better understand what open source means and how to use it. Business doesn't need to log into a command line to do anything in order to see the JIRA changes. If they expected a free solution that would print cryptocurrency with one click of a button then they are in for a rude surprise. There are hundreds of hours spent every day to maintain and contribute software changes and many business cases to be made on how to make blockchain easier and more consumable for anyone who does not want to stay too close to a computer screen for too long. composer was moving in that direction, but for whatever reason the biggest contributor didn't want to be the sole contributor to that project. 

     

    hopefully, i haven't misspoken on behalf of anyone's business but mine only.

     

    Thank you, greg misiorek

    Member

    BIS LLC


    From: tsc@... <tsc@...> on behalf of hmontgomery@... <hmontgomery@...>
    Sent: Thursday, October 18, 2018 2:34 PM
    To: bob@...; Todd Benzies; Christopher Ferris
    Cc: Hyperledger List
    Subject: Re: [Hyperledger TSC] Minutes / October 18th, 2018

     

    +1 to this.

     

    I have frustrated a number of business people when they have asked about future plans for Fabric and I have sent them the link to the jira.  It’s great for technical folks, but suboptimal for the business people.

     

    Thanks,

    Hart

     

    From: tsc@... [mailto:tsc@...] On Behalf Of Bob Summerwill
    Sent: Thursday, October 18, 2018 11:30 AM
    To: Todd Benzies <tbenzies@...>; Christopher Ferris <chrisfer@...>
    Cc: Hyperledger List <tsc@...>
    Subject: Re: [Hyperledger TSC] Minutes / October 18th, 2018

     

    Chris,

     

    On the JIRA Roadmap comment on your Fabric update, my own experience has been that the compulsory JIRA login is a real barrier to entry.

     

    This will just be down to the JIRA configuration which the LF has set up.  We had similar problems with comprehension of EIPs for Ethereum when we were just using GitHub issues.  It you are very comfortable with JIRA or GitHub then you are probably fine, but many other people would like something a little more human.

     

    Even just a little investment into a custom read only view onto issue tracking systems can be hugely impactful - to remove all barriers to engagement and provide a bit of "soft niceness" around our techie tools.

     

    See https://eips.ethereum.org for a really lightweight view onto the same GitHub data, but which helped immensely for EIPs.

     

    Maybe a custom roadmap view at https://fabricroadmap.hyperledger.org or whatever would make a big difference?

     

    On Thu., Oct. 18, 2018, 10:57 a.m. Todd Benzies, <tbenzies@...> wrote:

    Hyperledger Project

    Technical Steering Committee (TSC) Meeting

    October 18, 2018 (7:00am - 8:00am PT)

    via Zoom

     

    TSC Members

    Arnaud Le Hors

    Yes

    Baohua Yang

    Yes

    Binh Nguyen

    Yes

    Christopher Ferris

    Yes

    Dan Middleton

    Yes

    Hart Montgomery

    Yes

    Kelly Olson

    Yes

    Mark Wagner

    Yes

    Mic Bowman

    Yes

    Nathan George

    Yes

    Silas Davis

    Yes

     

    Resources:

    ·  Rocket.Chat:  chat.hyperledger.org (you can use your LFID to login)

    ·  Github:  www.github.com/hyperledger

    ·  Wiki:  https://wiki.hyperledger.org/

    ·  Public lists:  lists.hyperledger.org

    ·  Meetings:  wiki.hyperledger.org/community/calendar-public-meetings

     

    Event Reminders

    ·  APAC Hackfest -- week of March 4th (details coming soon)

    ·  Schedule announced for Hyperledger Global Forum, December 12-15 (Basel, Switzerland)

     

    Supply Chain proposal

    ·  Dave Cecchi provided an overview of the proposal

    ·  Are there more details on generic components being built that could be more widely shared?  Supply chain is a very general term that encompasses many thing -- what is your definition and specific set of capabilities?

    o The motivations are supply chain centric, but certainly components from this type of framework may have applicability to other market models.  Typical use cases deal with logistics, track and trace, as well as multi-party distributed supply chain business enablement. Want to solve distributed supply chain problems.

    ·  Would it be useful for Hyperledger to define a transaction format that is generic enough to be used in a wide range of environments with similar commonalities (i.e. format with sender/receiver addresses with backpointers)

    o These problems have been solved outside of blockchain -- businesses have been transacting for a while.  Looking for reusable components. As a platform, the components all need to work together.

    ·  What code currently exists?  If this was put into incubation, what would land on Day 0?  A lot seems to be centered around business process -- is supply chain as an umbrella project the best path?

    o Some code exists, but not production ready -- this is for incubation.  Code from track and trace usage linked in proposal, as well.

    o Customer, counterparty/party, product or material -- reusable components that can be assembled into an application that would tie these primitives together.

    ·  Why wouldn’t existing standards for supply chain apply?

    o Yes, the standards exists… but, why aren’t they implemented and in open source (or Hyperledger implementation) yet.

    ·  Compare Hyperledger Composer with the scope of this proposal?

    o Composer is a tool to help people get ramped into blockchain and do code generation of business considerations.

    o For this supply chain project, not code generation, but to still facilitate coding business level concerns in delivering an application.

    ·  A suggestion was made to add this into the proposal.

    ·  A suggestion was made to create a non-generic name (not “supply chain”)

    ·  A suggestion was made to have some references to existing standards, and sequencing expectations on deliverables

    ·  Questions as to whether it is limited to this vertical or more broadly encompassing

    ·  Continue discussion via chat and mailing list

     

    Quarterly project updates

    ·  Victor Hu provided the Hyperledger Caliper update

    o What is current level of communication between Caliper and PSWG?

    § For each PSWG meeting, one rep from Caliper will be there

    ·  Chris Ferris provided the Hyperledger Fabric update

    ·  Andi Gunderson provided the Hyperledger Sawtooth update

    o Is there a plan for testnet?

    § Loose plan was to get a starter testnet going where we raise nodes in different organizations, and do some basic integration testing across organizational boundaries -- then, look at more security-focused use of testnet

    o Are we still looking at testnet at a Hyperledger-level?

    § Dave Huseby is pulling together thoughts and a proposal for 2019 budget planning

    § ADD for TSC call next week

    ·  October 25th:  Hyperledger Iroha update

     

    Quarterly WG updates

    ·  No updates this week

    ·  October 25th:  Technical WG China update and Training and Education WG update

     

    --

    Todd Benzies

    Sr. Director, Program Management & Operations

    The Linux Foundation
    +1 (415) 412-0310 (m)

    2041 - 2060 of 3844