The app has a hard-coded "version" (timestamp) of the latest map data. Basically which "folder" it's in within S3.
The app downloads manifest.json from within this directory, which lists all of the downloadable regions. Right now, each region in the manifest has:
The paths to the file chunks (each 2MB, re-assembled after download) so the app knows where to download them
The bounding box represented by that region, so that it can be shown on the map for the user to click on
I'd like to add a couple new fields;
sha256sum of the assembled file, to assure users that the file is intact and (for whatever it's worth) not tampered with since it was generated
estimated decompressed data size - This one will be hard. The search data gets imported into sqlite3, and that's hard to predict. That's why we can only give an estimate. Close enough to give the users an idea whether this is a big or small area.
download data size - This can be exact. Maybe also useful if the user is worried about bandwidth.
Finally, I'd like to hard-code the sha256sum of the manifest file itself into the app, along with the hard-coded "version", so we know the manifest itself hasn't been tampered with.
In the long run we want to update the data without new app versions, in which case we'd switch to signatures on the manifests instead of sha256sums.
In a nutshell, here's how downloads work:
The app has a hard-coded "version" (timestamp) of the latest map data. Basically which "folder" it's in within S3.
The app downloads
manifest.jsonfrom within this directory, which lists all of the downloadable regions. Right now, each region in the manifest has:I'd like to add a couple new fields;
Finally, I'd like to hard-code the sha256sum of the manifest file itself into the app, along with the hard-coded "version", so we know the manifest itself hasn't been tampered with.
In the long run we want to update the data without new app versions, in which case we'd switch to signatures on the manifests instead of sha256sums.