Date   

[Hyperledger Project TSC] Identity WG Agenda March 8th 2017

Vipin Bharathan
 

Proposed Agenda:

Identity WG Paper- skeleton, sections
Fabric Composer - an Identity view
Continue discussion of Sovrin on-boarding
Other interesting groups working on Identity
Invitation to experts to discuss privacy & Identity
Any other topic related to Identity
 
Please look at wiki.hyperledger.org and go to the Identity wg for all the relevant links.

Please join the call at noon (EST)- call details in wiki.

Regards,
Vipin


[Hyperledger Project TSC] Identity working group call tomorrow March 8, 12 noon

Vipin Bharathan
 

Hi,
There will be an Identity WG call tomorrow March 8 12 noon EST for details check wiki.hyperledger.org
Regards,
Vipin


[Hyperledger Project TSC] Hyperledger Is Now Accepting Summer Internship Applications

Todd Benzies <tbenzies@...>
 

We're pleased to announced that Hyperledger is launching its inaugural summer internship program. We've put together 6 internship projects proposed by active developers in the technical community. These developers will also serve as the mentors for their projects and incoming interns. 

We need your help to spread the word about these opportunities and encourage college/university students in your networks to apply through the Linux Foundation job portal. They can find out about how to submit a strong application by reading the recommended application steps.

The application is now open and the deadline to apply is March 24. More detailed program schedule can be found here

If you have any questions, please contact internship@hyperledger.org.

--
Todd Benzies
Senior Program Manager
The Linux Foundation
+1 (415) 412-0310 (m)
Skype: tbenzies


Re: [Hyperledger Project TSC] Hyperledger TSC - GSL Discussion and Questions

Vipin Bharathan
 

Hi all,
I forwarded the chat log from last Thursday to Dan, Tamas & Lance. They can tease out questions from that.
Vipin

On Mar 6, 2017 2:15 PM, "Christopher Ferris via hyperledger-tsc" <hyperledger-tsc@...> wrote:
We should have time on this week's call for Q/A on GSL.

Chris

On Mar 6, 2017, at 1:38 PM, Dan O'Prey via hyperledger-tsc <hyperledger-tsc@lists.hyperledger.org> wrote:

All,

Thank you for those that attended last Thursday's TSC call during which Tamás Blummer and Lance Arlaus from Digital Asset presented an update on our latest thinking regarding a module candidate for cross-platform interoperability, the Global Synchronization Log. For those that missed it, the call was recorded: (starting at 37:30)

Unfortunately, we ran out of time for questions and we briefly saw lots of interesting comments and questions in the webex chat but they were lost as soon as the call ended a few seconds later.

If you have any questions, please send over to us directly and we will collate a short FAQ and circulate to this group.

Thanks a lot,

DAN O'PREY

​CMO​



DIGITAL ASSET HOLDINGS, LLC
96 SPRING STREET, 8TH FLOOR                             
NEW YORK, NY 10012
+​1 646-468-0213
dan
@digitalasset.com
digitalasset.com



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.
<GSL HL TSC Presentation.pdf>
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc

_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc


Re: [Hyperledger Project TSC] Hyperledger TSC - GSL Discussion and Questions

Christopher Ferris
 

We should have time on this week's call for Q/A on GSL.

Chris

On Mar 6, 2017, at 1:38 PM, Dan O'Prey via hyperledger-tsc <hyperledger-tsc@...> wrote:

All,

Thank you for those that attended last Thursday's TSC call during which Tamás Blummer and Lance Arlaus from Digital Asset presented an update on our latest thinking regarding a module candidate for cross-platform interoperability, the Global Synchronization Log. For those that missed it, the call was recorded: (starting at 37:30)

Unfortunately, we ran out of time for questions and we briefly saw lots of interesting comments and questions in the webex chat but they were lost as soon as the call ended a few seconds later.

If you have any questions, please send over to us directly and we will collate a short FAQ and circulate to this group.

Thanks a lot,

DAN O'PREY

​CMO​



DIGITAL ASSET HOLDINGS, LLC
96 SPRING STREET, 8TH FLOOR                             
NEW YORK, NY 10012
+​1 646-468-0213
dan
@digitalasset.com
digitalasset.com



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.
<GSL HL TSC Presentation.pdf>
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc


Re: [Hyperledger Project TSC] Hyperledger TSC - GSL Discussion and Questions

Christopher Ferris
 



Chris

On Mar 6, 2017, at 1:38 PM, Dan O'Prey via hyperledger-tsc <hyperledger-tsc@...> wrote:

All,

Thank you for those that attended last Thursday's TSC call during which Tamás Blummer and Lance Arlaus from Digital Asset presented an update on our latest thinking regarding a module candidate for cross-platform interoperability, the Global Synchronization Log. For those that missed it, the call was recorded: (starting at 37:30)

Unfortunately, we ran out of time for questions and we briefly saw lots of interesting comments and questions in the webex chat but they were lost as soon as the call ended a few seconds later.

If you have any questions, please send over to us directly and we will collate a short FAQ and circulate to this group.

Thanks a lot,

DAN O'PREY

​CMO​



DIGITAL ASSET HOLDINGS, LLC
96 SPRING STREET, 8TH FLOOR                             
NEW YORK, NY 10012
+​1 646-468-0213
dan
@digitalasset.com
digitalasset.com



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.
<GSL HL TSC Presentation.pdf>
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc


[Hyperledger Project TSC] Hyperledger TSC - GSL Discussion and Questions

Dan O'Prey
 

All,

Thank you for those that attended last Thursday's TSC call during which Tamás Blummer and Lance Arlaus from Digital Asset presented an update on our latest thinking regarding a module candidate for cross-platform interoperability, the Global Synchronization Log. For those that missed it, the call was recorded: (starting at 37:30)

Unfortunately, we ran out of time for questions and we briefly saw lots of interesting comments and questions in the webex chat but they were lost as soon as the call ended a few seconds later.

If you have any questions, please send over to us directly and we will collate a short FAQ and circulate to this group.

Thanks a lot,

DAN O'PREY

​CMO​



DIGITAL ASSET HOLDINGS, LLC
96 SPRING STREET, 8TH FLOOR                             
NEW YORK, NY 10012
+​1 646-468-0213
dan
@digitalasset.com
digitalasset.com



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.


[Hyperledger Project TSC] Minutes / March 2nd, 2017

Todd Benzies <tbenzies@...>
 

Hyperledger Project

Technical Steering Committee (TSC) Meeting

March 2, 2017 (7:00am - 8:00am PT)

via GoToMeeting


TSC Members

Arnaud Le Hors

Yes

Binh Nguyen

Yes

Christopher Ferris

Yes

Dan Middleton

Yes

Greg Haskins

Yes

Hart Montgomery

Yes

Mic Bowman

Yes

Murali Krishna Katipalli

Yes

Richard Brown

Yes

Sheehan Anderson

Yes

Tamas Blummer

Yes


Resources:


Action Item Review

  • Hackfest planning

    • East Coast, week of April 24th (venue/city pending)

    • Beijing, June TBD

    • If you have venue space, please contact Todd Benzies tbenzies@...

  • WG Charters

    • Requirements WG (Oleg)

      • Draft

      • Requirements WG meeting on March 6th to finalize, the to TSC on March 9th to approve

      • Brian B:  re: disbanding note… see the need for this WG to be ongoing, there will always be new use cases worth considering, new releases worth mapping to those use cases.

      • CF:  re: collaboration -- need a way to engage Requirements WG with some industry-specific WGs, like Healthcare.

      • DM:  Near outset of Hyperledger, there was some reluctance from a few to share info within this WG as it was seen as valuable IP within some companies, we should work to continue to move the needle on this perception and encourage continued sharing.

      • Vipin:  There has been movement in this direction.  Suggest also adding to the use cases some actual implementations to showcase the round-trip phenomenon.

  • slack-archive repo

    • No objections to archiving the Slack.  Ry to drive the process.

  • Internship Program

    • The subgroup met on February 28th and recommends the following 6 mentors/proposals

      • Deploy Fabric on Kubernetes Using Cello, Feihu Jiang, Huawei

      • Contract-based Business Process Execution / Hyperledger as a business process execution engine, László Gönczy, Budapest University of Technology and Economics

      • Anonymous Transactions in Iroha, Makoto Takemiya and Bogdan Vaneev, Soramitsu

      • Preserving Privacy with Sawtooth Lake, Dan Middleton, Intel

      • Design and Implement Blockchain Clustering Platform for Hyperledger, Baohua Yang and Haitao Yue, IBM China

      • Publish, Document, and Maintain a Distribution Agnostic Build Script, Mark Wagner, Red Hat

    • No objections -- ok to move forward with these 6.

  • Request to exit Incubation status for Hyperledger Fabric (here)

    • Note:  this isn’t about getting to 1.0, this is about maturity of “project,” not “product.“

    • Q:  What is the scope of Fabric?  Does it include chaintool or Node-SDK, for example?

      • CF:  From an alignment perspective, all Fabric-** are aligned in getting to 1.0.

    • Q:  What is ongoing role for IBM?  If IBM left would Fabric continue?

      • CF:  Year 1 goal was to get IBM under 50% of contributors (55% currently).  Today, positive sign of seeing more sustained contributors (non-IBM).  Ideally need to get down long-term number below 30% and get others more involved in Fabric.  In addition, of the IBM contributions, they come from multiple teams within IBM (not just one silo).

    • VOTE:  Unanimously approved.

  • GSL Discussion (Tamas Blummer)


Actions + On-going

  • Hackfest planning (East Coast, week of April 24th / Beijing, June)

  • Requirements WG Charter draft

--
Todd Benzies
Senior Program Manager
The Linux Foundation
+1 (415) 412-0310 (m)
Skype: tbenzies


Re: [Hyperledger Project TSC] Minutes / February 23rd, 2017

Todd Benzies <tbenzies@...>
 

Ry -- closing the loop on this thread.  There were no objections from the TSC to move forward.

On Wed, Mar 1, 2017 at 1:42 PM, Ry Jones <rjones@...> wrote:
I will not be able to attend the TSC call in the morning but here is my proposal for the slack archive.

As Hyperledger already has an AWS account, we could create an S3 bucket to hold the content of github[0] for indexing and display. It would need a host name - I have no good proposal for this. slack-archive.hyperledger.org perhaps?

I would still like to have the contents of github[1] hosted in my previously proposed repo in Gerrit. The gist that I used to generate the HTML is available[2]. Arnaud found some mangled characters - pull requests to fix the gist accepted.

We could host the initial version[0] until enough fixes are in to [2] to warrant a republication, or we could wait until people were generally happy with the formatting of the content.
Ry

[2] https://gist.github.com/rjones-lf/f8f4f9e4008567fa6ba9a03234316a33

On Thu, Feb 23, 2017 at 8:26 AM, Todd Benzies via hyperledger-tsc <hyperledger-tsc@lists.hyperledger.org> wrote:



--
Todd Benzies
Senior Program Manager
The Linux Foundation
+1 (415) 412-0310 (m)
Skype: tbenzies


[Hyperledger Project TSC] Agenda for March 2, 2017

Todd Benzies <tbenzies@...>
 

  • Hackfest planning
    • East Coast, week of April 24th (venue/city pending)
    • Beijing, June TBD
  • WG Charters
    • Requirements WG (Oleg) draft
  • slack-archive repo
  • Internship Program (suggested 6 from subgroup)
    • Deploy Fabric on Kubernetes Using Cello, Feihu Jiang, Huawei
    • Contract-based Business Process Execution / Hyperledger as a business process execution engine, László Gönczy, Budapest University of Technology and Economics
    • Anonymous Transactions in Iroha, Makoto Takemiya and Bogdan Vaneev, Soramitsu
    • Preserving Privacy with Sawtooth Lake, Dan Middleton, Intel
    • Design and Implement Blockchain Clustering Platform for Hyperledger, Baohua Yang and Haitao Yue, IBM China
    • Publish, Document, and Maintain a Distribution Agnostic Build Script, Mark Wagner, Red Hat
  • Request to exit Incubation status for Hyperledger Fabric (here)
  • GSL Discussion (Tamas Blummer)

--
Todd Benzies
Senior Program Manager
The Linux Foundation
+1 (415) 412-0310 (m)
Skype: tbenzies


Re: [Hyperledger Project TSC] Proposal of Eris-DB codebase to the Hyperledger project for incubation

Benjamin Bollen <ben@...>
 

Thanks Dan,

I will try to answer as precisely as I can.  Tendermint is a codebase licensed under Apache 2.0 and the copyright is owned by All in Bits, Inc (the company and amazing team behind Tendermint).

We have worked from the start very closely with Tendermint - from before its founding - to solve the consensus problem in an efficient and byzantine fault-tolerant (BFT) way and over the years our codebases have strongly influenced each other.  With the release of Eris-db v0.12 last year the logical and legal separation of the two codebases has completed. Eris-db consumes Tendermint core as a dependency, but Tendermint is a stand-alone project specialized in BFT consensus and as such it is not part of the upcoming submission of Eris-db to Hyperledger anymore than other dependencies we have.

