W3 Identifiers

Spaces

We identify mutable spaces via DID URIs, because unlike any other identifier they have provable ownership, which is really important for mutating them in an open, trustless protocol. Specifically only owner of the space can authorize mutation by delegating capabilities through UCANs.

ℹ️ Space is just collaboration tool allowing groups of agents to cooperate on. It is a name space and not a memory space or a compute space, although those could be abilities that space can aquire through memory and compute providers.

In order to enable cooperation participating actors need to prove they had been invited to do so by space owner, which is why we need provable ownership.

I think it is a good idea to think of the space as an IPNS or an MFS - A mutable pointer to an IPLD DAG. We may not have an actual materialized IPLD DAG for a space but we do define set of capabilities for querying and updating mutable pointer to transformed revisions.

You can think of compute as a sub-DAG, a map where keys are invocation CIDs and values are results of that computation.

In theory anyone could query CID (that space corresponds to) using same set of capabilities without owners permission. It is resolving and updating a pointer what requires permissions.

Rationale

For example consider following UCAN delegation and ponder how can arbitrary validator tell whether iss is owner of the resource file:///alice/photos/ to issue such a delegation ?

{
  "iss": "did:key:z6Mkk89bC3JrVqKie71YEcc5M1SMVxuCgNx6zLZ8SYJsxALi",
  "aud": "did:key:z6MkffDZCkCTWreg8868fG1FGFogcJj5X6PY93pPcWDn9bob",
  "att": [
    {
      "with": "file:///alice/photos/",
      "can": "file/write"
    }
  ]
}

On the other hand following delegation is self-evident to any validator, because resource (with) matches issuer (iss) and UCAN signature must be from the issuer key, wihch provides cryptographic proof that resource owner has authorized the delegation.

{
  "iss": "did:key:z6Mkk89bC3JrVqKie71YEcc5M1SMVxuCgNx6zLZ8SYJsxALi",
  "aud": "did:key:z6MkffDZCkCTWreg8868fG1FGFogcJj5X6PY93pPcWDn9bob",
  "att": [{
    "with": "did:key:z6Mkk89bC3JrVqKie71YEcc5M1SMVxuCgNx6zLZ8SYJsxALi", 
    "can": "file/write",
    "nb": { "at": "/alice/photos/" }
  }]
}

ℹ️ Also note that in the first example we had captured space semantics (like "file system" as opposed to "communication system") in both URI schema file:// and UCAN ability namespace file/

Considered alternatives

We could have addressed resource ownership in a different way for example using autority fragment of the URI like illustarted in the following example

{
  "iss": "did:key:z6Mkk89bC3JrVqKie71YEcc5M1SMVxuCgNx6zLZ8SYJsxALi",
  "aud": "did:key:z6MkffDZCkCTWreg8868fG1FGFogcJj5X6PY93pPcWDn9bob",
  "att": [
    {
      "with": "file://z6Mkk89bC3JrVqKie71YEcc5M1SMVxuCgNx6zLZ8SYJsxALi@/alice/photos/",
      "can": "file/write"
    }
  ]
}

With such approach validator can still deduce that issuer (iss) has authority over a resource (with) because issuer key matches resource authority (z6Mkk89bC3JrVqKie71YEcc5M1SMVxuCgNx6zLZ8SYJsxALi).

However this approach has couple of downsides:

1. It makes it possible to have invalid delegations e.g. file:// resource (with) coupled with message/send ability (can). In other words it would create more error surface to deal with.

   Note that use of DID in resource does not have that problem because semantics are in the ability namespace file/ and not in the resource.

2. Some URIs do not have authority (despite URIs specification), in pratice this means built-in parsers normalize some by stripping authority out which can lead to problems in the wild. E.g. browsers will normalize URI from the example into file:///alice/photos/.

3. In the end we still have to parse URI to exract authority & path from it. Our approach is basically parsed version authority is a resource (with) and path is the nb.at eliminating problems that could arise through incompatible parsers across languages and limitations around what character set can be used in auhority.

Finally there is one other alternative that has been considered which avoids some of the issuen from the above

{
  "iss": "did:key:z6Mkk89bC3JrVqKie71YEcc5M1SMVxuCgNx6zLZ8SYJsxALi",
  "aud": "did:key:z6MkffDZCkCTWreg8868fG1FGFogcJj5X6PY93pPcWDn9bob",
  "att": [
    {
      "with": "https://[e-mail]/alice/photos/",
      "can": "file/write"
    }
  ]
}

Because it is an HTTP(S) URL authority semantics are well defined which we can embrace to avoid URI parsing issues and we avoided enconding semantics in the resource which gives us robustness. However we still end up just encoding path in the resource which needs to be parsed out as opposed to just encoding parsed version.

More importantly we have also introduced depndency on DNS, which implies that we can not represent capability of writing a file into my laptop which does not have domain name. This is not moot point as it turns protocol from trustless to one requiring it & limits participation.

We could define another URL schema e.g. space:// that requires no DNS (and is similar to ipns://), but it's unclear what it will get us besides whole lot of work for specing and standardizing it. It would allow us to encode authority and path together but introducing additional parse is somewhat questionable benefit, not to mention that for some capabilities path may not even make sense.

Provable ownership in data

It is worth calling that important detail is provable ownership & that is certainly possible to do it at the data layer. For example IPLD DAG could encode permissions at each node which can be consulted to validate ownership. In fact DID documents could also be resolved to identify who can modify it (even if spec is bit fuzzy on how).

While it's very reasonable to go this route, it does introduce a mutable state into a system. Ownership becomes non-straigtfoward one needs to do out-of-bound resolution to decide, furthermore mutable owenership in untrusted settings would often require centralization to handle races and network partitions.

Added complexity does outweight the benefits for the web3.storage. It seems better to pursue some of those benefits in a different way e.g. we could embed permissioning into DAGs by introducing interior mutability through did:key pointers.