-
Notifications
You must be signed in to change notification settings - Fork 66
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
Moving Qri's IPFS repo into the .qri folder #1319
Comments
My vote for this is to keep the implementation simple. Copy everything from the old |
very into that idea. Sounds far less error prone |
My only concern here is while we are going to heavily test the migration suite, issues can still occur. One thing I'd definitely want in this is a rollback mechanism and maybe dual compatibility for a while until we get over the hump with some sort of sunset period. Currently a curse and a blessing that we don't have too many heavy users to make such a large change. |
I like keeping ...but. I am not sure what is in That’s a complicated case, but there are official places for those bits. I put more about this in #1319. It’s complicated, but now is probably the best time to consider it. |
Background for why we're doing this: #1225
Migrating Qri's configuration
We should time these changes with our overhaul of qri's configuration, updating the config RFC to talk about removing support for
IPFS_PATH
. Instead the ipfs repo path should be part of the new filesystem configuration, specific to the local IPFSqfs.Filestore
. Doing it this way both removes configuration ambiguity, and allows users to get the old behavior back by specifying~/.ipfs
as the repo path.To make this transition as clean as possible, I think we should use a completely new IPFS config, with a new keypair. This'll mean users running on the libp2p network won't appear as the same peer. Yet another reason I'm thankful we connected user data to a separate keypair held by Qri.
Moving Qri data from one IPFS repo to another
We're going to need a tool for detangling the hashes in an IPFS repo that Qri relies on, both to move those hashes to another repo, and to unpin those hashes from the original repo.
Using non-default ports for IPFS configuration
The other part of privatizing our IPFS instance is to move off of the default port configurations for our IPFS node.
We can leverage this move to a private configuration to set ports to non-standard ones. One option is to use
0
for port numbers, which defaults to an open port.Steps to complete:
note: need to finish this list
.qri/ipfs
, new keypair and allIPFS_PATH
env var.qri/ipfs
.The text was updated successfully, but these errors were encountered: