With Blockstack authentication, each application has a unique per-app, per-user private key (and associated Gaia storage). Currently, Blockstack applications are identified to user’s by the app’s Origin — this means that a change in origin will lead to a change in user keys and storage. Unfortunately, for now, this is a limitation of the platform.
Long-term, I’d want to pursue two solutions to this:
Enable easy user-controlled migration from one Gaia address to another. The user’s root keys (managed by the Blockstack Browser) have the ability to access any of the user’s Gaia addresses, and so should be able to initiate a migration from one to another — indeed, this is part of the promise of user-controlled data. The app-specific private key would still change, but there’s application-level methods to address this (and to the extent that those solutions are generalizable, there should be developer tooling to make that easier).
Identify applications using the Blockstack Naming System rather than application Origin. This puts application developers in significantly more control when it comes to changes in their infrastructure / DNS, and is also more secure, because it depends on the cryptographic safeguards of our platform.
I’d be interested to hear what other people think about those plans, or alternative strategies that may be able to improve the situation more quickly.
Would it be straightforward to store the application’s key derivation path in the apps object, alongside the app’s Gaia hub URL? This would decouple the key derivation from the origin.
Item (1) is blocked on the ability to list files in Gaia, which is being worked on. I’ll update the CLI to be able to migrate data once we have that shipped (and once we have the latest derivation path code shipped).
As someone who is currently blocked on this and want a solution as early as today, I have been discussing solutions with my team. The solution we independently came up is 2 – it has less friction on developers, especially now when we want to move fast.
Also, in the future both 1 and 2 can be supported, but 2 seems like the way to go.
Also, what is the timeline for this to be resolved? – just trying to gauge our if we need to make changes to our engineering roadmap
I have not tested this and I’m not sure how feasible it is for your specific solution, but couldn’t you set up a process by which the data is migrated through an import from one app to the other. Here’s how I’d see that going:
Users log into the new app origin and can fetch their app-specific publicKey somehow. You’d have to reveal this in the interface for them.
Then, the users log into the original app origin and are presented with an option to export the data to the new app. They’d have to paste in the publicKey from the other app origin, and in doing so, you could save the data and encrypt it with that publicKey.
The final step would be for the users to log into the new app origin and run an import that fetches that file and decrypts it with the corresponding privateKey.
Again, I haven’t tested this, but it seems like it would work.
Technically, that should work “as like a hack” but it has friction on the users. It’s always good to test approaches with the “don’t make me think” principle that most users “subscribe to.”
Totally agree. Out of curiosity, why is this coming up? Maybe I missed it in another thread. Are you just switching app origin because you changed names? Or are you expecting to be changing app origin frequently after you gain traction? Or is it something else entirely you’re solving for?
Our app relies on signing and verifying data using RSA keys. We figured that we can’t use users’ Blockstack keys since we do not have a access to the private key, and there are no Blockstack APIs that we can use as blackboxes. So, our approach is to use app-user RSA keys and some reputable libraries for signing and verification since we have access to the app-user RSA keys. However, the issue is that the app-user keys depend on the origin. That is problematic because we are not sure if the app-origin will be the same 5, 10, or so months in the future, and we do not want to be in a situation where it is in our best interest to change the app origin but then we can’t because we can’t access user data. In short, we don’t want put ourselves in corner and the app origin might need to change for various reasons.
iirc origin = url, i.e. the app key for Graphite is derived from “app.graphitedocs.org.” If the URL changes, then the key changes, that way if someone is trying to spoof Graphite via “app.graphitedocs.com” cannot access the original Graphite’s data. But it also means you can’t change the URL without losing all your data (as neither migrating data nor cross-app data buckets exist yet).