Ability to fork a space

[Gozala]

We got a request to change email associated with an account (see thread) which is bit tricky because:

1. We need space to delegate access to the new email DID and user may not have private key for space to do it.
   • Old email could still delegate to new one, but that would create delegation chain did:key:zSpace → did:mailto:mail.com:old → did:mailto:mail.com:new which effectively keeps old email in change of the new one
2. We need to update billing so that bills go to a new email as opposed to the old one.

We can not simply change DB records here as it will break accountability and provenance.

I think proper solution is something we have discussed in the early days of the protocol design, which is we can not give access to your space to any other principal (mailto or key), however we can allow you to create a fork of the space if you are able to prove that you have access to the space you are forking.

To layout this in terms of capabilities following would make most sense to me:

{
  iss: ...
  aud: "did:web:web3.storage",
  att: [{
    can: "store/import",
    with: "did:key:zNewSpace",
    nb: {
        source: { "/": "bafy...store" }
     }
  }]
}

Where did:key:zNewSpace MUST be a provisioned space with enough capacity to store all the data from the provided source.

The source link MUST be bundled and be a UCAN that delegates following capability to the did:key:zNewSpace

{
  iss: "..."
  aud: "did:key:zNewSpace",
  att: [{ can: "store/list", with: "did:key:zOldSpace" }]
}

Put it differently we have a verifiable proof that:

1. new space is able to list everything stored in the old space (using bafy...store is delegation)
2. new space has authorized storing all the data in from other space.

If we have this capability along with compatible upload/import we could address request as follows:

1. Ask user to create another space and provision it as they want choose with whatever email they want.
2. Ask them to create a delegation authorizing new space to read from the old one, which can be done with any agent that has enough access.
3. Invoke store/import and upload/import capabilities on the new space.

After all above steps they'll have new space with new email and all the data they have previously uploaded. They may have to change some code / config in their system to use new did:key, but that is the tradeoff they made when they decided to not retain the space key.

[Gozala]

As a side note, we also have kept punting on another idea that may have greatly simplified all of the above that might be worth revisiting here. Specifically we would like to represent your store and upload state as an IPLD DAG, probably as a UnixFS dirs. If we had that we would not need permission from old space to import data into new space. We could instead have source: { "/": "bafy...store" } link to the IPLD DAG represent state of the store.

Perhaps we could implement store/export capability to create such a DAG on demand ? That way not only we would simplify things we would have pretty credible user exit strategy.

We could also limit number of free store/export invocations per billing cycle

[Gozala]

@olizilla how about we continue discussion we started during the call about DAG-ifying user spaces here as this issue already outlines some ways we could go about it. Here are my rough thoughts

• I am 💯 onboard with idea of treating user space as MFS (or an IPLD DAG reminiscent of it. In fact Fission's WNFS is probably going to be ideal here), however I fear that might impossible given our current timeline.
• Building a UnixFS on request like store/export appears fairly straight forward, only trouble might be running out of memory or worker runtime on spaces that have insane amount of CARs. Personally, I would be ok with saying that this capability only works if your space holds < N CARs and we can lift that limitation in the future.
• Making all our */list operations return UnixFS directories is even more appealing as it effectively avoids < N CARs limitation of the store/export. If your whole store can fit one page you effectively have an export function, if it does not fit, well you'll have to export page by page and that's ok too, we can implement add .store.export() function to our client that will page and concat on the client side.

There is also an alternative idea that might be worth considering which is

• store/export creates a CAR with all the store entries and adds that car to your store only returning back the CID of it.
• store/import is basically a wrapper around store/add that once complete will add entries to the store async.

Nice thing about going with this approach we can cut both egress / ingress costs and if it so happens that CAR been imported is not already in our bucket, it's up to user to upload it to us with already optimized flow.

[Gozala]

It is worth highlighting that doing list / export as IPLD DAGs is not in conflict from turning space into a DAG itself. We could fully DAG-ify space and when that happens /export would effectively just give you CID of current revision. As of /list I think it still makes sense as it a selection on the DAG.

[travis]

PR toward this here: storacha/w3infra#392

[travis]

This should be working - I'm going to try it on one of the space I lost access to when we switched to new emails, and we're looking for a customer to try this with, but have not heard back from the folks who were interested earlier this summer and want to close this out.

[travis]

This is still pending a response from the customer who requested it - I think we should keep open.