QUICKSTART: note on stale content accessible via alternative transports

docs/QUICKSTART.md

@@ -147,7 +147,7 @@ You will also note the additional key in the config file: `defaultPluginTimeout`
 
 What this gives us is that any content successfully retrieved by `fetch` will now be cached for offline use. If the website goes down for whatever reason (and the `fetch` plugin starts returning errors or just times out), users who had visited before will continue to have access to content they had already accessed.
 
-> ### Note on plugin types
+> #### Note on plugin types
 > 
 > The `cache` plugin is a **"stashing"** plugin in LibResilient nomenclature. Such plugins have no way of accessing remote content, they are only good at saving such content locally for later, offline use. Currently there are no other stashing plugins, but anything that can save data locally and is available in Service Workers could be used to write new ones.
 > 
@@ -167,7 +167,7 @@ In case of LibResilient this means that the first time a visitor loads our examp
 
 Next time that same visitor loads that particular resource, it will be served from cache, so response will be instantaneous. In the background, however, LibResilient will still use the `fetch` plugin to try to retrieve newer version of that content. If it is retrieved and indeed newer, it will be stashed by the `cache` plugin.
 
-> ### Note on stashing in LibResilient
+> #### Note on stashing in LibResilient
 > 
 > LibResilient treats stashing plugins in a special way. If the configuration includes multiple transport plugins, and a stashing plugin (like the `cache`) between them, then:
 >
@@ -240,5 +240,10 @@ Once our website content is available on both `https://example.org/` *and* `http
 From the perspective of the visitor, the site will work normally, some content (that is, content that has not been stashed locally yet) will just be slower to retrieve. How much slower depends on the exact way our site is unavailable, and the value of `defaultPluginTimeout`:
  - if the `example.org` server is rejecting connections, or there are TLS certificate problems, or such, the `fetch` plugin will fail instantenously, and the `cache` and then `alt-fetch` plugins will kick in quickly;
  - if the `example.org` server is overloaded and takes seconds to respond, or for whatever reason the IP packets are and never responed to, LibResilient will give the `fetch` plugin `defaultPluginTimeout` (in our case, 1s) and then will move to trying `cache`, and `alt-fetch` afterwards.
-
+ 
+> #### Note on content versions
+> 
+> LibResilient does not have a reliable way of comparing versions of content available through different transport plugins. If the content available through configured alternative transports is *older* than the content available directly on the original website, that *older* content will be provided to the visitor if the original website happens to be down.
+> 
+> It is up to the website admins to ensure that the configured alternative transports do not serve stale content.