WIP: Draft up identity specs for delegation

[jsantell]

First draft of defining how delegations work for namespaces, spaces, and charms

[cubic-dev-ai]

3 issues found across 3 files

Prompt for AI agents (all 3 issues)

Understand the root cause of the following 3 issues and fix them.


<file name="docs/specs/delegation.md">

<violation number="1" location="docs/specs/delegation.md:29">
Replace “responsible from” with “responsible for” so the sentence reads correctly and the responsibility is unambiguous.</violation>

<violation number="2" location="docs/specs/delegation.md:35">
Use the plural verb “are” so the subject-verb agreement is correct and the sentence reads naturally.</violation>
</file>

<file name="packages/identity/src/url.ts">

<violation number="1" location="packages/identity/src/url.ts:28">
The parser drops any path segments beyond the first three address components, so a malformed URL such as &quot;/@ns/space/charm/extra&quot; is treated as valid instead of throwing. Please reject paths that contain additional segments after the charm component.</violation>
</file>

_{React with 👍 or 👎 to teach cubic. Mention @cubic-dev-ai to give feedback, ask questions, or re-run the review.}

[cubic-dev-ai]

Use the plural verb “are” so the subject-verb agreement is correct and the sentence reads naturally.

Prompt for AI agents

Address the following comment on docs/specs/delegation.md at line 35:

<comment>Use the plural verb “are” so the subject-verb agreement is correct and the sentence reads naturally.</comment>

<file context>
@@ -0,0 +1,110 @@
+&gt; [!NOTE]
+&gt; There may be a way to view a namespace, like itemizing all contained spaces, but is out of scope here.
+
+Additionally, delegations for access to the namespace is stored in the admin space as well. See **CAPABILITIES** below for delegation.
+
+### Namespace Admin Space
</file context>

Suggested change

	Additionally, delegations for access to the namespace is stored in the admin space as well. See **CAPABILITIES** below for delegation.
	Additionally, delegations for access to the namespace are stored in the admin space as well. See **CAPABILITIES** below for delegation.

[cubic-dev-ai]

Replace “responsible from” with “responsible for” so the sentence reads correctly and the responsibility is unambiguous.

Prompt for AI agents

Address the following comment on docs/specs/delegation.md at line 29:

<comment>Replace “responsible from” with “responsible for” so the sentence reads correctly and the responsibility is unambiguous.</comment>

<file context>
@@ -0,0 +1,110 @@
+
+Namespaces can be referenced via DNS record, resolving to a DID key, or via directly as a DID key. Similarly, a provider-namespace is implied when no namespace given, which also resolves to an identity DID. 
+
+Namespaces manage many spaces, and are responsible from mapping space petnames to their identity.
+Each namespace has an &quot;admin&quot; space (possibly with the same identity as the namespace itself?), where records are stored.
+
</file context>

Suggested change

	Namespaces manage many spaces, and are responsible from mapping space petnames to their identity.
	Namespaces manage many spaces, and are responsible for mapping space petnames to their identity.

[cubic-dev-ai]

The parser drops any path segments beyond the first three address components, so a malformed URL such as "/@ns/space/charm/extra" is treated as valid instead of throwing. Please reject paths that contain additional segments after the charm component.

Prompt for AI agents

Address the following comment on packages/identity/src/url.ts at line 28:

<comment>The parser drops any path segments beyond the first three address components, so a malformed URL such as &quot;/@ns/space/charm/extra&quot; is treated as valid instead of throwing. Please reject paths that contain additional segments after the charm component.</comment>

<file context>
@@ -0,0 +1,65 @@
+}
+
+export function parseCharmAddress(url: URL): CharmAddress {
+  const [prefix, ns, space, charm] = url.pathname.split(&quot;/&quot;);
+  if (prefix || !ns) throw new CharmAddressError();
+  if (!space &amp;&amp; charm) throw new CharmAddressError();
</file context>

[seefeldb]

+1, interestingly i think this could just correspond to the ability to create URIs whose hash is just derived from the space did, not some other URI that's already in the space. (assumes we restrict this, which we currently do, but sometimes consider since it guarantees unforgeable identifiers)

[seefeldb]

added a few comments there, but the most relevant is just to suggest that the top-level part must resolve to a space (either by being a DID, a DNS lookup or using the provider resolution), and then each subsequent component can be a lookup in that space that leads to another space, and so on.

i also added a comment there proposing that the default way to resolve components in a space is by deriving a URI from the slug and the space DID, which can then contain a link to the actual charm, or a space redirect. see below on how that maps to the CREATE capability.

[seefeldb]

there's a bunch in the PRD about provider-based names being disambiguated with an appended short hash, hopefully making them globally unique. maybe that happens as part of creating the key (see next paragraph)

[seefeldb]

i think that's implicit, but that delegation also removes did:key:alice-space from the owner list, right? i.e. if there is no ACL then the assumption is OWNER:, and the typical bootstrapping flow replaces that with others, taking the original DID out?

[seefeldb]

I think we can start with today's derived-from-name spaces for now and focus on adding ACLs.

Effectively ~ partitions the namespaces per user, but we could just choose to not use that.

In a way it's the most simple implementation of provider-level lookup and we can just grow it from there.

[seefeldb]

as noted above, it might be sufficient to go straight to the next step, at least to start.