You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 20 Next »

Join our Peer Programming Call-In

We're going to start implementing the Utility Emissions Channel use case together to demonstrate the idea described here.  Join our zoom call to code with us:

When:
Monday, 14 September 2020
9:00am to 10:00am
(UTC-07:00) America/Los Angeles

Where:
https://zoom.us/my/hyperledger.community

Guest Speaker:

Chris Gabriel from Hyperchain Labs will be demoing some of his work with using the Fabric Certificate Authority, with which he has built a carbon network for different organizations (carbon emitter, regulator, renewable energy project manager, verifier, etc.)



This Minimum Viable Product will use these key concepts from the Multi Channel Data Architecture to build applications described in Carbon Accounting and Certification Working Group

  1. Access data from several permissioned channels.
  2. Use standard model-factors to calculate emissions from the data.  
  3. Record the emissions results on a permissioned channel for the next entity to consume.
  4. Minimalist apps which
    1. run as serverless micro services, for example on Amazon Lambda or Cloud Functions from Google or IBM;
    2. pass through customer authentication keys to the permissioned channels

In each process, it will simulate the roles of:

  • Data source, which provides product use data
  • CO2 emissions auditor, which calculates CO2 emissions from the product use data
  • Data consumer, which uses the CO2 emissions data to calculate their own emissions, purchase offsets, etc.

The MVP will allow self-contained carbon emissions calculators for different purposes, as well as simulate how carbon emissions data could be shared across a supply chain with multiple parties.

Potential data sources include:

  • Utility bills 
  • Shipping data
  • Travel data
  • Vehicle trip data
  • Renewable Energy Certificates
  • Carbon offsets 

Think of each of these data source as a "programming primitive."  On their own, they're just data.  But combined together, we could build a variety of interesting applications, such as:

Each of these applications could empower a group of people to work together and take positive climate action, without waiting for a central authority to step up and regulate things.  

What we need is more ideas, both of where to obtain emissions data and what kind of applications could be built with them, so please write if you have any suggestions.


Coding Standards

Even though, or perhaps because we're building open source software, code quality is very important.  We're writing code that others would see long after we're finished, so we'd better leave them something they could actually understand and work with.  We'd also like to avoid being featured in an "Anti Pattern" book or blog post.

The most important coding standard is to keep things very modular, so separate each function as much as possible.  The UI and application logic must be completely separated, to the point of being separate projects, and talk to each other only through clearly defined (REST) API's.  This means that we could have several different UI's, like Linux.  It also means we don't start putting our business logic in the UI, like some PHP or JSP code did.  Similarly, different application domains such as user management, application logic, and standards data management must be kept apart as well. 

  • No labels