Chatafisha Goals

1. Build a flow similar to Verifiable Credentials (VCs) but for issuing impact certificates and corresponding evaluation attestations (approve evaluations trigger issuing carbon credits).
2. Incorporate impact types & design principles from:
   • Schema Libraries (especially scalar types)
   • Impact-Oriented Funding Cycles
   • Potlock Impact Scoring System

Blockers/Action Items

1. Finish defining attestation schemas with Chatafisha (Chatafisha: “Impact Calculator”)

   1. Impact Claims
   2. Impact Evaluations
   3. User Profiles

2. Create a way to programmatically publish:

   1. Impact claims from projects/contributors
      • evaluation attestations from verifying entities linked to specific impact claims
      • attestations from carbon credit issuers referencing the impact claim & details about credits being issued (e.g.
        • The carbon issuance attestation would then be referenced in a carbon-backed NFT
   2. Impact evaluation attestations from projects & members in an organization to:
      • other members
      • external parties (e.g. a collaborator)

Ideas

“Generic Impact Attestation Type Creator”

• Need to define “Impact Attestations” & scope of the type creator
• Idea: flexible metadata field specification
• Idea: use a subset of curated types from Schema Libraries
• Is this just another way to describe Hyperfiles?
  • Potential Issue: How to take arbitrary inputs and calculate reliable outputs?
    • Solution Idea: different attestation types need to be “related” the same way tables in a relational DB do, through a single “key” field that maps the two data structures.

Programmatic Support: VM Support / SDK Workaround

Problem: Hyperfiles doesn’t have an SDK or way for projects & users to programmatically publish data objects using specified schemas & types

Solution Idea #1: create an SDK following steps used to create the everything SDK

Solution Idea #2: template components, notifications, and/or dummy accounts

1. Projects could fork & deploy a template component that acts as a registry & hook.
2. Projects would then use near-sdk or near-api to make set calls on social.near to publish an opcode requesting Hyperfiles take an indicated action.
   1. Setup the template so Hyperfiles receives a notification when the template is forked, and also when projects publish opcodes.
   2. Build a function triggered by notifications that a specific widget has been forked, then registers the owner of that widget as a new project.
   3. Build a function triggered by opcode publishing that matches the opcode to a specific action, such as publishing a schema of a specific type

• Alternative Idea: enable projects like Chatafisha to request an “API Key” that grants them permission to write to dummy account
  • Limited function call access key on a dummy account controlled by Hyperfiles