[ONE General] airtower:
Cyandelta uses unix tool called xdelta. xdelta has nothing to do with cyanogenmod or any other type of file specifically. It has also been around for nearly 17 years, so there's that as well.

Think of it like this: I create a movie on my computer and send it to you as a single file. You tell me you don't like 4 out of the total of 10 scenes so I change them. Now I have two choices: I can send you a whole new file, including all 10 scenes changed and otherwise, or I can run the original movie and the updated movie through xdelta, which will produce an output delta file. (Videos aren't the best analogy here, as xdelta probably won't save much in the way of filesize in that case, but nonetheless the delta file will more than likely be smaller than just sending you the entire updated movie.) This delta file effectively contains only the changed scenes plus some metadata about what chunks of data replace what and where. When you receive the delta file, you run it through xdelta on your end specifying the original file and the delta file. xdelta produces an output file that is bit for bit the same as the complete movie file on my end with the updated scenes. A manual MD5 check would verify this (actually the final MD5 is included in the delta file and xdelta verifies it automatically).

xdelta works the same with movie files (mkx, avi, whatever) as it does with zip files - including CM nightlies, or any other file for that matter. On the cyandelta servers, delta files are created between the current nightly and (I believe) every nightly going back 14 days. Server-side, xdelta looks at the files in binary form, looks for regions that differ (compare this to the movie scenes example mentioned previously), and adds the changed regions and their "location" within the file to the output delta file. This file is posted on cyandelta's servers, the app pushes a notification, you download it, cyandelta runs xdelta on your device (xdelta is included within the app) on the original zip and applies the delta file producing an output zip with the exact MD5 of the new zip released by CM. There is no opportunity for error here and this is why cyandelta requires that you keep full zip of the version you are running in its directory on your sdcard. It needs a base file to apply the delta to to generate the updated file.

I think a lot of the misinformation comes from the fact that the files cyandelta creates locally are much larger than what one would download from CM. This is because cyandelta decompresses the zip files, as compressing them sort of scrambles all the data in a manner that casues xdelta to be much slower and the delta files to be much larger. Users are altered to this fact when first using the app.

For those of you this still cry "I HAVE ALL THE BANDWIDTHS I EVAR NEED I DONT CARE CYENDELTA CAUSES PROBLEMS LOLOLOL U SHOULD NEVAR USE IT!!!!11``" do yourself a favor and do this:

Download today's nightly

Decompress the zip using your favorite archive tool

Generate an MD5 sum for the uncompressed zip

Download last night's nightly

Install cyandelta, add last night's nightly, and allow it to apply the update for the current nightly

This will leave you with two zip files in the /sdcard/cyandelta directory. Run an MD5 check on the new nightly

Well look at that. They are the same. Bit. For. Bit. They are the same.

So it has nothing to do with what changed in zip, if it's in the CM zip, it ends up in the cyandelta zip

. Kernels, radios, other binaries, it's all the same. Some seemingly small changes result in larger than normal delta files (especially when binaries like kernels or modems are changed), but that's just the nature of the game. In the same way that compressing a file with winrar never screws up and leaves you with a corrupt file when you decompress it and open it, xdelta uses similar logic to ensure the output 100% matches the intended file. You can even clean flash the new zip as you would if you had obtained it directly from CM, to the same effect as a normal clean flash. I'm not saying clean flashing doesn't sometimes carry value here, as I believe it does, however the source of the file doesn't matter.

There is one caveat though, and in 4ish years of using cyandelta, it has caused me a minor headache a total of one time: Since the delta file generation is controlled by a script on the cyandelta servers, it will begin generation and publishing of the delta files as soon as they are posted by the CM build bots. If these files are for some reason pulled by CM (rare), cyandelta lacks a mechanism to pull back the delta updates. This could leave you with a few problems, but CM's management systems are pretty good at catching these types of problems before the code changes are even merged. Worst case, reboot to recovery and flash the old zip.

If this all still scares you, go ahead and run your device's stock ROM and go post in those threads about how you hated technology so much you left the bleeding edge. You're far more likely to encounter issues that are coming from the CM source than as a result of updating through cyandelta.