sandstorm

sandstorm copied to clipboard

@zenhack suggested I make a specific issue to discuss this proposal. I'd like to see the ability within the Grain Settings to both see and change the packageId assigned to a grain. While not a particularly user-friendly approach, I think it would grant us a lot of features without exceptional scaffolding. For instance, it would provide the ability to:

#2755 Upgrade a single grain to a newer version of an app #1913 Roll back a grain to an older version of an app provided the schema has not changed #386 Restore a grain to a specific version of the app Switch a grain to a forked SPK of an app Switch a grain to an alternative app supporting the same data storage format (Git repos, Text files, etc.) Switch a grain temporarily to a "grain editor" (kind of the equivalent to opening a local file in a hex editor) #2542 Grain patching, implementable with third party apps

Ian mentioned that this might be too low-level for the UI, but I am not sure I agree. Some of these scenarios would either be complicated to develop in the UI or require additional work on behalf of app packagers. While this sort of usage would be considered advanced, it shouldn't require a server admin on a Linux box craft a sandstorm mongo command to accomplish, particularly since the damage scope is a single grain that a grain owner should have total control of.

Users tampering with such a setting would presumably need to know what packageId they were switching a grain to, and it would need to exist on the server for the change to succeed. In most scenarios where a packageId change failed to work, changing it back to the old packageId would likely restore the grain. I would also propose this option also be placed within a "Danger Zone" section of the Grain Settings, which highlights that you should back up the grain first, and that changing the packageId could irreparably corrupt the grain.

I guess my objection is to shoving stuff in the UI that requires fairly sophisticated knowledge of the platform to even understand what it does. Note that on GitHub at least, the "Danger Zone" consists of operations that are potentially dangerous, but it's still clear what they do.

I guess I don't have a problem with an about:config-style extra-advanced settings area, but I think this is a step up from things like transferring grain ownership.

I think some of the above would be eventually better addressed with other UI in the long term, but I think there'd be a lot of short term value at a low implementation cost. It'd give us a path around what the most common strategy is, which is to download and tamper with a backup, breaking all sharing links and powerbox capabilities, and of course, without having to suggest Mongo commands, which are super risky.

I feel like any time a user potentially needs to go entirely outside of our UI, to manage their grains, that's a failure.

(I also thought of a fun side feature this would offer while trying to think about risks for this feature: One could intentionally change a grain between two unrelated apps that don't have any collision in /var, and hide grain data in a seemingly unrelated grain: Change your password storage grain into a YATA package ID, and your grocery list grain is concealing other data which will only be revealed by switching to the correct other packageId. Considering the use of self-hosting by people who need to avoid governmental surveillance and intrusion, this... might be useful for obscurity?)