For an object store backend, none of the suggestions in this paragraph
make much sense. "May" is much softer, in terms of
https://datatracker.ietf.org/doc/html/rfc2119. And in particular, the
cloud server implementation does not do any of these things.
We don't know why we're doing this step so we probably shouldn't.
Cryptography isn't magic and extra steps are harmful in that they
obscure the important parts.
* Add support for cloud sync, specifically GCP
This adds generic support for sync to cloud services, with specific
spuport for GCP. Adding others -- so long as they support a
compare-and-set operation -- should be comparatively straightforward.
The cloud support includes cleanup of unnecessary data, and should keep
total space usage roughly proportional to the number of tasks.
Co-authored-by: ryneeverett <ryneeverett@gmail.com>
Dependencies are now implemented, and the docs should be clear about the
format of the keys and values.
Noticed while working on GothenburgBitFactory/tw.org#212.
In #3118 @ryneeverett mentioned that "key" suggests that this is a
secret, when in truth it's just a user identifier. So "ID" is a better
word for it than "key".
- update CI branch filters so workflows actually run on merge
- update CI docs deployment target
- update links
- fix typos
- remove references to `ta` cli which was removed
- remove build-docs.sh script which duplicates publish-docs.yml workflow