You can find Tendermint at Tendermint.com and the code is hosted at github.com/tendermint/tendermint. We strongly encourage everyone to check them out and the amazing work they keep delivering for BFT consensus algorithms.

I hope this can clarify both the current situation and the history of the names.

Most kind regards,
Ben

On 2 Mar 2017, at 01:28, Dan O'Prey <dan@...> wrote:

Thanks, Casey and Monax team. From reading this, my understanding is the Tendermint codebase will also be submitted as part of the proposal by Monax rather than Tendermint itself. Is that correct? Will Tendermint also live separately as its own project?

Thanks for clarifying,

On Mar 1, 2017 15:56, "Casey Kuhlman via hyperledger-tsc" <hyperledger-tsc@...> wrote:
Dear members,

Please note that there was a typo in the subject of this email. We understand that the email is not the proposal and will be formally proposing to the TSC in the coming weeks. The email was simply for background and context about our upcoming submission.

Many apologies & best regards,
~Casey

____________________________________

Casey Kuhlman, Monax
CEO
Email: casey@... 
Phone (US): +1-423-523-9531(Netherlands): +31-62-864-2583
____________________________________

On Wed, Mar 1, 2017 at 9:44 PM, Benjamin Bollen <ben@...> wrote:

Dear Members of the Hyperledger Project Technical Steering Committee mailing list,


As many of you will have learned on Monday, Monax is very pleased to be joining the Hyperledger Project as a general member. Furthermore, we have determined that it is in our and the wider community’s interest for us to submit our blockchain client, Eris-db, to Hyperledger for incubation.


From our founding in 2014 until today, Monax’s objective has always been to build software which advances permissioned blockchain technology for enterprise use.


We feel the best way to build upon our work in permissioned blockchains to date is to create a forum in which a much larger community can contribute towards building production-grade ecosystem applications on the Ethereum Virtual Machine (EVM), a development paradigm which is organically popular among cryptocurrency developers, non-cryptocurrency blockchain developers, and enterprise developers alike.


We thought a good way to kick off the discussion about what we hope to achieve by joining Hyperledger would be to reach out to the members of this list with a brief overview of


  • what Eris-db is,

  • what we’re hoping to do with it once it’s under the Hyperledger umbrella, and

  • opportunities for you to get involved with the codebase’s development.


1. What is Eris-db?

Monax builds smart contract SDKs as well as a number of developer tools (package managers, chain managers, command line interfaces, etc.). We do not propose to place all of these in Hyperledger for the time being. What we are proposing to put into the Hyperledger project is Eris-db.


Eris-db is a permissioned blockchain node that executes smart contract code following the Ethereum specification. Eris-db also has permissioning protocols built in. It enjoys broad use among enterprise users of the Ethereum protocol and smart contract languages. Known users include a number of members of your consortium whom we will not name at this juncture, a number of bulge bracket banks, a range of top tier insurance providers, Deloitte, and SWIFT.


Eris-db is built for a multi-chain universe with application-specific optimization in mind. Eris-db as a node is constructed out of three main components: the consensus engine, the permissioned Ethereum Virtual Machine (EVM) and the rpc gateway.  


More specifically Eris-db consists of the following:


  • Consensus Engine: transactions are ordered and finalised with the Byzantine fault-tolerant Tendermint protocol.  The Tendermint protocol provides high transaction throughput over a set of known validators and prevents the blockchain from forking.

  • Application Blockchain Interface (ABCI): The smart contract application interfaces with the consensus engine over the ABCI. The ABCI allows for the consensus engine to remain agnostic from the smart contract application.

  • Smart Contract Application Engine: transactions are validated and applied to the application state in the order that the consensus engine has finalised them.  The application state consists of all accounts, the validator set and the name registry. Accounts in eris-db have permissions and either contain smart contract code or correspond to a public-private key pair. A transaction that calls on the smart contract code in a given account will activate the execution of that account’s code in a permissioned virtual machine.

  • Secure Native Functions: are the ground rules that all accounts and all smart contract code must follow.  Permissioning is enforced through secure native functions and underlies all smart contract code execution.

  • Permissioned Ethereum Virtual Machine: This virtual machine is built to observe the Ethereum operation code specification and additionally asserts the correct permissions have been granted. An arbitrary but finite amount of gas is handed out for every execution to ensure a finite execution duration - “You don’t need money to play, when you have permission to play”.

  • Application Binary Interface (ABI): transactions need to be formulated in a binary format that can be processed by the blockchain node.  Currently tooling provides functionality to compile, deploy and link solidity smart contracts and formulate transactions to call smart contracts on the chain. Future work on the light client will be aware of the ABI to natively translate calls on the API into signed transactions that can be broadcast on the network.

  • API Gateway: eris-db exposes REST and JSON-RPC endpoints to interact with the blockchain network and the application state through broadcasting transactions, or querying the current state of the application. Websockets allow to subscribe to events, which is particularly valuable as the consensus engine and smart contract application can give unambiguously finalised results to transactions after one blocktime of about one second.


Eris-db has been architected with a long term vision on security and data privacy from the outset:


  • Cryptographically Secured Consensus: Byzantine fault-tolerant Tendermint protocol achieves consensus over a known set of validators where every block is committed with cryptographic signatures from a majority of validators only.  No unknown variables come into play while reaching consensus on the network (as is the case for proof-of-work consensus). This guarantees that all actions on the network are fully cryptographically verified and traceable.

  • Remote Signing: transactions can be signed by elliptic curve cryptographic algorithms, either ed25519/sha512 or secp256k1/sha256 are currently supported. Eris-db connects to a remote signing solution to generate key pairs and request signatures. Eris-keys is a placeholder for a reverse proxy and we need security expertise from specialised companies to harden the platform here.

  • Multi-chain Universe (Step 1 of 3): from the start the eris platform has been conceived for orchestrating many chains, as exemplified by the command “eris chains make” or by that transactions are only valid on the intended chain. Separating state into different chains is only the first of three steps towards privacy on smart contract chains.  


What about roadmap proposals for Eris-db?


We already welcome contributions to and discussions about the proposed Eris-db roadmap items. Please refer to the Eris-db github repository for a deeper look at the proposed platform roadmap items. In terms of what the current roadmap looks like, please find a brief precis below:

Security, Identity and Privacy

  • Advanced security framework

  • Identity Management and Whitelisting

  • Multi-chain Universe (Step 2 of 3): Tendermint Cosmos proposal

  • Multi-chain Universe (Step 3 of 3): Monax’s NightSky proposal

