RFC: Linking entities + canonical spaces for an entity

[baiirun]

This RFC outlines a design for linking entities to a specific space and surfacing "canonical" spaces for entities that are curated by the current space.

Motivation

Users are able to link to specific entities using the ENTITY value type or by adding them to a collection. Entities are able to exist in many spaces at once, and anybody can add data to any entity as Geo is permissionless.

We need a mechanism that enables users to link to the view of an entity in a specific space while also enabling users in a space to generate social consensus as to whether that link points to the "canonical" view of that entity. What makes a space "canonical" or not is defined by the users of the space itself and can mean whatever they want.

Assumptions

• It's okay if the social consensus on a "canonical" entity or space is different than any onchain state that might represent the entity. For example, we have onchain profiles that represent the Person entity for a user that joins the Geo knowledge graph. This onchain state may not match a "canonical" entity as defined by a space. We want to decouple social consensus from technological consensus.
• Spaces for a link are optional. If no link is defined we'll rely on a fallback mechanism to determine which space to navigate to. Users can add a space to the link at any point. To start, the fallback mechanism is the defined canonical space, else some other default heuristic. Eventually we'll rely on curation as part of this model.

Design

The goal is to decouple the linking mechanism in Geo from the "canonical" representation of an entity within a space. Linking to an entity is comprised of two components:

1. Defining the space link itself and the entity id itself
2. Signaling that this space link is to the "canonical" representation of the entity as defined by users of the space

Defining the space link

The space link is an optional field that denotes that a reference to an entity should link to a specific space. There are two potential designs

1. A space triple on the collection item being used to reference the entity
2. A space property on the ENTITY value referencing the entity

1 only supports links to entities that are defined within a collection. It does not support a triple pointing to an entity using an ENTITY value type.

2 supports both collections and arbitrary triples pointing to an entity since the space is stored on the entity value itself. It would be an extension of the v1.0.0 design for an ENTITY value type that adds an optional space property to the Op's value denoting a specific space the entity value points to. The Op data model for the second design might look like this:

type EntityValueOp = {
  opType: 'SET_TRIPLE';
  payload: {
    attributeId: string;
    entityId: string;
    value: {
      type: 'ENTITY'
      value: string; // points to the entity id being referenced
      space?: string; // points to the space address (?). Is optional.
    }
};

Designing the canonical representation per-space

The canonical state is some piece of data that denotes that an entity has gone through social consensus and the space agrees on which space represents the view of an entity.

A space can define an entity's canonical space by adding a Canonical Space attribute to an entity in their space. This describes to the rest of the space how this particular entity should be canonically viewed within the space. For example, the entity of "San Francisco" can be defined in Space A as being canonical if viewed within Space B. Each space can create their own Canonical Space triple for each entity that they want to canonize. This allows us to have many views on a single entity across many spaces while enabling spaces to define specifically how they view an entity.

Questions

• What is the value of a Canonical Space triple? A string or an entity? If it's an entity what is it?

Out of scope

• We might want to handle editors and members the same way in the future, where the space decides how they’re represented in the space. For now we’re leaving it as is where we rely on the onchain profile representation
• Derived data like queries in data blocks aren't able to specify links to a specific space

UX considerations

• Need a good way to surface the Canonical Space triple in proposals so it's clear that users are voting on introducing a new canonical space for an entity
• Need to surface "canonical space" for an entity more prominently in the UI, similar to how we do Types
• We may want to render triples from the canonical space in the current space if the entity has defined a canonical space

[baiirun]

What is the value of a Canonical Space triple? A string or an entity? If it's an entity what is it?