In legacy/trac#22341 we are thinking about picking up LZMA- and Zstandard-support for consensus diffs. For LZMA-compressed diffs I often encounter boostrap delays of at least 20s like this: ``` Dec 26 21:01:18.000 [debug] HTTP body from server 'XX.XX.XX.XX:9001' was labeled as LZMA compressed, and it seems to be LZMA compressed. Dec 26 21:01:38.000 [info] handle_response_fetch_consensus(): Applied consensus diff (size 482897) from server 'XX.XX.XX.XX:9001', resulting in a new consensus document (size 1903167). ``` But, worse, it might even break Tor Browser bootstrap entirely when blocking a Tor Launcher `GETCONF` call (throwing an exception as Tor Launcher thinks tor is not working) like so: ``` Dec 30 23:54:54.000 [debug] HTTP body from server 'XX.XX.XX.XX:9001' was labeled as LZMA compressed, and it seems to be LZMA compressed. Illegal AddressMatcher: [xpconnect wrapped nsIPrefBranch] -- TypeError: s.split is not a function Illegal AddressMatcher: [xpconnect wrapped nsIPrefBranch] -- TypeError: s.split is not a function [12-30 22:54:55] TorLauncher DBUG: readTorSettings ---------------------------------------------- [12-30 22:54:55] TorLauncher DBUG: Sending Tor command: GETCONF UseBridges [12-30 22:55:10] TorLauncher NOTE: Exception on control port [Exception... "Component returned failure code: 0x804b000e (NS_ERROR_NET_TIMEOUT) [nsIBinaryInputStream.readBytes]" nsresult: "0x804b000e (NS_ERROR_NET_TIMEOUT)" location: "JS frame :: jar:file:///home/thomas/Arbeit/TBB/tor-browser_en-US/Browser/TorBrowser/Data/Browser/profile.default/extensions/tor-launcher@torproject.org.xpi!/components/tl-protocol.js :: TorProtocolService.prototype._torReadLine :: line 920" data: no] ```