Aaron Craelius is really sorry that he couldn’t make it to the gathering this weekend. He did send some thoughts my way, and I thought it would be helpful to share them with the group and get some of your thoughts here so that he might get some of the feedback he is looking for. Please chime in:
I wanted to share my thoughts on some important things for us to be thinking about over the GOAT weekend from my perspective. Of course, we will be thinking about ways for Regen Network to interface with different OpenTeam partners. Beyond that, here are a few specific questions:
- what types of ecological data is being collected/exchanged?
- what is the structure of that data? what are key properties? for the less technical here, think columns in spreadsheets and fields in forms
- what is relevant for ecological agreements - both things like ecosystem credits, certifications, and multi-party contracts
Please thoughts on these questions and what you are hearing from others. Soon we’ll be gathering to collect everyone’s observations from GOAT and the OpenTeam webinars (http://goatech.org/category/webseries/). The big idea is to collect as much information as possible to be able to better design Regen Ledger’s and our SDK’s support for ecological data, as well as see how that data fits into better agreements. It would be best for us to understand the needs of the fellow OpenTeam members, so that we can build these in such a way that makes it easily interoperable and accessible to the other users.
What we have been intending to help build for the OpenTeam ecosystem is the ecological data layer that allows interoperability and the ability to anchor data onto Regen Ledger (both tracking hashes, signatures, and sometimes actual data).
The way I see this working is, we build or help build an SDK that can be integrated into any existing platform and that provides the following benefits:
- by integrating the SDK and implementing some service interfaces, there will be a standard way of pulling ecological data from the app in an interoperable format
- the SDK will allow apps to integrate with Regen Ledger so that they can be part of a cryptographically secure audit trail
- integrating with Regen Ledger will, in the long run, allow tokenized payment for data services
A few design principles that I have been holding for how to do this that may be different from how it is currently being thought both in OpenTeam and generally, but certainly worth sharing and opening up conversation around:
Durability - we need protocols and formats that are long-lived. This means backward and forward compatibility are key. Think internet level protocols like HTTP and TCP/IP
Upgradibility - we need to be able to gracefully upgrade the formats to evolve to changing requirements and understanding, while maintaining compatibility with older clients
Cryptographically auditable - we need to be able to use hashes and digital signatures to provide an audit trail
Immutability - we need to think about immutable chunks of data that have a stable hash, so that they can be cryptographically signed. If data keeps changing and we lose the old version, we can’t reconstruct an audit trail.
Ubiquity - we need tools that can work on all platforms and integrate with all program languages, so eventually the level of tool integration is high. This takes a bit of work, but can be done
See you all on Zoom.