| 22 Jun 2021 |
 /dev/tty63 | not capacity problems, but at some point codeload.github.com starts to give 500 server error | 22:51:06 |
| /dev/tty63 | https://codeload.github.com/cdnjs/cdnjs/zip/refs/heads/master | 22:51:09 |
| /dev/tty63 | when it reaches 10GB of downloaded data | 22:51:22 |
 Elpranocotro | idk what is the special status of Discordian's call, but just know that no matter what you are building with any PL project, there likely is a weekly call you can join and ask questions about the thing you are using | 22:52:32 |
| /dev/tty63 | In reply to @_discord_183309006767521792:ipfs.io
idk what is the special status of Discordian's call, but just know that no matter what you are building with any PL project, there likely is a weekly call you can join and ask questions about the thing you are using thats very cool | 22:53:23 |
 Discordian | Yeah I'm quite new so I don't know how the other projects operate, but PL is very remote and everyone seems very friendly, so it makes sense to have communication be easy and open | 22:55:35 |
| /dev/tty63 | that weekly call is on slack? | 22:57:19 |
| Discordian | I don't know what Elpranocotro is referring to, but mine's just a closed meeting coordinating community things including talking about what Hackathons are coming up and such. It's on Zoom | 22:58:11 |
| /dev/tty63 | Yeah, I meant the open call xD | 22:58:47 |
| Discordian | Oh haha, yeah I'm curious too | 22:58:57 |
| /dev/tty63 | I mean, I don't have relevant stuff for now tho :D | 22:59:01 |
| Discordian | I feel like I'm missing out :p | 22:59:01 |
| 23 Jun 2021 |
 IPFS Bot | Dwarkesh Patel @dwarkesh posted in How to decipher root node content?
To better understand how mid and root nodes are encoded in IPFS, I decided to see if I can decode them. I’m trying to find the children’s hashes from the raw data of the root node. My root node CID is QmRvnF6ybLDfAHzuKFZmPcQKMyaWXCga4GtTVVE3nheQdh.
I ran:
ipfs block get QmRvnF6ybLDfAHzuKFZmPcQKMyaWXCga4GtTVVE3nheQdh >> root.bin
protoc --decode_raw < root.bin
protoc is the Protocol Buffer comp...
| 00:03:06 |
|  Johnny狼 | Kaimon joined the room. | 02:13:32 |
 RubenKelevra | In reply to @ljmf0null:matrix.org
Arch uses zstd compression, and zstd is pretty heavy zstd is actually the best compression algorithm around | 02:15:16 |
| RubenKelevra | Arch changed from xz to zstd because it's more lightweight | 02:15:39 |
| RubenKelevra | zstd is IMHO also the only viable option if you're to compress chunked data, since you can use a static dictionary file for the file type instead of the need to build up the same dictionary on each chunk again. | 02:17:02 |
| RubenKelevra | 
Download 8421_compression-test-compress-speed-vs-ratio-01~2.png | 02:22:34 |
| RubenKelevra | No other algorithm comes even close in speed when you want just a small amount of compression. You can basically compress with several thousands of MB per second. | 02:23:35 |
| RubenKelevra | Source: https://community.centminmod.com/threads/round-4-compression-comparison-benchmarks-zstd-vs-brotli-vs-pigz-vs-bzip2-vs-xz-etc.18669/ | 02:24:38 |
| RubenKelevra | Redacted or Malformed Event | 02:27:13 |
| RubenKelevra | And if you don't compress test data but something more real world, like the Linux kernel you can see it perform even better:
| 02:27:42 |
| RubenKelevra | 
Download 7890_round3-part4-charted-shorter-02.webp.png | 02:27:55 |
 notawhiteowl | hey gang. I'm trying to implement my dual proxy setup for the websocket transport. the reverse proxies work just fine, and nodes which all have reverse proxies in place show GET / requests with 200s | 03:13:49 |
| notawhiteowl | but then when i put the forward proxy in place, it instead attempts to make CONNECT requests, which nginx does not support | 03:14:09 |
| notawhiteowl | why is go-ipfs using the GET method on the reverse proxy, but the CONNECT method on the forward proxy? | 03:14:29 |
| notawhiteowl | im pulling my hair out. nginx doesn't support the CONNECT method out of the box, and implementing the functionality with a module doesnt change anything | 03:17:12 |
| notawhiteowl | is there a different forward-proxy tech which might work better? | 03:17:40 |
|  Milo-IPFSUnion changed their display name from Milo-IPFSUnion to Milo - IPFSUnion. | 03:46:39 |
| Milo-IPFSUnion changed their display name from Milo - IPFSUnion to Milo-IPFSUnion. | 03:46:56 |