Scalability and governance

  • Read-cache Optimisation and Queryability

  • Chain life-cycle management

  • Sharding and scalability framework

  • Light-client and ABI integration upgrade.



2. Why do we think Eris-db is good addition to Hyperledger?


  • The EVM is a highly popular tool for smart contract code execution. Eris-db, if accepted, would provide Hyperledger with a built-to-spec EVM, something the Project currently lacks

  • We invite you to contribute actively towards the roadmap (developers from everywhere can help build and test Eris-db, though the name will be changed once we submit it to Hyperledger - more on this below)

  • We want to ensure the longevity of the open source code base under the mature devops and governance of the Linux Foundation

  • We want to ensure larger community outreach and engagement for permissioned chains

  • We want to enable production level support as a primary driver in the realization of ecosystem applications


3. How do we hope to facilitate wider engagement with the codebase?


We would very much welcome new collaborators at the co-maintainer and contributor levels in the following areas:

  • co-maintainers of the codebase

  • thought leadership contribution towards developing the codebase’s long-term development roadmap

  • documentation and technical writing assistance

  • enterprise grade RPC optimization and client libraries

  • QA, packaging, and testing experts

  • network level QA and long-range scenario testing experts

The focus is on hardening the stack towards enterprise-ready production level demands pertaining to usability, scalability, security and data privacy. This is not a task that our small company can or should undertake on its own. If you or your company would like to participate in the maintainership of this EVM-capable codebase, feel free to ping me either on this list or at contact@....

In order to make engagement even easier, you can expect us to establish and/or improve on the existing services we have in place:


4. What about branding of Eris-db?


Our company was founded as “Eris Industries” in 2014. We re-branded to “Monax” in October of 2016. Our intention is to rebrand Eris-db to a name not associated with the company. We have some proposed names in mind but intend to settle on a final choice after discussing this with LF/Hyperledger members who have agreed to become co-maintainers.


Conclusion


We appreciate this opportunity to engage with the Hyperledger community at large, and welcome any and all comments and questions about our contribution and request for participation as laid out above.


Looking forward to continuing the conversation!


Yours faithfully


Casey Kuhlman, CEO, Monax

Preston Byrne, COO, Monax

Jan Scheufen, Product, Monax

Paul du Plessis, Partnerships, Monax

Benjamin Bollen, Core Developer, Monax

Silas Davis, Core Developer, Monax



_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc



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.


Re: [Hyperledger Project TSC] Proposal of Eris-DB codebase to the Hyperledger project for incubation

Dan O'Prey
 

Thanks, Casey and Monax team. From reading this, my understanding is the Tendermint codebase will also be submitted as part of the proposal by Monax rather than Tendermint itself. Is that correct? Will Tendermint also live separately as its own project?

Thanks for clarifying,

On Mar 1, 2017 15:56, "Casey Kuhlman via hyperledger-tsc" <hyperledger-tsc@...> wrote:
Dear members,

Please note that there was a typo in the subject of this email. We understand that the email is not the proposal and will be formally proposing to the TSC in the coming weeks. The email was simply for background and context about our upcoming submission.

Many apologies & best regards,
~Casey

____________________________________

Casey Kuhlman, Monax
CEO
Email: casey@... 
Phone (US): +1-423-523-9531(Netherlands): +31-62-864-2583
____________________________________

On Wed, Mar 1, 2017 at 9:44 PM, Benjamin Bollen <ben@...> wrote:

Dear Members of the Hyperledger Project Technical Steering Committee mailing list,


As many of you will have learned on Monday, Monax is very pleased to be joining the Hyperledger Project as a general member. Furthermore, we have determined that it is in our and the wider community’s interest for us to submit our blockchain client, Eris-db, to Hyperledger for incubation.


From our founding in 2014 until today, Monax’s objective has always been to build software which advances permissioned blockchain technology for enterprise use.


We feel the best way to build upon our work in permissioned blockchains to date is to create a forum in which a much larger community can contribute towards building production-grade ecosystem applications on the Ethereum Virtual Machine (EVM), a development paradigm which is organically popular among cryptocurrency developers, non-cryptocurrency blockchain developers, and enterprise developers alike.


We thought a good way to kick off the discussion about what we hope to achieve by joining Hyperledger would be to reach out to the members of this list with a brief overview of


  • what Eris-db is,

  • what we’re hoping to do with it once it’s under the Hyperledger umbrella, and

  • opportunities for you to get involved with the codebase’s development.


1. What is Eris-db?

Monax builds smart contract SDKs as well as a number of developer tools (package managers, chain managers, command line interfaces, etc.). We do not propose to place all of these in Hyperledger for the time being. What we are proposing to put into the Hyperledger project is Eris-db.


Eris-db is a permissioned blockchain node that executes smart contract code following the Ethereum specification. Eris-db also has permissioning protocols built in. It enjoys broad use among enterprise users of the Ethereum protocol and smart contract languages. Known users include a number of members of your consortium whom we will not name at this juncture, a number of bulge bracket banks, a range of top tier insurance providers, Deloitte, and SWIFT.


Eris-db is built for a multi-chain universe with application-specific optimization in mind. Eris-db as a node is constructed out of three main components: the consensus engine, the permissioned Ethereum Virtual Machine (EVM) and the rpc gateway.  


More specifically Eris-db consists of the following:


  • Consensus Engine: transactions are ordered and finalised with the Byzantine fault-tolerant Tendermint protocol.  The Tendermint protocol provides high transaction throughput over a set of known validators and prevents the blockchain from forking.

  • Application Blockchain Interface (ABCI): The smart contract application interfaces with the consensus engine over the ABCI. The ABCI allows for the consensus engine to remain agnostic from the smart contract application.

  • Smart Contract Application Engine: transactions are validated and applied to the application state in the order that the consensus engine has finalised them.  The application state consists of all accounts, the validator set and the name registry. Accounts in eris-db have permissions and either contain smart contract code or correspond to a public-private key pair. A transaction that calls on the smart contract code in a given account will activate the execution of that account’s code in a permissioned virtual machine.

  • Secure Native Functions: are the ground rules that all accounts and all smart contract code must follow.  Permissioning is enforced through secure native functions and underlies all smart contract code execution.

  • Permissioned Ethereum Virtual Machine: This virtual machine is built to observe the Ethereum operation code specification and additionally asserts the correct permissions have been granted. An arbitrary but finite amount of gas is handed out for every execution to ensure a finite execution duration - “You don’t need money to play, when you have permission to play”.

  • Application Binary Interface (ABI): transactions need to be formulated in a binary format that can be processed by the blockchain node.  Currently tooling provides functionality to compile, deploy and link solidity smart contracts and formulate transactions to call smart contracts on the chain. Future work on the light client will be aware of the ABI to natively translate calls on the API into signed transactions that can be broadcast on the network.

  • API Gateway: eris-db exposes REST and JSON-RPC endpoints to interact with the blockchain network and the application state through broadcasting transactions, or querying the current state of the application. Websockets allow to subscribe to events, which is particularly valuable as the consensus engine and smart contract application can give unambiguously finalised results to transactions after one blocktime of about one second.


Eris-db has been architected with a long term vision on security and data privacy from the outset:


  • Cryptographically Secured Consensus: Byzantine fault-tolerant Tendermint protocol achieves consensus over a known set of validators where every block is committed with cryptographic signatures from a majority of validators only.  No unknown variables come into play while reaching consensus on the network (as is the case for proof-of-work consensus). This guarantees that all actions on the network are fully cryptographically verified and traceable.

  • Remote Signing: transactions can be signed by elliptic curve cryptographic algorithms, either ed25519/sha512 or secp256k1/sha256 are currently supported. Eris-db connects to a remote signing solution to generate key pairs and request signatures. Eris-keys is a placeholder for a reverse proxy and we need security expertise from specialised companies to harden the platform here.

  • Multi-chain Universe (Step 1 of 3): from the start the eris platform has been conceived for orchestrating many chains, as exemplified by the command “eris chains make” or by that transactions are only valid on the intended chain. Separating state into different chains is only the first of three steps towards privacy on smart contract chains.  


What about roadmap proposals for Eris-db?


We already welcome contributions to and discussions about the proposed Eris-db roadmap items. Please refer to the Eris-db github repository for a deeper look at the proposed platform roadmap items. In terms of what the current roadmap looks like, please find a brief precis below:

Security, Identity and Privacy

  • Advanced security framework

  • Identity Management and Whitelisting

  • Multi-chain Universe (Step 2 of 3): Tendermint Cosmos proposal

  • Multi-chain Universe (Step 3 of 3): Monax’s NightSky proposal

Scalability and governance

  • Read-cache Optimisation and Queryability

  • Chain life-cycle management

  • Sharding and scalability framework

  • Light-client and ABI integration upgrade.



2. Why do we think Eris-db is good addition to Hyperledger?


  • The EVM is a highly popular tool for smart contract code execution. Eris-db, if accepted, would provide Hyperledger with a built-to-spec EVM, something the Project currently lacks

  • We invite you to contribute actively towards the roadmap (developers from everywhere can help build and test Eris-db, though the name will be changed once we submit it to Hyperledger - more on this below)

  • We want to ensure the longevity of the open source code base under the mature devops and governance of the Linux Foundation

  • We want to ensure larger community outreach and engagement for permissioned chains

  • We want to enable production level support as a primary driver in the realization of ecosystem applications


3. How do we hope to facilitate wider engagement with the codebase?


We would very much welcome new collaborators at the co-maintainer and contributor levels in the following areas:

  • co-maintainers of the codebase

  • thought leadership contribution towards developing the codebase’s long-term development roadmap

  • documentation and technical writing assistance

  • enterprise grade RPC optimization and client libraries

  • QA, packaging, and testing experts

  • network level QA and long-range scenario testing experts

The focus is on hardening the stack towards enterprise-ready production level demands pertaining to usability, scalability, security and data privacy. This is not a task that our small company can or should undertake on its own. If you or your company would like to participate in the maintainership of this EVM-capable codebase, feel free to ping me either on this list or at contact@....

In order to make engagement even easier, you can expect us to establish and/or improve on the existing services we have in place:


4. What about branding of Eris-db?


Our company was founded as “Eris Industries” in 2014. We re-branded to “Monax” in October of 2016. Our intention is to rebrand Eris-db to a name not associated with the company. We have some proposed names in mind but intend to settle on a final choice after discussing this with LF/Hyperledger members who have agreed to become co-maintainers.


Conclusion


We appreciate this opportunity to engage with the Hyperledger community at large, and welcome any and all comments and questions about our contribution and request for participation as laid out above.


Looking forward to continuing the conversation!


Yours faithfully


Casey Kuhlman, CEO, Monax

Preston Byrne, COO, Monax

Jan Scheufen, Product, Monax

Paul du Plessis, Partnerships, Monax

Benjamin Bollen, Core Developer, Monax

Silas Davis, Core Developer, Monax



_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc



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.


Re: [Hyperledger Project TSC] Minutes / February 23rd, 2017

Ry Jones
 

I will not be able to attend the TSC call in the morning but here is my proposal for the slack archive.

As Hyperledger already has an AWS account, we could create an S3 bucket to hold the content of github[0] for indexing and display. It would need a host name - I have no good proposal for this. slack-archive.hyperledger.org perhaps?

I would still like to have the contents of github[1] hosted in my previously proposed repo in Gerrit. The gist that I used to generate the HTML is available[2]. Arnaud found some mangled characters - pull requests to fix the gist accepted.

We could host the initial version[0] until enough fixes are in to [2] to warrant a republication, or we could wait until people were generally happy with the formatting of the content.
Ry

On Thu, Feb 23, 2017 at 8:26 AM, Todd Benzies via hyperledger-tsc <hyperledger-tsc@...> wrote:


Re: [Hyperledger Project TSC] Proposal of Eris-DB codebase to the Hyperledger project for incubation

Casey Kuhlman
 

Dear members,

Please note that there was a typo in the subject of this email. We understand that the email is not the proposal and will be formally proposing to the TSC in the coming weeks. The email was simply for background and context about our upcoming submission.

Many apologies & best regards,
~Casey

____________________________________

Casey Kuhlman, Monax
CEO
Email: casey@... 
Phone (US): +1-423-523-9531(Netherlands): +31-62-864-2583
____________________________________

On Wed, Mar 1, 2017 at 9:44 PM, Benjamin Bollen <ben@...> wrote:

Dear Members of the Hyperledger Project Technical Steering Committee mailing list,


As many of you will have learned on Monday, Monax is very pleased to be joining the Hyperledger Project as a general member. Furthermore, we have determined that it is in our and the wider community’s interest for us to submit our blockchain client, Eris-db, to Hyperledger for incubation.


From our founding in 2014 until today, Monax’s objective has always been to build software which advances permissioned blockchain technology for enterprise use.


We feel the best way to build upon our work in permissioned blockchains to date is to create a forum in which a much larger community can contribute towards building production-grade ecosystem applications on the Ethereum Virtual Machine (EVM), a development paradigm which is organically popular among cryptocurrency developers, non-cryptocurrency blockchain developers, and enterprise developers alike.


