So Brotli already contains a dictionary that is trained on web traffic. I think the thing here is that Google wants to make sending YouTube 1.1 more efficient if you already have YouTube 1.0, but they can’t put YouTube 1.0 into the browser.

This is something game devs have been doing for decades.

If you want to delta 1.0 to 1.1 that’s server side work you do once at deployment or build time, not on every request.

What happens when you release 1.2 and someone who has 1.0 visits? Do you generate a delta for every past version at build time?

You determine how far back you want to build deltas for. If you build deltas for the last 3 versions then you can send diffs for those users as well (as long as the dictionary hasn't expired). Or, you could just send the full response just like if dictionaries weren't supported.

Each site can decide what a "good" number of releases to build against based on typical release cycles and user visitation patterns.

The patch system I worked with generated signatures of each build. The signature had the hash of each block of the build. The client has the signature for their version (1.0) and they download the signature of the new version (1.2) and diff the two. Then they download each block that has changed.

I think it was the `electron-updater` for my electron app, but I don't quite remember now.

It was just a couple years ago that I learned that the Unix compression libraries have a flag to make them “rsync friendly”. They do something with compression blocks to make them more stable across changes. Normally a small change in the middle of a file could change the rest of the output, due to bit packing.

I should really figure out how that works.

You mean if a user who hasn’t visited the site in a year comes back?

They download 1.2 because 1.0 is no longer in their browser cache, that’s what.

The web is easier than games because “files at rest” are much more volatile on the web.