The answer to this is surprisingly complicated.
TLS can optionally support compression which would most likely have universally worked for all wss:// connections. However, this was disabled in OpenSSL and other TLS libraries because of a critical information leakage that arises when secret and non-secret information are combined in the same compression context: https://blog.qualys.com/product-tech/2012/09/14/crime-information-leakage-attack-against-ssltls
HTTP-level compression does not apply to websockets (since its framing replaces/upgrades the HTTP framing) so instead compression is specified by the websocket RFCs. It is optional, so not all clients support this.
Websocket compression happens per message, and can use an empty window for each message, or can have a "sliding compression" window where messages are effectively compressed with previous messages. Some implementations will support both of those modes, some only one, and some neither. Even if an implementation supports compression, it may choose not to use it, and/or may use it only for particular messages (and not others). Furthermore, in the websocket compression handshake, bi-directional window sizes need to be negotiated and sometimes windows cannot be negotiated in one or both directions.
Almost all browser websocket clients support full compression with sliding windows in both directions, and so does strfry. The sliding window has a relatively large memory overhead per connection, so it can optionally be disabled. The compression ratios can be seen in the strfry logs.
Although strfry <> browser connections are almost always compressed both ways, different clients and relays have different levels of support and often can't negotiate optimal compression.
Doug Hoyte /
npub1yx…8qud4
2024-09-14 00:22:34
in reply to nevent1q…rp3h
Author Public Key
npub1yxprsscnjw2e6myxz73mmzvnqw5kvzd5ffjya9ecjypc5l0gvgksh8qud4Published at
2024-09-14 00:22:34Event JSON
{
"id": "af9c476bee37dcedce8fe0d296f87b13eb552f060b5866462e5c20bf51d4daf7",
"pubkey": "218238431393959d6c8617a3bd899303a96609b44a644e973891038a7de8622d",
"created_at": 1726273354,
"kind": 1,
"tags": [
[
"client",
"oddbean"
],
[
"e",
"8623be03632bdf85e140c275fdf7f39b20e1393c381164f5b25662724663058a",
"",
"root"
],
[
"e",
"58bfdf6e9f297ae780089f445da5652c32d47d7f07b31c8f5c7e2b5298357f73",
"",
"reply"
],
[
"p",
"218238431393959d6c8617a3bd899303a96609b44a644e973891038a7de8622d"
],
[
"p",
"3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d"
],
[
"p",
"6140478c9ae12f1d0b540e7c57806649327a91b040b07f7ba3dedc357cab0da5"
]
],
"content": "The answer to this is surprisingly complicated.\n\nTLS can optionally support compression which would most likely have universally worked for all wss:// connections. However, this was disabled in OpenSSL and other TLS libraries because of a critical information leakage that arises when secret and non-secret information are combined in the same compression context: https://blog.qualys.com/product-tech/2012/09/14/crime-information-leakage-attack-against-ssltls\n\nHTTP-level compression does not apply to websockets (since its framing replaces/upgrades the HTTP framing) so instead compression is specified by the websocket RFCs. It is optional, so not all clients support this.\n\nWebsocket compression happens per message, and can use an empty window for each message, or can have a \"sliding compression\" window where messages are effectively compressed with previous messages. Some implementations will support both of those modes, some only one, and some neither. Even if an implementation supports compression, it may choose not to use it, and/or may use it only for particular messages (and not others). Furthermore, in the websocket compression handshake, bi-directional window sizes need to be negotiated and sometimes windows cannot be negotiated in one or both directions.\n\nAlmost all browser websocket clients support full compression with sliding windows in both directions, and so does strfry. The sliding window has a relatively large memory overhead per connection, so it can optionally be disabled. The compression ratios can be seen in the strfry logs.\n\nAlthough strfry \u003c\u003e browser connections are almost always compressed both ways, different clients and relays have different levels of support and often can't negotiate optimal compression.",
"sig": "9e7d4ae92c2cf40804aa81a7a2909997f61191bc3de7ddd504b3769caf0220e5b7ddc7745358bf840268c590effc3e950cbc947ff8fc3b5e9ce92acaf44a128b"
}