@meejah and others (including myself...) point out that there are situations in which it would be desirable for existing/on-disk tahoe configurations to be more easily updated in accordance with configuration changes made by tahoe storage providers. For example, if a user creates a Recovery Key on the Public Test Grid today and that grid's introducer fURL changes tomorrow, the user may find themselves unable to restore from that Recovery Key later on (because, as it currently stands, Gridsync's recovery process will restore whichever introducer fURL was originally embedded in the Recovery Key; it makes no effort, presently, to distinguish "old" grid-configurations from newer/current ones).

Accordingly, it would be preferable if Gridsync could make better determinations -- and/or present to the user meaningful options -- about which grid-configuration to use when restoring from a Recovery Key. One way to do this would be to a) ascertain the "identity" of a grid (and thus the true location of the user's rootcap) according to some other more durable identifier (such as the name of the grid/connection itself or even a UUID) that remains the same over time and b) prefer -- and/or provide the option to use -- the grid-configuration associated with that identifier during recovery. Under such a scheme, a user attempting to restore from a Recovery Key containing potentially-old/obsolete Public Test Grid configuration could thus instead be given the ability to restore with the newer/updated configuration (assuming, of course, that Gridsync actually has access to this new configuration -- for example, because it embeds the configuration data in a newer version of the software).