We thought a good way to kick off the discussion about what we hope to achieve by joining Hyperledger would be to reach out to the members of this list with a brief overview of


  • what Eris-db is,

  • what we’re hoping to do with it once it’s under the Hyperledger umbrella, and

  • opportunities for you to get involved with the codebase’s development.


1. What is Eris-db?

Monax builds smart contract SDKs as well as a number of developer tools (package managers, chain managers, command line interfaces, etc.). We do not propose to place all of these in Hyperledger for the time being. What we are proposing to put into the Hyperledger project is Eris-db.


Eris-db is a permissioned blockchain node that executes smart contract code following the Ethereum specification. Eris-db also has permissioning protocols built in. It enjoys broad use among enterprise users of the Ethereum protocol and smart contract languages. Known users include a number of members of your consortium whom we will not name at this juncture, a number of bulge bracket banks, a range of top tier insurance providers, Deloitte, and SWIFT.


Eris-db is built for a multi-chain universe with application-specific optimization in mind. Eris-db as a node is constructed out of three main components: the consensus engine, the permissioned Ethereum Virtual Machine (EVM) and the rpc gateway.  


More specifically Eris-db consists of the following:


  • Consensus Engine: transactions are ordered and finalised with the Byzantine fault-tolerant Tendermint protocol.  The Tendermint protocol provides high transaction throughput over a set of known validators and prevents the blockchain from forking.

  • Application Blockchain Interface (ABCI): The smart contract application interfaces with the consensus engine over the ABCI. The ABCI allows for the consensus engine to remain agnostic from the smart contract application.

  • Smart Contract Application Engine: transactions are validated and applied to the application state in the order that the consensus engine has finalised them.  The application state consists of all accounts, the validator set and the name registry. Accounts in eris-db have permissions and either contain smart contract code or correspond to a public-private key pair. A transaction that calls on the smart contract code in a given account will activate the execution of that account’s code in a permissioned virtual machine.

  • Secure Native Functions: are the ground rules that all accounts and all smart contract code must follow.  Permissioning is enforced through secure native functions and underlies all smart contract code execution.

  • Permissioned Ethereum Virtual Machine: This virtual machine is built to observe the Ethereum operation code specification and additionally asserts the correct permissions have been granted. An arbitrary but finite amount of gas is handed out for every execution to ensure a finite execution duration - “You don’t need money to play, when you have permission to play”.

  • Application Binary Interface (ABI): transactions need to be formulated in a binary format that can be processed by the blockchain node.  Currently tooling provides functionality to compile, deploy and link solidity smart contracts and formulate transactions to call smart contracts on the chain. Future work on the light client will be aware of the ABI to natively translate calls on the API into signed transactions that can be broadcast on the network.

  • API Gateway: eris-db exposes REST and JSON-RPC endpoints to interact with the blockchain network and the application state through broadcasting transactions, or querying the current state of the application. Websockets allow to subscribe to events, which is particularly valuable as the consensus engine and smart contract application can give unambiguously finalised results to transactions after one blocktime of about one second.


Eris-db has been architected with a long term vision on security and data privacy from the outset:


  • Cryptographically Secured Consensus: Byzantine fault-tolerant Tendermint protocol achieves consensus over a known set of validators where every block is committed with cryptographic signatures from a majority of validators only.  No unknown variables come into play while reaching consensus on the network (as is the case for proof-of-work consensus). This guarantees that all actions on the network are fully cryptographically verified and traceable.

  • Remote Signing: transactions can be signed by elliptic curve cryptographic algorithms, either ed25519/sha512 or secp256k1/sha256 are currently supported. Eris-db connects to a remote signing solution to generate key pairs and request signatures. Eris-keys is a placeholder for a reverse proxy and we need security expertise from specialised companies to harden the platform here.

  • Multi-chain Universe (Step 1 of 3): from the start the eris platform has been conceived for orchestrating many chains, as exemplified by the command “eris chains make” or by that transactions are only valid on the intended chain. Separating state into different chains is only the first of three steps towards privacy on smart contract chains.  


What about roadmap proposals for Eris-db?


We already welcome contributions to and discussions about the proposed Eris-db roadmap items. Please refer to the Eris-db github repository for a deeper look at the proposed platform roadmap items. In terms of what the current roadmap looks like, please find a brief precis below:

Security, Identity and Privacy

  • Advanced security framework

  • Identity Management and Whitelisting

  • Multi-chain Universe (Step 2 of 3): Tendermint Cosmos proposal

  • Multi-chain Universe (Step 3 of 3): Monax’s NightSky proposal

Scalability and governance

  • Read-cache Optimisation and Queryability

  • Chain life-cycle management

  • Sharding and scalability framework

  • Light-client and ABI integration upgrade.



2. Why do we think Eris-db is good addition to Hyperledger?


  • The EVM is a highly popular tool for smart contract code execution. Eris-db, if accepted, would provide Hyperledger with a built-to-spec EVM, something the Project currently lacks

  • We invite you to contribute actively towards the roadmap (developers from everywhere can help build and test Eris-db, though the name will be changed once we submit it to Hyperledger - more on this below)

  • We want to ensure the longevity of the open source code base under the mature devops and governance of the Linux Foundation

  • We want to ensure larger community outreach and engagement for permissioned chains

  • We want to enable production level support as a primary driver in the realization of ecosystem applications


3. How do we hope to facilitate wider engagement with the codebase?


We would very much welcome new collaborators at the co-maintainer and contributor levels in the following areas:

  • co-maintainers of the codebase

  • thought leadership contribution towards developing the codebase’s long-term development roadmap

  • documentation and technical writing assistance

  • enterprise grade RPC optimization and client libraries

  • QA, packaging, and testing experts

  • network level QA and long-range scenario testing experts

The focus is on hardening the stack towards enterprise-ready production level demands pertaining to usability, scalability, security and data privacy. This is not a task that our small company can or should undertake on its own. If you or your company would like to participate in the maintainership of this EVM-capable codebase, feel free to ping me either on this list or at contact@....

In order to make engagement even easier, you can expect us to establish and/or improve on the existing services we have in place:


4. What about branding of Eris-db?


Our company was founded as “Eris Industries” in 2014. We re-branded to “Monax” in October of 2016. Our intention is to rebrand Eris-db to a name not associated with the company. We have some proposed names in mind but intend to settle on a final choice after discussing this with LF/Hyperledger members who have agreed to become co-maintainers.


Conclusion


We appreciate this opportunity to engage with the Hyperledger community at large, and welcome any and all comments and questions about our contribution and request for participation as laid out above.


Looking forward to continuing the conversation!


Yours faithfully


