This is an implementation of the emissions data channels from the Operating System for Climate Action.

A Demo

This project calculates the emissions impact of activities, for example shipping and travel, from the Supply Chain Decarbonization.

The Use Case

  • User (could be a company or an individual) uploads their activities data to calculate their emissions impact.
  • User pays a fee for the audit into a treasury.
  • One or more Auditors reviews the activities data.
  • Auditor may interact with the User to get additional information.
  • Auditor calculates Greenhouse Gas (GHG) emissions from the activities data based on published emissions factors.
  • Auditor issues a token on the Emissions Tokens Network for the emissions or declines to issue based on problems with the activities data from the User.
  • In either case, the Auditor is paid from the treasury.

The Auditor could be a single entity, chosen randomly from several trusted entities on the network.  Or it could be several entities reviewing the activities data together.  If there are several auditors reviewing the data, the final result could be weighted based on reputation tokens of the Auditors, or it could be a vote through a DAO such as the Decarbonization DAO.

The Auditors could in turn be reviewed by a wider community, who would award reputation tokens based on the quality of their work.

Implementation

This process could be implemented either in Hyperledger Fabric for an enterprise solution (performance, security, and scalability) or using encrypted IPFS for transferring data through Solidity smart contracts (cheap and simple), either on a public Ethereum-compatible network or permissioned Hyperledger Besu. 

Emissions Data are Not Tokens

The emissions data are not tokens and not meant for transactions.  The emissions data can be used to create a token which is suitable for transaction as part of the Emissions Tokens Network.  For example, the emissions data from a full month or several months could be used to create a token.  The token may require that the emissions data used covers enough of the time period, and that there are no overlaps of emissions data.

To prevent double counting, we will not allow emissions records for the same utility customer in overlapping date ranges on the channel.

Get Involved

An error occured while executinng macro:

Access token 7 not found

Icon


Get Involved

This is an open source project and anyone is welcome to get involved and we will be happy to see you contribute.

1) Start by subscribing to the Climate SIG mailing list for updates and meeting notifications.

2) Join our bi-monthly Peer Programming Zoom call for developers on Mondays at 9 AM US Pacific time (UTC-07:00 America/Los Angeles.) Please check the calendar for the next call. 

3) Check out the good first issues from our blockchain-carbon-accounting in Hyperledger-labs and feel free to contribute a fix for one that looks interesting to you.

4) See our How to Contribute page for other ways how you could get involved. 

  • No labels

