Table of Contents

<aside> 🧠 EAS Build Idea: Using Attestations to Construct Social Graphs

Ethereum Attestation Service

</aside>

Touchpoints for EAS <> Hyperfiles

Near Attestation Service (NAS): onchain frontend components implementing EAS standards

  1. Hyperfiles uses a social graph smart contract as our “registry” (**NEAR socialDB)**
    1. Schemas and attestations are saved under top-level keys (user accounts)
      1. e.g. accountId/schema/uid and accountId/attestation/uid
        1. Objects are uniquely identified by a human-readable path instead of a UID

          1. Schemas are named by default

          2. Improves discoverability of schemas

          3. Users can easily “import” schema libraries from each other to reuse or fork

          4. Implications for Object Categorization: Names and Tags

            1. Compare to EAS schema names (and frontend regulation)

            Untitled

Hyperfiles ⛓️🧠: data (source) adapters & indexing data objects

Import data from EAS indexer to:

  1. Hyperfiles Data Objects ←can register→ EAS schema content (e.g. “True)
  2. Hyperfiles References ←can register→ EAS attestation content (e.g. metadata w/ nested schema data)
  3. Hyperfiles Types ←can register→ EAS Schemas (e.g. isBuilder=”boolean”)

Challenges & Opportunities

  1. Mutability of reference objects

    1. Data on socialDB can be modified or deleted by the owner at any time. This can easily lead to broken references via changes in schema definition (property names, value types/primitives), attestation content (whether isBuilder=True or False), and probably other things I didn’t think of yet.
    2. If we lean into this it could enable “dynamic schemas” and automate normalization
      1. Type Checking

  2. Optional non-revocability of attestation validity

    1. Solved by adding/removing accountIds to recipient fields (accountId not present = revoked). See “Badge Builder” example below.

  3. EAS schemas reference types

    1. attestWithTypes uses types to structure attestations directly (thereby excluding standardized fields for schema metadata)
    2. “Badge Builder” is more similar to EAS in that the badge contains pre-defined metadata fields analogous to EAS schemas (badges reference types)

  4. Chain agnostic BOS frontend components for EAS ABI

    1. EAS.sol ABI Specification on GitHub

    2. Example BOS component using Gitcoin Passport ABI

    3. Hyperfiles EVM Adapter

      1. Solidity ABI - Types: https://docs.soliditylang.org/en/v0.8.16/abi-spec.html#types
      2. Near Social Standards: https://github.com/NearSocial/standards
      3. Data Types | NEAR Protocol Specification (nomicon.io)

EAS vs. Hyperfiles for Attestations

  1. Hyperfiles are attestations. An attestation is a structured statement, or a claim, an opinion.
  2. Each Hyperfile follows a generalized structure, and it’s contents are specified according to a user-defined schema.
  3. Hyperfiles makes the assumption that attestation based claims are about something. This is practically implemented by creating corresponding reference objects to structured data objects.
EAS Hyperfiles
Schema Metadata (Name, Description, Context) None by default. Requires using standard schemas deployed by EAS to “attest” to each metatdata field Schema metadata fields are included in the schema type definition. Name is the object path & not required in metadata.
Private Data Requires using special “privateData” schema to create Merkle Tree via ethers.js TBD - goal is encryption by default
Generate Proofs for Content Can hash on/offline and use their web tool to verify a hash None yet
Indexed Attestations On request Always, via socialDB
Indexed Schemas Always, via SchemaRegistry.sol Always, via socialDB
Adapters for Import/Export Need to create an entire frontend to integrate EAS w/ new sources Publish data objects anywhere
Object Mutability (data and references) None Yes, can update or delete any data stored under user account
Attestation Revocability Set by schema, immutable Can be enable
Schema Field Types Solidity primitives only Any type (can import libraries from other users or define new ones)
Cross-chain Publish & Query Deployed to multiple EVM chains, but each is fully independent. Yes, and double-indexing will be implemented for references published off-NEAR.
Delegating Txn Cost Yes, via EIP-712. Yes, via relayer & meta-txns.

Open Questions

  1. How best to leverage the network effect of people using & building on EAS for scientific sensemaking?

    1. Filter & index relevant schemas + attestations
      1. Deploy schema library to socialDB under eas.hyperfiles.near

  2. Can the indexing and adapter features of Hyperfiles be a value-add for EAS users?

    1. Example: return every EAS attestation?

      “EAS by default doesn’t index attestations onchain. You can use the graphql endpoint or run your own indexer. If you require onchain indexing you can use the EASindexer contract to index and query attestations by schema id and attester/recipient” - Steve Dakh (quoted from Telegram)

      Relevant forum post: How to extract the list of attestations UIDs of a recipient using EAS-SDK? (answer in screenshot below)

      Untitled

    2. Should we index all attestations? https://docs.near.org/bos/api/social#socialindex

  3. Hyperfiles registry contract: features and requirements

  4. Refactoring the schema and attestation types on socialDB