feat(api): Account, space and governance medata

[cvauclair]

Motivation

Even though the data service is mostly concerned with indexing triples for all (or some) spaces, there is also a need for indexing and storing metadata such as accounts, spaces and governance data.

This data is useful in many scenarios, such as viewing past edits to a space, or browsing active proposals. In the context of an app like the typesync app, the following user flow should be possible:

• user opens app
• we pull their local spaces/entities
• when they authenticate
  • pull their personal space from the KG
  • pull any spaces of type=App that they creates through the typesync app

Note that spaces can have both a governance type (Personal or Public, which is determined by onchain contracts) as well as a more "functional" type (e.g.: the space is about a Person, Company, App, etc. determined by a relation in the KG)

Data Modelling

The current KG data service stores account, space and governance metadata as GRC20 triples defined in a special "INDEXER" space (space id Y7z7eeWdupgZayxG9Lvi2Z).

As such, the data is queryable by default by selecting entities belonging to the "INDEXER" space. E.g.:

# This query returns all entities in the indexer space that have an attribute with id `space_plugin_address`, as well as a `type` attribute with value `Public`
# Note: We don't have GRC20 ids for a lot of the attributes in the indexer space yet!
query { 
  entities(
    spaceId: "Y7z7eeWdupgZayxG9Lvi2Z", # Indexer space id
    where: {
      attributes: [
        {attribute: "space_plugin_address"},
        {attribute: "type", value: "Public"},
      ]
    }
  ) {
    id
    createdAt
    attributes {
      attribute
      value
    }
  }
}

Note: This "indexer space" is only partly populated with proper types at the moment, which limits the usefulness of the API at the moment. Part of this epic is to fully populate the space.

API

Even though it is already possible (in theory) to query all account, space and governance metadata as GRC20 triples, there is an argument to be made to have dedicated GraphQL types and queries to fetch this data, most notably because they are so important for proper functioning of the knowledge graph.

Here are a few ideas that have been thrown around on how this could be achieved.

Idea 1. Add account, space and governance types to existing API

The idea is straightforward: we add some new GraphQL types (see below) to model this metadata explicitly. These would simply be a wrapper around the existing triples data for these entities.

Some rough idea of added types (not exhaustive):

# Schema level
type Account {
  id: String!
  address: String!
}

enum GovernanceType {
  Public,
  Personal,
}

type Space {
  id: String!
  governanceType: GovernanceType!
  type: String!
  members: [Account!]!
  editors: [Account!]!
  # other fields
}

# Query level
query {
  personal_spaces: spaces(
    where: {
      membersContains: ["MY_ACCOUNT"],
      governanceType: Personal,
    }
  ) {
    id
    # other fields
  }
  
  app_spaces: spaces(
    where: {
      membersContains: ["MY_ACCOUNT"],
      type: "App",
      # some other filter
    }
  ) {
    id
    # other fields
  }
}

Idea 2. Separate API

It was suggested a few times that it would make sense to separate the actual KG data from the KG metadata by separating them at the API level. This separate metadata API could then be implemented by the same data service, or another data service entirely!

This has the disadvantage of making it impossible to make a query like the following (hypothetical) query:

# This query mixes KG GRC20 data with metadata by selecting the author of the edit that created the entity in the space
query {
  entity(id: "SOME-ID", space_id: "SPACE-ID") {
    id
    name
    
    # This field is of type `Edit`
    initialEdit {
      author {
        address
      }
    }
  }
}

That being said, the second idea might scale better at a later stage since it might become unrealistic to expect all indexers to also index all metadata. Moreover, I am about 70% sure that a account, space and governance metadata only data service can be implemented as a simple subgraph since this data is mostly in the form of onchain events