-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to fork a space #1018
Comments
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 Perhaps we could implement We could also limit number of free |
@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
There is also an alternative idea that might be worth considering which is
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. |
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 |
PR toward this here: storacha/w3infra#392 |
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. |
This is still pending a response from the customer who requested it - I think we should keep open. |
We got a request to change email associated with an account (see thread) which is bit tricky because:
did:key:zSpace → did:mailto:mail.com:old → did:mailto:mail.com:new
which effectively keeps old email in change of the new oneWe 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:
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 thedid:key:zNewSpace
Put it differently we have a verifiable proof that:
bafy...store
is delegation)If we have this capability along with compatible
upload/import
we could address request as follows:store/import
andupload/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.The text was updated successfully, but these errors were encountered: