Wagn should support these mechanisms for viewing files/images.   Note that even different revisions of the same card can use different mechanisms.

1. coded files - db_content starts with ':'.  These files are in the codebase, like the default logo.  Every view is a wagn request. 
2. local files – db_content starts with '~'.  These are in the deck's "files" directory by default.  If read permissions are set such that "Anyone" can read, then there is a symlink from the public directory.  Otherwise every view is a wagn request. 
3. "bucketed" files - db_content starts with '('.  Eg "(mybucket)/123/4567.png".   bucket is substituted for url base.  rendered as absolute url
4. (?) complete urls - db_content starts with http (or other?).    rendered as is.

In 3-5, the content may be stored on the same server or another.   In general  none of the three should lead to wagn requests.

They correspond to these mechanisms for storing cards:

1. coded files are handled by coders (eg with rake tasks)
2. protected uploaded files are the default.  (current functionality)
3. linking/unlinking to unprotected files is handled on permission-changing events. 
4. this is standard cloud upload behavior
5. ? 

Unlike viewing files/images, which can all be options in the same deck, any given deck will need to have a single default storage option for creating/updating cards.  (One configuration option in the future might present a dropdown for the user, but for now there is not much demand for that; it's much more important to keep things clean and simple).

Configuration

the explicit (but unnecessary) configuration of current behavior

config.file_storage :protected  # default

buckets are a bit more involved: 

config.file_storage :bucket1
config.file_buckets({
  bucket1: {
    provider: ...
    credentials: ...
    directory: ...
  },
  bucket2: {
    url_base: ...
  }
})

 bucket1 above is an example of a full-fledged cloud service.  Ready for createing and updating files/images.

bucket2 is basically read-only.  It would not be able to create/update images, but it would let folks render files and images and may help us support some cool data sharing patterns.  (Eg, you could publish a set of image variants and switch to different buckets to get the different variants.  Or you could have a dev server that didn't let you accidentally alter images on the cloud but let you see them.  Or you could let someone use your "hand" of cards but not given them access to edit its images/files.