Casey Kuhlman, CEO, Monax

Preston Byrne, COO, Monax

Jan Scheufen, Product, Monax

Paul du Plessis, Partnerships, Monax

Benjamin Bollen, Core Developer, Monax

Silas Davis, Core Developer, Monax



[Hyperledger Project TSC] Proposal of Eris-DB codebase to the Hyperledger project for incubation

Benjamin Bollen <ben@...>
 

Dear Members of the Hyperledger Project Technical Steering Committee mailing list,


As many of you will have learned on Monday, Monax is very pleased to be joining the Hyperledger Project as a general member. Furthermore, we have determined that it is in our and the wider community’s interest for us to submit our blockchain client, Eris-db, to Hyperledger for incubation.


From our founding in 2014 until today, Monax’s objective has always been to build software which advances permissioned blockchain technology for enterprise use.


We feel the best way to build upon our work in permissioned blockchains to date is to create a forum in which a much larger community can contribute towards building production-grade ecosystem applications on the Ethereum Virtual Machine (EVM), a development paradigm which is organically popular among cryptocurrency developers, non-cryptocurrency blockchain developers, and enterprise developers alike.


We thought a good way to kick off the discussion about what we hope to achieve by joining Hyperledger would be to reach out to the members of this list with a brief overview of


  • what Eris-db is,

  • what we’re hoping to do with it once it’s under the Hyperledger umbrella, and

  • opportunities for you to get involved with the codebase’s development.


1. What is Eris-db?

Monax builds smart contract SDKs as well as a number of developer tools (package managers, chain managers, command line interfaces, etc.). We do not propose to place all of these in Hyperledger for the time being. What we are proposing to put into the Hyperledger project is Eris-db.


Eris-db is a permissioned blockchain node that executes smart contract code following the Ethereum specification. Eris-db also has permissioning protocols built in. It enjoys broad use among enterprise users of the Ethereum protocol and smart contract languages. Known users include a number of members of your consortium whom we will not name at this juncture, a number of bulge bracket banks, a range of top tier insurance providers, Deloitte, and SWIFT.


Eris-db is built for a multi-chain universe with application-specific optimization in mind. Eris-db as a node is constructed out of three main components: the consensus engine, the permissioned Ethereum Virtual Machine (EVM) and the rpc gateway.  


More specifically Eris-db consists of the following:


  • Consensus Engine: transactions are ordered and finalised with the Byzantine fault-tolerant Tendermint protocol.  The Tendermint protocol provides high transaction throughput over a set of known validators and prevents the blockchain from forking.

  • Application Blockchain Interface (ABCI): The smart contract application interfaces with the consensus engine over the ABCI. The ABCI allows for the consensus engine to remain agnostic from the smart contract application.

  • Smart Contract Application Engine: transactions are validated and applied to the application state in the order that the consensus engine has finalised them.  The application state consists of all accounts, the validator set and the name registry. Accounts in eris-db have permissions and either contain smart contract code or correspond to a public-private key pair. A transaction that calls on the smart contract code in a given account will activate the execution of that account’s code in a permissioned virtual machine.

  • Secure Native Functions: are the ground rules that all accounts and all smart contract code must follow.  Permissioning is enforced through secure native functions and underlies all smart contract code execution.

  • Permissioned Ethereum Virtual Machine: This virtual machine is built to observe the Ethereum operation code specification and additionally asserts the correct permissions have been granted. An arbitrary but finite amount of gas is handed out for every execution to ensure a finite execution duration - “You don’t need money to play, when you have permission to play”.

  • Application Binary Interface (ABI): transactions need to be formulated in a binary format that can be processed by the blockchain node.  Currently tooling provides functionality to compile, deploy and link solidity smart contracts and formulate transactions to call smart contracts on the chain. Future work on the light client will be aware of the ABI to natively translate calls on the API into signed transactions that can be broadcast on the network.

  • API Gateway: eris-db exposes REST and JSON-RPC endpoints to interact with the blockchain network and the application state through broadcasting transactions, or querying the current state of the application. Websockets allow to subscribe to events, which is particularly valuable as the consensus engine and smart contract application can give unambiguously finalised results to transactions after one blocktime of about one second.


Eris-db has been architected with a long term vision on security and data privacy from the outset:


  • Cryptographically Secured Consensus: Byzantine fault-tolerant Tendermint protocol achieves consensus over a known set of validators where every block is committed with cryptographic signatures from a majority of validators only.  No unknown variables come into play while reaching consensus on the network (as is the case for proof-of-work consensus). This guarantees that all actions on the network are fully cryptographically verified and traceable.

  • Remote Signing: transactions can be signed by elliptic curve cryptographic algorithms, either ed25519/sha512 or secp256k1/sha256 are currently supported. Eris-db connects to a remote signing solution to generate key pairs and request signatures. Eris-keys is a placeholder for a reverse proxy and we need security expertise from specialised companies to harden the platform here.

  • Multi-chain Universe (Step 1 of 3): from the start the eris platform has been conceived for orchestrating many chains, as exemplified by the command “eris chains make” or by that transactions are only valid on the intended chain. Separating state into different chains is only the first of three steps towards privacy on smart contract chains.  


What about roadmap proposals for Eris-db?


We already welcome contributions to and discussions about the proposed Eris-db roadmap items. Please refer to the Eris-db github repository for a deeper look at the proposed platform roadmap items. In terms of what the current roadmap looks like, please find a brief precis below:

Security, Identity and Privacy

  • Advanced security framework

  • Identity Management and Whitelisting

  • Multi-chain Universe (Step 2 of 3): Tendermint Cosmos proposal

  • Multi-chain Universe (Step 3 of 3): Monax’s NightSky proposal

Scalability and governance

  • Read-cache Optimisation and Queryability

  • Chain life-cycle management

  • Sharding and scalability framework

  • Light-client and ABI integration upgrade.



2. Why do we think Eris-db is good addition to Hyperledger?


  • The EVM is a highly popular tool for smart contract code execution. Eris-db, if accepted, would provide Hyperledger with a built-to-spec EVM, something the Project currently lacks

  • We invite you to contribute actively towards the roadmap (developers from everywhere can help build and test Eris-db, though the name will be changed once we submit it to Hyperledger - more on this below)

  • We want to ensure the longevity of the open source code base under the mature devops and governance of the Linux Foundation

  • We want to ensure larger community outreach and engagement for permissioned chains

  • We want to enable production level support as a primary driver in the realization of ecosystem applications


3. How do we hope to facilitate wider engagement with the codebase?


