Wow - I would love to help get diffable deployed in this type of environment and see how it performs!
The steps that you describe are exactly what the project does, and we have been experimenting with it, off and on, inside Google since I originally built it. However, we were mostly interested in trying to use it to lower the page load time of desktop sites from 10s of seconds to single digit seconds. We had not played with it in a
very low bandwidth setting like the one you are describing. The main issues we have run into during our various experiments are local storage implementations and the added latency of the boot sequence.
In many cases where users have poor connections, they also seem to have poor local storage performance. Reading from local storage was adding significant time to the boot sequence, and in a significant portion of the cases, otherwise fast users (had they been using the network only) were slowed down by this initial access of local storage. However, given the scenario you are describing, I don't think this would be an issue given how long it takes to download over the network. The second major problem was the case when there was no version in storage, or, for whatever reason, the version in storage was no longer valid or patchable. You can imagine that, in production, you could end up with exponential patches as each new version requires a patch from every older version and so putting a limit on how old the library can be was a way to manage cost. But in these cases, having to first read from local storage, and then access the network for the full download, was a big latency hit compared to them just having downloaded the resource directly. Again, this seems like a problem you would not have given how long the download takes.
In summation, I think what you are describing would be a perfect candidate for why I initially created this. As I mentioned, the version in source control at the moment does everything you describe and is absolutely functional, though it's been about 4 years since I've worked with it. I would need to familiarize myself with the code again. However, I would love to do so if it were going to be receiving this kind of trial by fire! Out of curiosity, what environment are you using on the server side?
Per your client-only concept, I don't think this would be possible given that the server would always have to be the one generating patches. One thing I could imagine is that all patches are only between successive versions, i.e. v1 -> v2 -> v3 -> v4. If someone loaded the base page and saw the v4 was the current and v2 was in local storage, they would first have to download and patch v2 -> v3 and then v3 -> v4. This would mean all diffs could be generated at build time, on the server, and pretty much all logic from that point forward could reside in the client. But given the network conditions you describe, I imagine adding these extra round-trips could be quite costly.
Thoughts?
And thanks again for reaching out! It's so cool to think that it could be used to help so many people, and I would love to help in any way I can!
Joshua