Setup
Connecting an account
Flitterby never asks for a password. Google Drive and Dropbox are connected through their own sign-in screens, and S3-compatible storage through keys you issue yourself and can revoke without involving us.
Google Drive
Source or destination
What to do
Choose Google Drive when adding an account. Google's own sign-in screen opens, you pick the account, and you land back here. There is nothing to configure and nothing to paste.
The permission looks broad, because it is
Google offers one Drive permission and no narrower one that still allows reading the files you pick and writing copies where you ask. We use it for exactly those two things. Google also lets you untick it on that screen: if you do, the connection is refused rather than saved half-working, because a connection that cannot read is not a connection.
You may see an "unverified app" warning
Flitterby is in private testing, and Google shows that warning until an app completes its review. Choose Advanced, then continue. If your address is not on the tester list the sign-in will simply fail, so tell us and we will add it.
Reconnecting every seven days, for now
While the app is in testing Google expires the stored authorization after seven days. Nothing is lost when it happens: the copy parks, you press Reconnect, and it carries on from where it stopped. This goes away when the app is published.
Dropbox
Source or destination
What to do
Choose Dropbox when adding an account and approve it on Dropbox's screen. As with Google, there is nothing to paste.
What we ask for
files.metadata.read files.content.read
files.content.write account_info.read sharing.read
Read what you choose, and create what you asked for. There is no delete permission in that list, so a copy into a folder that already holds the same name lands as a new “name (1)” rather than replacing anything.
Team accounts
A Dropbox Business connection can act as any member, so after connecting you pick which member's files to work with. A personal account is only ever itself and the choice does not appear.
S3-compatible storage
Keys, not a sign-in
This one is a form rather than a sign-in, because these providers issue keys instead of using OAuth. Your keys are checked against the live bucket before anything is saved, so a typo is reported immediately rather than at the start of a transfer.
What the form asks for
Name is yours, for telling connections apart.
Endpoint is the bucket's S3 URL without the bucket name in it.
Bucket is the bucket name on its own.
Region can be left as auto where the provider ignores it.
Folder prefix is optional and confines Flitterby to one part of the bucket.
Then the access key ID and secret access key.
Endpoints and where keys come from
Confirm the endpoint in your provider's own console, since it varies with the region the bucket was created in.
Amazon S3. https://s3.<region>.amazonaws.com, region
required. Keys from IAM, under a user's security credentials.
Cloudflare R2.
https://<account-id>.r2.cloudflarestorage.com, region auto.
Keys from R2, Manage API Tokens, with Object Read and Write.
Backblaze B2.
https://s3.<region>.backblazeb2.com, for example
s3.us-west-002.backblazeb2.com. Region is the one in the endpoint. Keys from
Application Keys.
Wasabi. https://s3.<region>.wasabisys.com. Keys from
Access Keys.
DigitalOcean Spaces.
https://<region>.digitaloceanspaces.com, for example
sfo3.digitaloceanspaces.com. Keys from API, Spaces Keys.
MinIO or self-hosted. Your own URL, and usually
us-east-1 unless you set otherwise.
What the key needs to be allowed to do
To read: list the bucket and get objects. To write: put objects, and create, upload and complete multipart uploads for anything large.
It also needs delete, which deserves an explanation given what we say elsewhere. It is used in exactly two places: abandoning a multipart upload of our own that failed partway, and removing a file we had just written whose checksum did not match, so a corrupt copy is not left behind wearing a correct name. It is never used on anything that was already in your bucket. If you would rather it could not, issue a key without delete: transfers still work, and a failed verification leaves the bad object for you to remove.
Your provider may charge for the transfer
Flitterby does not charge for bandwidth, but object storage providers often do, and it is usually billed on the way out, meaning the account you are copying from. Some also charge per request, which scales with how many files you have rather than how large they are, and a few add minimum retention rules. Rates differ by provider and change, so check your provider's pricing before starting a large transfer. See the declaration for the shape of it.
Scoping the key
Every provider here can issue a key limited to one bucket, and most can limit it to a prefix. Doing that is a better protection than anything we can promise you, because it does not depend on us behaving.
When a connection stops working
What it looks like and what to do
Waiting for you to reconnect
The stored authorization stopped being accepted: it expired, or it was revoked, or the account's permissions changed. Use the Reconnect link on the account and resume the copy. It picks up from where it stopped rather than starting over.
Revoking access yourself
Disconnecting here removes the stored credential immediately. You can also revoke Flitterby from Google's or Dropbox's own security settings, or delete the S3 key, which takes effect at once and does not depend on us.
Still stuck
What helps us answer quickly
Write to support@flitterby.com with the provider, the step it failed at, and the exact message. For S3, the endpoint and bucket as you entered them helps most, and never send the secret key.