If you use a module that cabal doesn't know about, first it warns you and then
later it fails to link because it doesn't have the module.

App will scale better than "lots of parameters passed everywhere".

getFilesDir gives us our _data_ directory.
Nothing yet writes out a servers.yaml there so we won't ever find it.
There is something called "assets".
Maybe that is the kind of thing we want to distribute/load.
For now, we know how to distribute Haskell code, so put it there.

probably should add some kind of navigation proof of concept too

didn't I have this in here?  where did it go?

* tahoe-ssk implements SDMF itself
* new version of tahoe-great-black-swamp exposes the APIs for downloading
  "mutables"
* new version of gbs-downloader extends `download` interface to support SDMF

Useful for checking to see if your Base64 encoder works :(

In fact, it does work in `ob run` but it encounters an error in decodeUtf8
when run on Android.

Previous attempts which appeared to work seemed to using our MainWidget.hsc
and reflex-dom's MainWidget.c/h...  These changes seem to convince the build
system to use our copies only.

and move platform-independent code out of Android module where it is expensive
to build/test.

Hook up the Android back button to the event propagation system.

Handle the Android back button event with browser-based history navigation.

This is aimed at the Android back button for now.  Later it will probably deal
with Android Activity results.  After that, who knows.

reflex-dom does not expose it but we need to use it if we are going to
customize the AndroidActivity - necessary to do things like hook up the back
button or handle activity results from other apps.

This is more different from the "MagicFolders" view

... since we want to display this if there's no Magic Folders yet.

It doesn't build.

The executable is generated code that we probably won't touch.