We would very much welcome new collaborators at the co-maintainer and contributor levels in the following areas:

  • co-maintainers of the codebase

  • thought leadership contribution towards developing the codebase’s long-term development roadmap

  • documentation and technical writing assistance

  • enterprise grade RPC optimization and client libraries

  • QA, packaging, and testing experts

  • network level QA and long-range scenario testing experts

The focus is on hardening the stack towards enterprise-ready production level demands pertaining to usability, scalability, security and data privacy. This is not a task that our small company can or should undertake on its own. If you or your company would like to participate in the maintainership of this EVM-capable codebase, feel free to ping me either on this list or at contact@....

In order to make engagement even easier, you can expect us to establish and/or improve on the existing services we have in place:


4. What about branding of Eris-db?


Our company was founded as “Eris Industries” in 2014. We re-branded to “Monax” in October of 2016. Our intention is to rebrand Eris-db to a name not associated with the company. We have some proposed names in mind but intend to settle on a final choice after discussing this with LF/Hyperledger members who have agreed to become co-maintainers.


Conclusion


We appreciate this opportunity to engage with the Hyperledger community at large, and welcome any and all comments and questions about our contribution and request for participation as laid out above.


Looking forward to continuing the conversation!


Yours faithfully


Casey Kuhlman, CEO, Monax

Preston Byrne, COO, Monax

Jan Scheufen, Product, Monax

Paul du Plessis, Partnerships, Monax

Benjamin Bollen, Core Developer, Monax

Silas Davis, Core Developer, Monax


[Hyperledger Project TSC] TWG-China Meeting Minutes for 2017-03-01

Baohua Yang
 

Dear all

We just had the bi-weekly meeting today.


More information of TWG-China can be found at https://wiki.hyperledger.org/groups/tsc/technical-working-group-china.

Thanks!


--
Best wishes!

Baohua Yang


[Hyperledger Project TSC] [reminder] Hackfest Scheduling / April (East Coast) - action needed

Todd Benzies <tbenzies@...>
 

If you are planning to attend the next Hyperledger Hackfest on the East Coast in April, please take a quick second to indicate your preferred week for the event to be held:  http://doodle.com/poll/xwdefutqhpwsqszr.  [note:  it will be a 2-day event]

Regards,

Todd

On Thu, Feb 23, 2017 at 8:07 AM, Todd Benzies <tbenzies@...> wrote:
Hyperledger Technical Community,

As discussed on the TSC call, we are looking to hold a Hackfest on the East Coast in April.  As such, please indicate your preference on timing at http://doodle.com/poll/xwdefutqhpwsqszr.

Also, if you have venue space and would be interested in hosting, please get in touch with me directly.  Happy to provide some more details.

Regards,

Todd

--
Todd Benzies
Senior Program Manager
The Linux Foundation
+1 (415) 412-0310 (m)
Skype: tbenzies



--
Todd Benzies
Senior Program Manager
The Linux Foundation
+1 (415) 412-0310 (m)
Skype: tbenzies


[Hyperledger Project TSC] Mentors desired for the LF/Hyperledger Beijing Hackathon Mar 11-12

Brian Behlendorf
 


The Linux Foundation, Wanda, and IBM are jointly producing a hackathon in Shanghai on March 11th and 12th.  This is a competition-focused weekend event like the one we held in October in Amsterdam.  There are already 120 developers registered for this, with room for more.  Here's the link:

http://szqy.ffan.com/hack/Hack/

Given the response, there is a need for more mentors and experts to advise the development teams during their work, so we'd like to encourage anyone on these lists who knows their way around any of the major Hyperledger DLT projects (Fabric, Sawtooth, Iroha) to come to Shanghai for the event. The reward is building your connection to the China blockchain community, and watching the Hyperledger community grow in China. Chris Ferris and I will both be there and will make sure you have a good time. Travel invitation letters can be issued to streamline visa applications.

There is no direct compensation or expense coverage for participation as a menotr, but if it helps, Hyperledger will reimburse two nights at a nearby hotel for up to 3 individuals.

If you're interested in participating as an expert, please contact Julian Gordon <jgordon@...>.

Thanks!

Brian


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


Re: [Hyperledger Project TSC] TWG China monthly report for Feb 2017

Baohua Yang
 

Dear Brian

Thanks and great to hear that good news! 

We did suffer sometimes due to the low access to the website :(

Regarding the i18n work, the team has already started by communication and putting materials to temp locations like google doc, once we got the project repo ready, we can migrate to that.

And for the forum website, we can evaluate the access performance after migrating to Cloudflare (after they fixed the security issue certainly).

The rocketchat/wiki work well mostly, but also meet some connection problem occasionally.

Thanks! 

On Mon, Feb 27, 2017 at 10:17 AM, Brian Behlendorf <bbehlendorf@...> wrote:
Baohua, this looks great.  Thank you for drafting it.  Would like the TSC's help in the following two points?

2. i18n work: Need to fix the platform problem.
3. Forum: Adopt the global one? Or use some local 3rd-party one?

Regarding i18n of the web site: at the Linux Foundation we are starting work on localizing hyperledger.org, and are about to move to Cloudflare (yes, I am aware of the security incident they had recently) so as to provide acceleration from China datacenters.  I realize you are likely focused in i18n of documentation, but wanted to point this out.  Also, let us know if any part of the rest of the infrastructure (RocketChat, Wiki, etc) doesn't have adequate support.

Brian


On 02/26/2017 02:35 AM, Baohua Yang wrote:
Dear TSC

On behalf of the TWG-China, we have drafted the working report for Feb 2017. 



Welcome for any advice&comments!

Thanks!


--
Best wishes!

Baohua Yang


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



--
Best wishes!

Baohua Yang


Re: [Hyperledger Project TSC] TWG China monthly report for Feb 2017

Brian Behlendorf
 

Baohua, this looks great.  Thank you for drafting it.  Would like the TSC's help in the following two points?

2. i18n work: Need to fix the platform problem.
3. Forum: Adopt the global one? Or use some local 3rd-party one?

Regarding i18n of the web site: at the Linux Foundation we are starting work on localizing hyperledger.org, and are about to move to Cloudflare (yes, I am aware of the security incident they had recently) so as to provide acceleration from China datacenters.  I realize you are likely focused in i18n of documentation, but wanted to point this out.  Also, let us know if any part of the rest of the infrastructure (RocketChat, Wiki, etc) doesn't have adequate support.

Brian

On 02/26/2017 02:35 AM, Baohua Yang wrote:
Dear TSC

On behalf of the TWG-China, we have drafted the working report for Feb 2017. 



Welcome for any advice&comments!

Thanks!


--
Best wishes!

Baohua Yang


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

2661 - 2680 of 3318