44 Comments

  1. Tadisetty Subbha praveen

    Hello Chen,

    Thanks for sharing the detailed description for tracking the Co2 emission per customer based on electricity usage.

    All organizations have sustainability goals on Co2 emission reduction, the use case mentioned above is it for tracking and transparency on the carbon emission and managing carbon credit?

    https://btcmanager.com/ibm-launches-carbon-credit-management-using-hyperledger-fabric-blockchain/?q=/ibm-launches-carbon-credit-management-using-hyperledger-fabric-blockchain/&

    Is this page intended for tracking Co2 emission for individuals from a single utility company?

    I am looking for Hyperledger based solution for a similar use-case.

    Thanks,

    Praveen





    1. Si Chen

      Yes, it is for tracking carbon emissions, which is the foundation that could then be used for a variety of applications, including managing and trading carbon credits, disclosuing carbon emissions and ESG metrics, purchasing personal or corporate offsets, etc.  

  2. Robin Klemens

    Hi Si Chen,
    thank you very much for providing the use case. My feedback below is categorized according to the categories of the description of your proposal.
    Set Up the Channel:

    • "Auditor – trusted third-party which calculates CO2 emissions from utility energy use and published data sources":
      • I'd prefer at minimum two auditors and move the C02 calculation to the blockchain in form of a smart contract. The smart contract will then be executed by the two auditors and maybe additional parties such as the utility if the utility hosts an endorsing peer node (endorsing peers are peers which hold and execute a smart contract)
    • "Channel Operator – a third party which operates the channel, including maintaining the Orderer and Anchor Peer and allowing new organizations into the channel. In real life this Channel Operator would probably operate on behalf of the utilities and the customers who use it, under the supervision of a governance entity.":
      • In Hyperledger Fabric there isn't a construct like a third party channel operator. A channel is managed by the organizations that participate in it. However, this could also just be a few admin organizations. Who is in charge of the channel is defined in the configtx.yaml file prior to starting the blockchain network (The configtx.yaml file defines the channel capabilities as well as permissions, and the channel genesis block is created from it).
      • Every organization which hosts peer nodes has to define at minimum anchor peers. Anchor peers are the contact point for other organizations. Thus, anchor peers start communicating with anchor peers and then tell other (non-anchor peers) the connection information in a gossip protocol. Anchor peers are also defined in the configtx.yaml file as well as the peer nodes themselves.
      • In terms of the orderer service redundancy should also be our goal. The Raft ordering service requires at least three ordering nodes in order to function properly. Thus, we should distribute three ordering nodes to three different orgs. If all the orderer nodes were within the hands of one organization, this organization would be a central entity of the system with too much power.

    • "1 Orderer run by Channel Operator":

      • Three ordering nodes run by two/three validators (and the utility)

    • "1 Anchor Peer run by Channel Operator"/ "3 Peers run by 1 Peer Node Operator, 1 Auditor, and 1 Channel Operator"

      • I count three orgs: Two auditors and the utility hosting peer nodes. The company can be considered an additional org, but does not have a role to play in the infrastructure layer of Hyperledger Fabric.

      • Thus we would have three anchor peers (one per org)

    • "MSP for Auditor and each Customer. The auditor is given permission to write data to the channel. The customers are given permission to read data from the channel. Their MSP's are able to register certificates for their users"
      • Each org (peer) comes with an MSP by default. The MSP enables Access Control Lists (ACL) on a channel level and Chaincode Access Control on a chaincode level. Hyperledger Fabric uses X.509 certificates which allows for fine granularity in setting up identity-based permissions to read/write access

    Data Stored on Channel:

    • "Link to raw utility bill data on IPFS, encrypted (Question – how should this be encrypted?  With customer's public key so that it can only be decrypted by customer?)":
      • I don't think this should be encrypted at all. At least the utility (initially), the customer and the auditors need to have access to the link to the documents stored on IPFS. Hence, we have multiple keys that make encryption by the customer's public key not suitable. A better way of denying access to the data would to use chaincode access control to the link and limit access to the customer as well as the auditors.
    • "HASH of utility bill data for verification":
      • If the data is stored on IPFS, there is no additional hash of the utility bill data (the document) needed as IPFS generates a hash value for each data that is stored. Thus the IPFS link can be used as the unique identifier. IPFS uses SHA-256 (32 bytes) and the output is Base58 encoded which allows for recalculating the hash of the raw data if needed.
    • I would also add information about the "current owner" of the CO2 emission and later CO2 token. This would allow for better accountability and tradability.

    Store Emissions Data:

    • I would love to tackle the challenge to put the process of converting the kWh of electricity used to CO2 emissions in a smart contract. This would of course lead to a lot of computation at the blockchain level but could remove the need of one single auditor. With the chaincode defined properly and having all the auditors agreed on, the auditors' nodes could execute the smart contract and consensus would lead to a result. This could be a great starting point for outsourcing computation-intensive processes to Hyperledger Avalon. However, in the prototype, we don't need to worry about scalability or transactions per minute.
    • "Write the CO2 emissions for each customer to the channel as private data for each customer"
      • Data on a channel cannot be completely private as the data is at least accessible by all hosts of peer nodes in the channel. The concepts of ACL or chaincode access control can of course be applied. If data has to be totally confidential, the data needs to be stored in a private data collection which requires hosting a peer node and being part of the channel.

    I propose the following high-level architecture of the Hyperledger Fabric network of the prototype:


    Each auditing organization hosts one Certificate Authority (CA). The CAs generate all the crypto material needed for the Utility Emission Channel which includes TLS-certificates for peer and ordering nodes, and the certificates as well as the keys for all users.

    I'm looking forward to getting feedback on my ideas. If we collectively agree on a certain architecture of the network I'd love to support in elaborating a more detailed version. 

    Greetings from Berlin
    /Robin

    1. Si Chen

      Hi Robin KlemensThanks very much for your comments.  Just a few thoughts about how organizationally the channel might work:

      • The auditing company may just be a specialized environmental engineering company, so they can analyze utility data, publish the CO2 emissions, but not necessarily want to be an admin organization on a channel. 
      • The utility would continue to run its business as today – supply electricity, generate bills, but not necessarily want to get on a blockchain channel.  (I'm not 100% sure but that might require public hearings in front of a regulator.)

      So I thought of a Channel Operator as an entity which manages these channels for different utilities and auditors.  As you suggest, though, maybe there could be a couple of organizations that are part of a group that runs the channel, rather than just one.  Each one would have orderning and peer nodes.  Then the auditors would have MSP's to allow customers to access their data.

      In terms of the utility bills, if it's just stored on IPFS without encryption, businesses and utilities may have concerns about privacy of data, even not very important data.

      Finally, the good news is that calculating emissions from kWH used is relatively simple.  The utilities are required to report their power mix in that eGRID database, so we can just use that and multiply by the kWH.

    2. Si Chen

      Robin Klemens I just added a section "The Use Case" of how it would work.  Please take a look and let me know what you think.

    3. Yilin Sai

      Hi Robin Klemens,

      From my understanding, Raft cluster has one leader node which determines the ordering, the other nodes just copy the ordering result from the leader nodes. Therefore, having multiple organisations running orderers doesn't distribute the power.

      Raft can be set up with a single node, as documented here: https://hyperledger-fabric.readthedocs.io/en/release-2.2/orderer/ordering_service.html#ordering-service-implementations. "Existing users of Solo should move to a single node Raft network for equivalent function."

      The purpose of running multiple raft nodes is crash tolerance.

      1. Robin Klemens

        Hi Yilin Sai, we understand the functionality of the Raft ordering service in the same way. Like in Kafka, Raft follows a leader and follower model. Thus the leader is the one ordering the batches and the follower just copy them. 

        I want to clarify what I mean by "If all the orderer nodes were within the hands of one organization, this organization would be a central entity of the system with too much power":

        Imagine two setups of the ordering service:

        1. Three ordering nodes within one organization which acts as the ordering service for the network
        2. Three ordering nodes distributed across three organizations

        Both settings can be considered crash fault-tolerant since if one node crashes the Raft cluster would still be functioning.

        Now it comes to my understanding of too much power:

        In scenario 1, all ordering nodes belong to one organization. Thus the organization could just stop all ordering nodes which would lead to a non-functional blockchain network as there is no ordering service anymore. 
        In scenario 2, the ordering nodes are distributed. Thus there is no central organization with the power to crash the blockchain network alone.

        It's the power over the overall functionality of the blockchain network instead of the power over the ordering node which is the current Raft leader I was referring to.

        1. Yilin Sai

          Ah that makes sense. Thanks for the clarification!

  3. vaneet

    Robin Klemens  Si Chen Thank you for the great breakdown.

     Above looks great.  Perhaps, we can refine it bit more.

    Just one suggestion/or an idea

    For instance:  "Channel Operator "  - i do not think we need this extra layer for first version of MVP.   as per my understanding, auditor is good enough for writing data to the channel .

    Utility service providers , most of them are already trusted/ authorized parties from government, and once they sign into the platform, there must be some contractual liabilities for not providing right data, and business side of such would have licenses and etc in place before on boarding such type organizations. and i think MSP is handling some work of channel operator.  What do you think ?

    I still think that some parts of the whole platform could be done with traditional client server and other parts do the blockchain for taking best from blockchain and best from existing infrastructure we have in place,  for instance channel operator part could be done by  micro services using protobuf over RPC perhaps. With this, we can get to understand the external integrations capabilities and challenges to design next version on blockchain with fine granularity. Perhaps this is not feasible but this is just an idea.


    question

    Peer Node operator sounds very good.  Does this mean independent operators across who can help scale the infrastructure aka like peer 2 peer music sharing platforms back in old days.


    " Link to raw utility bill data on IPFS, encrypted (Question – how should this be encrypted?  With customer's public key so that it can only be decrypted by customer?) "

    Suggestion: /  Let customers use their encryption for accessing. Perhaps we can provide something like OATH 2

    https://www.synopsys.com/blogs/software-security/oauth-2-0-vs-oauth-1-0/


    absolutely agree with below points.

    Note also that:

    • the Utility does not have to participate in the channel.  It can continue to do what it does today.
    • the Auditor does not have to maintain anything on an ongoing basis.  Once it files the CO2 emissions data on the channel, it is finished.


    Thank you again for the great work.

    1. Si Chen

      Hello vaneet

      Yes, I can see some other peers participating to scale the infrastructure, in return for a small fee paid to maintain it.  See my comment at the bottom of Multi Channel Data Architecture also.

      Interesting point about storing the utility bill raw data.  I think you and Robin Klemensare talking about a similar concept?  Let me do some more research as well.

      1. Robin Klemens

        vaneet Si Chen

        "Suggestion: /  Let customers use their encryption for accessing. Perhaps we can provide something like OATH 2"

        Should the utility bills also be accessible by the auditor/regulators of the channel? Then, we cannot use the costumer's private key to encrypt the data and we need some different sort of encryption. I'm not sure how OAUTH 2 fits in there but I'm open to discussions :)

        1. Nish Chan

          vaneet Si Chen Robin Klemens Good ideas going there. Thank you for detailing your thoughts!

          With regards to encryption, I thought we were thinking of using Aries that lets Customers to create an ID and use that ID to access their data. Aries has their own encryption in place, where they need a Private Key to access the data.


          OAuth on the other hand is also a great tool. Rather than using the keys provided by the system, you could use a mixture of OAuth and OpenID that works one-one with the Sovrin system.


          1. Robin Klemens

            Wow!! Bringin Aries to this would be the next level sh*t. I'll spend some thoughts on this and am looking forward to brainstorming the idea with the SIG.

            Still, we need to make sure access to the utility bills is guaranteed to the auditors. Correct?

            1. Nish Chan

              I had brought this up during the first call with SIG. Not sure where it got lost.

              However, I remember Martin Wainsteinmentioning this during our last call, and the idea of bringing this discussion with the Aries group.

              I'm not sure about the access to the utility bills to the auditors being default. After all, auditors are also 3rd party and need a customers permission. Si Chen can you please elaborate on this?

              1. Si Chen

                Nish Chan Yes that's true.  This is the process – I added this to the page:

                • Customer contacts Auditor to request that its CO2 emissions from its Utility bill be calculated.
                • Auditor sends an authorization request for data access from the Utility to the Customer.  This could be an emailed link or a paper document, see Green Button standards.
                • Customer grants the authorization request, by clicking on agree or sending back the paper document.
                • Utility grants Auditor access to Customer's bill data.


          2. Si Chen

            Robin Klemens vaneet Nish Chan I created this github task https://github.com/opentaps/blockchain-carbon-accounting/issues/5 just about this.  We can look at these different options for storing the utility bills.

  4. Si Chen

    Robin Klemens Tadisetty Subbha praveen Paul Klick Nish Chan Peter Clarke Thanks for being on the call yesterday.  I've updated this use case based on some of what we've discussed.  I think we have enough to get started here.  There are a lot of additions we can make, like private data, security for the raw data, adding more nodes, security certificates later.

    1. Robin Klemens

      Si Chen Thank you for incorporating the feedback of our last call. This should be enough to get started next Tuesday and we should fail early and iterate again instead of spending multiple weeks in planing.
      Concerning the "Set Up the Channel" section. I felt like that we agreed on a set up consisting of three organizations where each organization takes the role of an auditor (for the first draft). Further, each organization would host 1 peer node, 1 ordering node, and 1 certificate authority. This would make the prototype a little more complex but also more robust in terms of fault tolerance. Because if the network is base on 2 orgs, 2 peers, and  2 orderers not any part of the infrastructure as well as an organization should fail/be faulty. Otherwise, the network would stop working.

      1. Si Chen

        Robin Klemens We can have 3 auditors, but it is not possible to have the orderers be the same as the peers.  See https://github.com/litong01/minifabric/issues/52.  There's also a link to a Fabric Q&A 

         https://hyperledger-fabric.readthedocs.io/en/release-1.4/Fabric-FAQ.html#ordering-service -
        "Question: | Can I have an organization act both in an ordering and application role?

        Answer: Although this is possible, it is a highly discouraged configuration. ..."

        I tried to have 2 organizations as Orderers, but at least with minifabric got the error 

        Error: got unexpected status: SERVICE_UNAVAILABLE -- no Raft leader

        So far I can only get it to start up with 2 orderers in the same domain, like

           - "orderer1.operator.com"

           - "orderer2.operator.com"

        We can talk about that some more during our call next Tuesday.

        1. Robin Klemens

          Si Chen

          I’ve done some research on having orderer and peer nodes in the same organization. Since Hyperledger Fabric uses Raft ordering service, the orderer nodes can run in different organizations and be in different clusters which weren’t possible with Kafka. Technically, this works and I’ve verified the proposed configuration of 3 orgs with 1 peer and orderer each in different Kubernetes clusters. Also, take a look at the Medium article of KC Tam.

          “If I use fabric-ca in combination with `NodeOUs` and set up the `configtx.yaml` file accordingly I don't get the points why not to configure the network this way. Also the actual version of the sample `configtx.yaml` file (https://github.com/hyperledger/fabric/blob/master/sampleconfig/configtx.yaml) puts orderer nodes and peer nodes in the same organization.“ (I posted the question we are talking about to the Hyperledger Fabric rocket chat)

          However, there is still one valid point in separating ordering and peer organizations. If one organization hosts both orderer and peer it has access to all the data of the ordering node. The ordering node could have data stored which isn’t meant for the organization, e.g. data of a different channel. Thus, the organization could access data illegally.

          If we consider the hosts of the network trustworthy, the above-mentioned potential risk of security in terms of separation of concerns, could be neglected.

          I’ll keep you updated as soon as I get feedback from the Hyperledger Fabric community.

          1. Si Chen

            Robin Klemens Tadisetty Subbha praveen Nish Chan

            Good question.  I think the emissions auditor as a service provider who would provide the audited CO2 emissions for a company.  That could include a variety of services, including reviewing the accuracy of the data from the company, running software to calculate the emissions, and filing it on the blockchain, plus customer service (smile)  So it could be part of the auditor's service to run the chaincode and record the results on the chain.  But maybe it could also be set up so that those auditors don't touch the chain code or the chain – they just work with blockchain operators, or with entities which supply the algorithms as open source code and run the blockchain.  It could work a variety of different ways.

          2. Si Chen

            Robin Klemens There was some good discussion on the main fabric list about this: https://lists.hyperledger.org/g/fabric/topic/76214410#8878

            What do you think?

            Is there some benefit to having orderers and peers in the same organization?  Otherwise it's better not to add a requirement that the hosts of the network to be trustworthy.

            But in any case, the same chain code could work on a network where the orderers and peers are or are not in the same organization, right?  So this can be resolved at deployment?

            1. Robin Klemens

              Si Chen Thanks for posting this to the fabric list. The discussion is great.

              In a production-ready system, I prefer the separation of peer and orderer organizations with two different MSPs and different fabric-CAs.

              For the sake of simplicity, I would stick to our current set-up, which is great for the prototype we are building. If we consider the separation crucial to the overall prototype, I could adjust the config files and scripts. 

              However, the configuration of the above doesn't affect the application and/or chaincode at all.

              1. Si Chen

                Robin Klemens Sounds good.  Let's do it that way.

    2. Nish Chan

      Si Chen Thanks for the feedback yesterday. Here's a high-level DFD/ UML that we talked about. I understand there is a need for 2 auditors, but this diagram should suffice for comprehensive purposes. We can make it better as we move further. Do let me know if you have any questions or feedback.

      1. Si Chen

        This looks right to me.  How about you edit the wiki page and put it in the main section?

        Also I think vaneetwas thinking about user stories.  Maybe he should take a look at it too.

        1. vaneet

          Nish Chan its good (smile) as you said, we can make it better as we move


          some suggestions. i aint expert in sequence diagrams.

          Perhaps we can provide demarcation 

          services outside blockchain

          services in blockchain

          services requiring authentication and authorization and see which part cross over

          can help in giving us a sky view of the building model, and help programmers dive into the right module


          1. Nish Chan

            vaneet That does go in-depth. I found a lot of use cases in the Indy and Aries repo. Maybe we could use that, or let me see if I get all these data together before next Tuesday.

            Thanks for your input. (smile)

        2. Tadisetty Subbha praveen

          Nish Chan Should we have the transactions 1,2,3,4 on the channel and also the conversion to Co2 emissions will be a smart contract on the channel.

          1. Robin Klemens

            Great questions Tadisetty Subbha praveen

            It depends on how we see/define the role of the auditors and what we want to store to the blockchain. As Si Chen mentioned in one of the comments above “Finally, the good news is that calculating emissions from kWH used is relatively simple.  The utilities are required to report their power mix in that eGRID database, so we can just use that and multiply by the kWH.“

            In the prototype, auditors host the blockchain infrastructure aka peer&orderer nodes. Further, each auditor has its fabric-ca (certificate authority) and can generate valid certificates for the users of the channel. At least, that’s what we have agreed on.

            What we still have to define is what parts of the business logic (e.g. converting kWh to CO2 emissions) will take place off-chain (e.g. manual paper-based, microservices) vs. on-chain (Smart Contract/Chaincode).

            1. Tadisetty Subbha praveen

              Thanks Robin Klemens for the explanations.

              For suppose if all the transactions (utility bill details (IPFS) and conversion to Co2) were kept out of ledger and only the converted value is kept in ledger. How do we trust the data published by auditor on the ledger without utility, consumer without participating on the channel.

              I may be wrong on understanding on how auditing companies does verification of utility bills and provide the carbon credits. Please do share any materials if it exists for current process.

              Si Chen Robin Klemens

              Apologies for asking many questions, these questions may be invalid for the current scenario but would help me in designing similar use-case.

              1. Si Chen

                Robin Klemens Tadisetty Subbha praveen

                I'm thinking the business logic of converting KWH to CO2 emissions happens on chain.  It is just

                find emissions factor for utility

                multiply by KWH

                The utility bill we were talking about storing somewhere, encrypt/oauth/aries – still deciding!

                1. Robin Klemens

                  Si Chen Tadisetty Subbha praveen Nish Chan

                  If "the business logic of converting KWH to CO2 emissions happens on chain" what will be the role of the auditors besides hosting the blockchain infrastructure and executing chaincode (maybe also define chaincode)?
                  Do we need the "auditor" as an intermediary as in today's accounting business or should we eliminate respectively reduce the need for the auditor as the chaincode does all/most of it? Thus, the trust we give to the auditor would decrease to the pure operational management of a part of the blockchain network. The trust in auditing of carbon account would be established by distributing the blockchain infrastructure to independent parties and reached by consensus among them. 

            2. Si Chen

              Tadisetty Subbha praveen Rob Thatcher See some of the github tasks I created: https://github.com/opentaps/blockchain-carbon-accounting/issues  Maybe that gives an idea of what should be in the smart contract?

          2. Nish Chan

            Tadisetty Subbha praveen Based on the feedback from Si Chen and Robin Klemens , I think so far the data connections seems to be fine. 

            Regarding the conversion of Co2 emissions, you're right. I might have to revise that. 

            Thank you for your feedback!

  5. Tadisetty Subbha praveen

    Si Chen Robin Klemens Do we intend to create a certificate for every user subscribed to a utility company. Also to grant permission for accessing the utility bill , will that be a transaction which needs to be endorsed utility and consumer?

    1. Si Chen

      Robin Klemens Tadisetty Subbha praveen

      1.  Yes, I think we will need a separate certificate for every user.
      2. Yes, to grant permission to utility bill is a transaction that needs to be endorsed by the customer.  This is described as part of the Green Button standard.  It could be done either through signed paper documentation (seriously) or through a third party service like Utility API.  I think this should be separate from the channel.

      1. Tadisetty Subbha praveen

        Si Chen

        Okay, if the user's are created by audit companies as and when the user want's to participate on the channel.

        1. Si Chen

          Tadisetty Subbha praveen I don't think the users are created by audit companies.  They're other parties on the channel.  They may request different auditors over time.  Maybe the right way to think about the channel is a group of utilities, auditors, and customers of utilities.

  6. vaneet

    Si Chen Robin Klemens I have been reading the comments for past few weeks. I was busy at work.

    Robin Klemens any help in creating micro service architecture or code, let me know.

    Also, can give a hand in other stuff (smile)

    Regards


    1. Si Chen

      vaneet thanks so much.  If you have some time take a look at https://github.com/opentaps/blockchain-carbon-accounting/issues

      In particular I think storing the published emissions statistics and looking them up would be a great micro service, for example running on amazon lambda.  If you’re interested in trying that let me know.

    2. Robin Klemens

      vaneet great to have you on board.
      Of course, you can support development.
      Two things. First, what are you interested in, and second, what are your skills. 
      Having a look at the issues in GitHub is a good starting point. Furthermore, it would be great having you on our Peer Programming Call-In on Monday, 14 September 2020.

  7. vaneet

    sure (smile) Do we have amazon account ?

    Btw, i love your project openTabs. 

    Regards

    Vaneet

    1. Si Chen

      You can just write node.js and then running it in lambda is simple: https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html

      As for where to store data, I still would like to try orbitdb