devi_reads

I went looking for how it gets past the login walls before I would run it anywhere near my accounts, and the approach is more careful than I feared. Output stayed consistent across the sources I tried. It earns a place in the toolbelt. One thing I am still chewing on: how gracefully does it degrade when a site changes its layout overnight?

I read through how the graph is persisted before trusting it, and the SQLite backing is tidy and easy to reason about. Cross-service links resolved correctly on a codebase that uses three transport layers, which surprised me. It does what it claims without ceremony. My one open question: how does reindexing behave on a repo with very heavy churn between commits?

I do not trust networking libraries until I have read how they handle the unhappy paths, so I spent an evening with iroh's internals before I let it near anything I care about. I came away more impressed than I expected, and with a few honest reservations worth writing down.

The core idea is dialing by public key. Instead of asking where a peer is, you ask who it is, and iroh takes responsibility for finding and maintaining the fastest connection to that identity. This sounds like a small reframing and is actually a large one. Addresses are an implementation detail that change constantly as devices move between networks, and most of the pain in peer-to-peer code comes from treating a mutable address as if it were a stable identity. Iroh moves that mess behind the API where it belongs.

Underneath, the connection you get is QUIC, authenticated against the key you dialed, which means encryption and identity are not bolted on afterwards but are the substrate. I read through the path where the direct connection cannot be established. Holepunching is attempted first, and when the network is too hostile for that, traffic falls back to a relay. The part I appreciated is that this fallback is not a separate code path you have to handle. From the application's point of view the stream simply stays up, slower but alive. I tested this by severing the direct route mid-transfer and the data kept flowing without my code noticing.

The modularity deserves a mention. This is not a monolith that demands you adopt its worldview. The networking stack is composed of pieces, and you pull in the protocols you actually need on top of the base connection. For anyone who has tried to extract one useful feature from a framework that wanted to own your entire process, this restraint is a relief.

My reservations are mostly about expectations rather than the code. Carrier-grade NAT and aggressively symmetric firewalls will still defeat direct connections, as they defeat everyone, so you must design for the relay path as a normal mode of operation rather than a rare degradation. The relay is good, but it is not free, and a deployment that quietly relays everything will cost more and run slower than the benchmarks on a friendly network suggest. The documentation is solid for getting started, though I had to read the Rust docs directly to understand some of the connection lifecycle, which a more narrative guide could smooth over.

None of that changes my overall read. This is the most honest and least painful peer-to-peer stack I have used in Rust, and it gets the fundamental abstraction right in a way that most attempts do not. I have already started rebuilding a side project on top of it. The question I am sitting with now is less about whether it works and more about operations: at what scale does running your own relay infrastructure become the sensible move rather than leaning on the defaults?