Meeting notes: Regen / OADA / Trellis, structure and function for OpenTEAM members


Purpose: To clarify OADA/Trellis, GEMS and Regen Network’s core functionality, specifically:

  1. how they differ (by function, by occupying different markets, etc.)

  2. and how existing OpenTEAM members can utilize their services (the step by step)

  3. possible collaboration (if needed), clarity (for GEMS, OADA + Regen + users) to get improved uptake by OpenTEAM members.

Who’s here:

Users (farmOS, Our Sci, GEMS)

Devs (Regen, OATS)

Other interested folks!

Participants: Greg Austic (Our-Sci), Paul Weidner (farmOS), Aaron Ault (OATS), Gregory Landua (Regen), Ron (Regen), Aaron C. (Regen), Mike Stenta (farmOS), Kevin Silverstein (GEMS), Will Gardiner (Our-Sci), Dorn Cox, Jamie Gaehring (farmOS), Ankita


  • Data interoperability, traceability, security, appropriate privacy, maintain data connectedness (online offline), supply chain management (digital signatures)


  • OADA Demo by Aaron A.
    • runs in Docker w/ helpful shell script
    • plugins enable you to add microservices that OADA manages for you
    • basic test it’s working: https://localhost/.well-known/oada-configuration
    • summary: a discoverable framework for standardized API’s
    • API is built by the data you put in it
    • how to add OADA conformance?
      • add OADA as a caching layer
    • Primary value of oada
      • Creating new API it solves a lot of problems from the get go
      • Easier interop with people using your API (on top of existing API)
      • Does not - define data standards for data (like crop types or whatever)
  • Trellis Demo by Aaron A.
  • Regen Intro by Aaron C.
    • Proof of Stake based on Cosmos
    • Identity management
      • provide a more user-friendly interface for multiple individuals to manage an identity’s keys etc
      • decouple the key from the signature
      • timestamping when a signature was created
    • registry of schemas on blockchain
      • for sharing, discovering and evolving those schemas
    • on-chain governance (DAO’s) for organizations to manage resources
    • data discovery & monetization through tokens
    • Regen guarantees that a schema will remain stable and provides governance models for how changes to those schemas will change
  • General Discussion
    • Prompt from Aaron C.: Pick up the conversation next time on why to use OADA as an API spec vs other industry standards that have more momentum behind them? eg, GraphQL is or is not an API spec?
    • Aaron Ault: OADA is a way to move data more easily in a standardized way, when there is an existing REST API, Regen/blockchains would be where that data moves to.

Meeting 2

Friday 2p - 3p EST

Follow up last time:

  1. Technical discussion about libs / frameworks OADA / Regen (raised by @aaronc, discuss with @aultac) - create a separate forum post for Aaron and Aaron to clarify an important technical question - is OADA’s currently structure ‘good enough’ to be used as a basis for later markets which have governance applications and tokenization applications (ie decisions and money are on the line!). Community wants to know so we know if building on OADA now helps us build towards Regen later. Let’s get clarity here.
  • Starting with the OADA support seems an ok approach from Aaron C’s perspective and moving from there.
  • Or workshop session to hash it out on real applications.

Agenda, this time:

  1. GEMs capacity + tools on this topic. Help us understand how best to work with resources available from GEMs and how that fits into existing workflows

  2. Summarize where we got last time - what functions are, how they serve OpenTEAM members (direct utility), overlap and compliment.

  3. Questions raised since last time

  4. Thoughts on applications of OADA / Regen within the call. From each group, how can you use this. How much value? How important to existing dev path? What to do this year? If there’s technical questions

OADA applications this year

  • Kita: ISO Blue data from machinery → farmOS, between cover crop tools, from plan data service,
    • eg, take cover crop data, add context of farm mgmt data from farmOS, and move that data to the marketplace, using OADA to transport that data
  • for farmOS: can ISO Blue be used to track tractor data?
  • For Our Sci: digital signatures for quick carbon

Challenges to integration

  • Are we imposing a schema with OADA?

  • Can we just do digital signatures on our existing API’s?

    • can’t mutate data after you’ve signed it
  • Greg: We don’t have a strict need for OADA or digital signatures, but do we believe that in the future such initiatives will be worth adopting now?

  • Can we discuss specific use cases?

  • Stakeholders (researchers, farmers) primarily want data that they can have high confidence in and is low-cost to integrate with their own systems, and are less concerned with standardization or even collection methods