DEV Community: Athreya aka Maneshwar

A VPN Is a Lie You Tell Your Kernel

Athreya aka Maneshwar — Mon, 27 Jul 2026 12:24:24 +0000

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git-lrc to help devs discover the project. Do give it a try and share your feedback.

A VPN is mostly a polite lie you tell your kernel. Here is how EdgeVPN tells it without a single central server, explained by actually reading the Go

I have used VPNs for years without really knowing what one is.

I typed wg-quick up, saw a new interface show up in ip a, and moved on with my life.

Classic dev move: it works, ship it, never look inside.

Then I found EdgeVPN, a VPN written in Go that has no central server at all.

You generate a token, paste it on two machines, and they find each other across the internet and start routing packets.

No control plane, no 10.0.0.1 server you have to keep alive, no cloud bill.

That sounded suspiciously like magic, so I did the only reasonable thing and read the whole codebase.

This post is me walking you through what I found, from "what even is a network interface" all the way down to how a single IP packet crosses the planet without anyone in charge.

Grab a coffee. This one has depth.

First, the uncomfortable truth about VPNs

A VPN is not a tunnel.

A VPN is a lie you tell your operating system, and the OS is very willing to believe you.

Here is the trick.

Linux (and macOS, and Windows) lets you create a TUN device.

It looks like a normal network interface, it shows up in ifconfig, it has an IP, the kernel happily routes traffic to it.

But it is not connected to any hardware.

It is connected to a file descriptor that your program holds.

That is the whole thing. Really:

Your program reads from that file descriptor, and it gets IP packets the kernel wanted to send out.
Your program writes to that file descriptor, and the kernel believes those packets just arrived from the network.

Everything else a VPN does (encryption, peer discovery, routing) is just deciding what happens in the gap between that read and that write.

If you can move bytes from machine A's file descriptor to machine B's file descriptor, congratulations, you have written a VPN.

Everything after this is engineering.

Here is EdgeVPN's read loop, and it is honestly almost anticlimactic:

func getFrame(ifce io.Reader, c *Config) (ethernet.Frame, error) {
    var frame ethernet.Frame
    frame.Resize(c.MTU)

    n, err := ifce.Read([]byte(frame))
    if err != nil {
        return frame, errors.Wrap(err, "could not read from interface")
    }

    frame = frame[:n]
    return frame, nil
}

That is it. That is the interface. ifce is the TUN device, read gives you a raw packet, and now it is your problem.

The hard part is not tunneling, it is the phone book

Now the real question.

Machine A wants to send a packet to 10.1.0.13.

Machine A reads that packet off the TUN device. Cool. Where does it send it?

10.1.0.13 is a made up address.

It exists only inside your virtual network.

Somewhere out there is a real machine, behind a real NAT, with a real (and probably changing) public IP, that has claimed that made up address.

Something has to map one to the other.

WireGuard solves this by making you do it by hand.

You write AllowedIPs and an Endpoint in a config file for every peer.

It is simple, fast, and it does not scale to "I have twelve laptops behind twelve different routers and one of them is my friend's Raspberry Pi."

Traditional VPNs solve it with a server.

The server knows everyone, everyone talks to the server, the server is the phone book. Also the server is the single point of failure, the single point of trust, and the single thing you have to pay for.

EdgeVPN solves it with a gossiped ledger, which is a fancy way of saying: every node keeps shouting what it knows, and everyone eventually agrees. Let me build up to it.

The token is the entire network

Everything starts with one command:

edgevpn -g > config.yaml
# or, as a portable token
export EDGEVPNTOKEN=$(edgevpn -g -b)

The token is just that YAML, base64'd. Nothing more. Decode one and you get roughly this:

otp:
  dht:
    interval: 9000
    key: 7Kx...43-random-chars...
    length: 43
  crypto:
    interval: 9000
    key: Qz9...43-random-chars...
    length: 43
room: bT2...43-random-chars...
rendezvous: mP4...43-random-chars...
mdns: xL8...43-random-chars...
max_message_size: 20971520

Five random strings and two intervals.

No IPs, no hostnames, no server address, no certificates.

This file is your network.

Which brings us to the most important sentence:

Warning Exposing this file or passing-it by is equivalent to give full control to the network.

Hold that thought, we are coming back to it with receipts.

The clever bit is those otp blocks.

Those keys are not used directly.

They are fed into TOTP, the same algorithm behind the 6 digit codes in your authenticator app, except tuned to spit out a long base64 string instead:

func TOTP(f func() hash.Hash, digits int, t int, key string) string {
    cfg := otp.Config{
        Hash:     f,      // sha256 here
        Digits:   digits, // 43
        TimeStep: otp.TimeWindow(t), // 9000 seconds
        Key:      key,
        Format: func(hash []byte, nb int) string {
            return base64.StdEncoding.EncodeToString(hash)[:nb]
        },
    }
    return cfg.TOTP()
}

So every 9000 seconds (2.5 hours), every node in the network independently derives the same new secret, without talking to each other.

Time is the only coordination they need. This gets used for two different things, and both are neat.

Step 1: finding each other at a rotating rendezvous

To meet a stranger on the internet you need a place to meet.

EdgeVPN uses the IPFS Kademlia DHT as that meeting point, announcing itself under a key that is just TOTP(dht.key).

So your rendezvous on a public hash table moves every couple of hours.

A watcher sees peers cluster around a random looking key, then that key goes cold forever.

One subtle trap, nicely handled: if everyone rotates at exactly time T, a node with a skewed clock rotates early and for a moment nobody finds anybody.

So the DHT announces on the last two rendezvous points at once:

rendezvousHistory: Ring{Length: 2}

Overlapping windows. Unglamorous, and exactly the difference between "works in the demo" and "works at 3am".

On a LAN, mDNS does the same job with the mdns string as the service tag.

Here is the full bootstrap:

Notice the ordering. Peers connect first, and then they exchange the routing table.

The routing table travels over the p2p network it describes. Bootstrapping is fun.

Step 2: the gossip room, sealed twice

Connected peers join a GossipSub topic named from the other OTP.

libp2p already encrypts every connection, and EdgeVPN still wraps another AES layer around each message, keyed the same rotating way:

func (e *Node) sealkey() string {
    return internalCrypto.MD5(internalCrypto.TOTP(sha256.New, e.config.SealKeyLength, e.config.SealKeyInterval, e.config.ExchangeKey))
}

Why double up? The rendezvous is public, so anyone can find the topic and subscribe.

Transport encryption protects the hop, not the payload from someone who legitimately joined the room.

The seal means a lurker hears noise, and since the key retires every 2.5 hours, brute forcing captured traffic chases a key nobody uses anymore.

Layers of secrets, rotating on a timer, all from one shared string. Most elegant idea in the codebase.

Step 3: the ledger, or "eventual consistency by shouting"

Now the phone book. EdgeVPN keeps a tiny blockchain. Before you close the tab: no proof of work, no mining, no coin.

It is a chain of blocks purely for cheap ordering, and each block carries a map[bucket]map[key]value.

The buckets are hardcoded constants that read like a table of contents for the whole product:

const (
    FilesLedgerKey    = "files"
    MachinesLedgerKey = "machines"
    ServicesLedgerKey = "services"
    UsersLedgerKey    = "users"
    HealthCheckKey    = "healthcheck"
    DNSKey            = "dns"
    EgressService     = "egress"
    TrustZoneKey      = "trustzone"
    TrustZoneAuthKey  = "trustzoneAuth"
)

The routing table is just the machines bucket keyed by virtual IP.

Every feature here is "write to a bucket, read other people's writes".

Once that clicked the codebase went from clever to obvious, which is the best thing you can say about an architecture.

Conflict resolution is beautifully blunt:

last := l.blockchain.Last()
if block.Index > last.Index ||
    (block.Index == last.Index && block.Hash > last.Hash) {
    l.blockchain.Add(*block)
}

Highest block wins, ties broken by higher hash so every node breaks them identically. Whole block replace, no vector clocks, no Raft.

"But that loses writes," you say. Yes! And it does not matter, because every node reannounces its own state on a ticker until it sees itself reflected in the chain.

Read it, check if the world agrees with you, and if not, say it again. Louder. Forever.

The system converges not because the merge is smart but because everyone is relentlessly repetitive.

Wipe the entire chain and the nodes refill it in seconds.

The tradeoff is real and the docs own it: every block goes to every peer, so this is chatty by design.

Fine for a routing table, which is why the README warns you off latency sensitive workloads.

Step 4: an actual packet, end to end

Here is the life of one ping, with the real function names.

The lookup is where every piece meets:

value, found := ledger.GetKey(protocol.MachinesLedgerKey, dst)
if !found {
    return notFoundErr
}
machine := &types.Machine{}
value.Unmarshal(machine)

// Decode the Peer
d, err = peer.Decode(machine.PeerID)

Virtual IP goes in, libp2p peer ID comes out.

That one lookup replaces the entire VPN server, and libp2p handles the rest: NAT traversal, hole punching, relays, encryption, multiplexing.

The receiving end checks the sender against that same ledger before copying a byte, and resets the stream otherwise.

If you are not in my routing table, I will not read your packets.

Two jobs, one map.

The bit I did not expect to enjoy: leaderless leader election

Every node drops a timestamp into a healthcheck bucket, and anyone older than maxtime counts as gone.

But some jobs need exactly one node to run them (scrubbing stale entries, handing out IPs).

With no server, who decides? This:

func Leader(actives []string) string {
    leaderboard := map[string]uint32{}
    leader := actives[0]

    for _, a := range actives {
        leaderboard[a] = hash(a) // fnv32a
        if leaderboard[leader] < leaderboard[a] {
            leader = a
        }
    }
    return leader
}

Hash every live peer ID, highest wins. No votes, no terms, no Raft.

Every node computes it locally and agrees, because the ledger already synced the input.

When the leader dies it falls out of the healthcheck bucket, everyone recomputes, and a new leader appears with zero messages exchanged.

Is it Paxos? No. Does deciding who deletes stale map entries need Paxos? Also no. Right sized engineering is underrated.

Same trick powers the built in DHCP: nodes without an IP wait, the leader among them takes the lowest free one, next node repeats.

Distributed DHCP with no DHCP server, built from a hash function and patience.

Now, about that token

Remember that warning. In the default config, holding the token lets you write anything into any bucket. Including this:

machines/10.1.0.13 -> { PeerID: "my-peer-id-actually" }

Congratulations, you just hijacked someone's virtual IP and every node will happily route their traffic to you.

The routing table has no concept of who owns which key.

That is the sort of thing you only catch by reading source, and to their credit the project keeps layering in defenses.

PeerGuardian (pkg/trustzone) adds ECDSA challenge and response, so the token alone does not get you in.

Relay ACL (pkg/config/relay_acl.go) gates who can use you as a circuit relay, with an open bootstrap window because a NAT'd peer often needs a relay before it can prove membership. Chicken and egg, at the network layer.

The good one is ledger ownership (pkg/blockchain/sign.go): sign every entry with the node's libp2p key and enforce per key ownership on merge, in three modes, off, observe, enforce.

That middle mode is the detail I liked most.

Turn it on in a live network, watch the violation logs for a week, then flip to enforce.

That is how you ship a breaking security change to something you cannot restart all at once.

The README also says it plainly: "I'm not a security expert, and this software didn't went through a full security audit".

Respect for that instead of stamping "military grade encryption" on a landing page.

The layer cake

Zooming out, here is how the whole thing stacks.

Everything above the node is optional and plugs into the same two extension points:

The dotted lines matter. Control traffic (who owns what) goes through the gossip ledger, slowly and to everyone.

Data traffic (your actual packets) goes point to point over a dedicated libp2p stream protocol, directly to the one peer that needs it.

Mixing those up is how you build something that falls over at four nodes.

The extension seam is two types, and once you see them you can read any feature in the repo:

// something long running that gets the node and the ledger
type NetworkService func(context.Context, Config, *Node, *blockchain.Ledger) error

// something that handles a raw stream for a given protocol ID
type StreamHandler func(*Node, *blockchain.Ledger) func(stream network.Stream)

The VPN is a NetworkService. So is DNS. So is the file transfer. So is the healthcheck.

Adding a feature means picking a bucket name, announcing into it, and optionally claiming a protocol ID for the data path.

That is the whole framework.

What I actually took away

Coordination is the actual product. WireGuard says "you coordinate, I will be fast". Commercial VPNs say "a server coordinates, pay us". EdgeVPN says "we gossip until we agree". The question was never encryption.

Repeating yourself beats being clever. Every node reannounces its own truth forever, so the merge logic gets to be ten dumb lines and still heals from total data loss. Idempotent shouting as a consistency model. I am stealing this.

Go read some source code. The scariest part of most systems is the part you have not looked at yet, and it is usually about 300 lines.

Repo is github.com/mudler/edgevpn, docs are here, and libp2p's docs are where the real dark magic lives.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs — without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Git Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

GenAI today is a race car without brakes. It accelerates fast -- you describe something, and large blocks of code appear instantly. But AI agents silently break things: they remove logic, relax constraints, introduce expensive cloud calls, leak credentials, and change behavior -- without telling you. You often find out in production.

git-lrc is your braking system. It hooks into git commit and runs an AI review on every diff before it lands. 60-second setup. Completely free.

In short, git-lrc helps Prevent Outages, Breaches, and Technical Debt Before They Happen

At a glance: 10 risk categories · 100+ failure patterns tracked · every commit…

View on GitHub

How terminal-sharing tools put your shell in a browser

Athreya aka Maneshwar — Sun, 26 Jul 2026 16:43:17 +0000

You have probably done this dance.

You are debugging something on a box, your teammate says "can you just show me", and you end up screen sharing a 4K monitor over a video call so they can squint at 11px monospace text that has been compressed into oatmeal.

There is a better way, and it has existed for years.

Tools like ttyd, TermPair, and sshx put your actual terminal in someone else's browser. Real text. Real selection.

Real copy paste.

I got curious about how they pull this off, so I cloned all three and read them.

Turns out they are solving the same problem in three very different ways, and the differences are genuinely interesting.

Let's get shell shocked together.

what even is a terminal

Before any of the web stuff makes sense, you need one concept: the pseudoterminal, or PTY.

When you run bash in your terminal app, bash is not talking to your keyboard.

It is talking to a file.

Specifically, a pair of linked file descriptors that the kernel sets up to impersonate an actual physical teletype from 1965.

One end is the master, one end is the slave.

Your terminal emulator holds the master. Bash holds the slave, and bash has no idea it is being catfished.

Anything you write to the master shows up as keyboard input to bash. Anything bash prints comes back out of the master.

That is the entire trick.

Terminal sharing tools are just programs that hold the master end and forward those bytes somewhere more interesting than a window on your laptop.

Here is sshx doing exactly that, in crates/sshx/src/terminal/unix.rs:

use nix::pty::{self, Winsize};
use nix::unistd::{execvp, fork, ForkResult, Pid};
use nix::libc::{login_tty, TIOCGWINSZ, TIOCSWINSZ};

pub struct Terminal {
    child: Pid,
    master_read: File,
    master_write: File,
}

Fork, call login_tty in the child so the slave fd becomes its controlling terminal, execvp the shell, and keep the master in the parent.

ttyd does the same thing in C.

TermPair does it in Rust.

Three codebases, one ancient POSIX handshake.

Everyone takes the same fork in the road.

Oh, and TIOCSWINSZ is how the terminal size gets set.

When you resize your browser window, that ioctl is what eventually fires so that vim redraws correctly instead of smearing itself across the screen.

Resize handling is not a nice-to-have here, it is load bearing.

The simplest possible version: ttyd

ttyd is the "no, seriously, that's it" implementation.

One C process, built on libwebsockets and libuv.

It is the web server and it is the terminal host.

There is no relay, no separate client, no key exchange.

The protocol is beautifully dumb. From src/server.h:

// client -> server
#define INPUT           '0'
#define RESIZE_TERMINAL '1'
#define PAUSE           '2'
#define RESUME          '3'
#define JSON_DATA       '{'

// server -> client
#define OUTPUT            '0'
#define SET_WINDOW_TITLE  '1'
#define SET_PREFERENCES   '2'

Single byte opcode, then payload. That is the whole wire format.

'0' plus your keystrokes goes up, '0' plus terminal output comes down.

PAUSE and RESUME exist because a fast-scrolling cat of a huge file can outrun the browser, so the client can apply backpressure instead of dying.

Here is the full round trip:

Two details worth stealing from ttyd:

The frontend ships inside the binary.

The Preact and xterm.js app in html/ gets bundled, gzipped, and inlined into src/html.h as a C byte array.

You get a single executable with no static file directory to misplace.

The tradeoff is that touching a .tsx file means running yarn run inline and then rebuilding the C binary, which surprises people exactly once.

It is read only by default. You have to pass -W to let viewers actually type.

ttyd -p 7681 -c user:pass -O -W bash

That said, ttyd's threat model is "you trust the server, because the server is your machine."

The bytes are plaintext over the wire unless you turn on TLS.

Which brings us to the interesting question.

What if you don't trust the server?

The moment you want to share a terminal with someone across the internet, you need a middleman with a public IP. And now that middleman can read everything you type.

TermPair and sshx both took that guy's advice.

They make the server a blind relay: it routes ciphertext between the terminal host and the browsers, and it structurally cannot decrypt any of it.

Green means "can read your terminal."

The whole game is shrinking the green.

The key delivery trick

So the client encrypts and the browser decrypts. Both need the key.

The server must not have it. But the browser gets its entire existence from the server.

How do you hand a secret to a page that the server itself sent you?

The answer is a URL fragment.

https://sharemyclau.de/s/abc123#key-goes-right-here

Everything after # is never sent in the HTTP request.

It is a client side construct.

Browsers use it for anchor scrolling and hash routing, and it stays in the address bar and in JavaScript's location.hash while the server sees only /s/abc123.

So you share one link, the recipient's browser reads the key out of its own address bar, and the relay in the middle sees an opaque session ID and a stream of noise.

Here is the flow end to end:

The security of this rests entirely on the link. Anyone who gets the full URL gets the session.

Don't paste it in a public Slack channel and then act surprised.

Two flavors of crypto

TermPair and sshx both do AES, but they made different calls, and the differences are instructive.

TermPair: AES-128-GCM with counter IVs

From crates/termpair-common/src/encryption.rs:

pub fn iv_from_count(count: u64) -> [u8; IV_LENGTH] {
    let mut iv = [0u8; IV_LENGTH];
    let bytes = count.to_le_bytes();
    iv[..bytes.len()].copy_from_slice(&bytes);
    iv
}

GCM gives you authentication for free, so a tampered message fails to decrypt rather than quietly turning into garbage that your terminal then interprets as escape sequences.

The IV is a plain message counter, which is fine and correct as long as you never reuse one with the same key.

Nonce reuse in GCM is not a "slightly weaker" situation, it is a "here is your key, thanks for playing" situation.

Which is why constants.rs has this:

pub const ROTATION_THRESHOLD: u64 = 1 << 20;
pub const MAX_MESSAGES_PER_KEY: u64 = ROTATION_THRESHOLD * 2;

After about a million messages, the key rotates.

There is a whole aes_key_rotation event in the protocol for it.

Separate keys for terminal output and browser input, plus a bootstrap key for the handshake, so the counter spaces cannot collide.

It is careful work, and the kind of thing that is invisible when it is done right.

sshx: Argon2 stretched key with AES-CTR

sshx made a different bet. From crates/sshx/src/encrypt.rs, with a comment I really enjoyed:

const SALT: &str =
    "This is a non-random salt for sshx.io, since we want to stretch the security of 83-bit keys!";

let hasher = Argon2::new(
    Algorithm::Argon2id,
    Version::V0x13,
    Params::new(19 * 1024, 2, 1, Some(16)).unwrap(),
);

The key in your URL is only 83 bits of entropy, because sshx wants the shareable link to stay short enough to actually paste in chat.

83 bits is not a lot by modern standards, so it runs Argon2id over it with real memory cost parameters. Brute forcing now costs 19MB and real CPU time per guess instead of a nanosecond.

It is a deliberate trade of raw entropy for ergonomics, paid back with a KDF.

Then it uses CTR mode with a clever addressing scheme:

pub fn segment(&self, stream_num: u64, offset: u64, data: &[u8]) -> Vec<u8> {
    assert_ne!(stream_num, 0, "stream number must be nonzero"); // security check
    let mut iv = [0; 16];
    iv[0..8].copy_from_slice(&stream_num.to_be_bytes());
    let mut cipher = Aes128Ctr64BE::new(&self.aes_key.into(), &iv.into());
    cipher.seek(offset);
    cipher.apply_keystream(&mut buf);
    buf
}

Because CTR mode is seekable, sshx can encrypt "the bytes at offset N of stream M" without touching anything before them.

That is not a crypto flex, it is an architecture decision: it means a browser that reconnects can say "I have everything up to byte 4096, send me the rest" and the server can serve that from its buffer.

Encryption and resumability designed together.

The assert_ne!(stream_num, 0) guard is there because stream 0 is used for the encrypted zeros block that proves you have the right key.

Reusing it would mean reusing a keystream.

Nice to see the security check written down instead of assumed.

The part that makes sshx feel fast

Here is my favorite detail in any of these codebases.

There is a fundamental problem with remote terminals: your keystroke has to go to the server, into the PTY, back out, and back to you before you see the character.

On a 200ms link, typing feels like moving through syrup.

sshx solves this the way Mosh does, with predictive echo. From src/lib/typeahead.ts:

// A terminal "local echo" or typeahead addon for xterm.js.
//
// This is forked from VSCode's typeahead implementation at
// https://github.com/microsoft/vscode/blob/1.80.1/...

The client guesses. You press k, it draws a k immediately (slightly dimmed) while the real round trip happens in the background.

When the server's actual output arrives, it reconciles.

If the guess was right, nothing visibly changes.

If it was wrong, because you were in vim or hitting a password prompt, it rolls back.

The tricky part is knowing when not to predict.

Predicting into a password prompt would echo your password onto the screen, which is a memorable way to lose a friend.

So the addon tracks terminal modes and bails out when it is not confident.

Getting a-head of the output, but politely.

Sessions, state, and the boring stuff that matters

The last layer is lifecycle. Sessions are long lived, connections are not. Wifi drops. Laptops sleep.

sshx handles this with sequence numbers in the protocol (crates/sshx-core/proto/sshx.proto):

message TerminalData {
  uint32 id = 1;
  bytes data = 2;
  uint64 seq = 3;  // Sequence number of the first byte
}

message SequenceNumbers {
  map<uint32, uint64> map = 1;  // Active shells and their sequence numbers
}

Every shell is a stream with a byte offset. On reconnect, the client sends where it left off and the server replays the difference.

Combined with seekable CTR encryption, resume is nearly free.

It also has to decide when to give up on a session:

/// Timeout for a disconnected session to be evicted and closed.
const DISCONNECTED_SESSION_EXPIRY: Duration = Duration::from_secs(300);

Five minutes without a backend client and the session is closed and dropped from the DashMap. Otherwise every crashed laptop leaks memory forever.

And because sshx runs a globally distributed mesh, session state also goes into Redis via crates/sshx-server/src/state/mesh.rs, so you can connect to the nearest server rather than always crossing an ocean.

TermPair, meanwhile, caps things with hard limits (MAX_TERMINALS: 200, MAX_BROWSERS_PER_TERMINAL: 50, MAX_WS_MSGS_PER_SEC: 500) which is the sensible answer when you are running one modest box instead of a mesh.

So which one should you use

Genuinely depends on what you are doing.

ttyd if the network is already trusted. Homelab, LAN, behind a VPN, embedded devices, an OpenWrt router. It is one small C binary with no runtime dependencies and it will outlive us all. ttyd -W bash and you are done.

TermPair if you want end to end encryption with a simple mental model and the option to self host the relay. The three-key design with rotation is easy to reason about and the code is small enough to read in an afternoon.

sshx if you want the polished product experience. Multiple terminals on an infinite canvas, other people's cursors moving in real time, predictive echo, global mesh, automatic reconnect. Worth noting the README says self hosting is explicitly not supported, so this is "use sshx.io" rather than "run your own."

The takeaway

Every one of these tools is, at its core, fork(), a PTY master fd, and a loop that shovels bytes into a WebSocket.

That part is 1970s technology wearing a 2020s hoodie.

Everything else, the encryption, the sequence numbers, the key rotation, the predictive echo, the session eviction, exists to answer one question: how much do you trust the machine in the middle? ttyd says "it's mine, so completely."

TermPair and sshx say "not at all, and here is the math."

Reading three implementations of the same idea side by side is the fastest architecture lesson I have had in a while.

If a concept keeps showing up in every version, it is essential.

If it only shows up in one, it is a product decision.

That distinction is hard to see from a single codebase and obvious from three.

Go clone them.

It is more fun than another framework tutorial, and you will never look at location.hash the same way again.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs — without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Git Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc is your braking system. It hooks into git commit and runs an AI review on every diff before it lands. 60-second setup. Completely free.

In short, git-lrc helps Prevent Outages, Breaches, and Technical Debt Before They Happen

At a glance: 10 risk categories · 100+ failure patterns tracked · every commit…

View on GitHub

I'm a Dev Who Barely Knows the Kernel. Here's How I'm Learning How to Track a Packet with pwru

Athreya aka Maneshwar — Sat, 25 Jul 2026 13:01:01 +0000

Hey, so here's a confession.

My idea of "networking debugging" used to top out at iptables -L -v -n, squinting at counters, and occasionally yelling "WHY IS IT DROPPING" at a terminal that does not care about my feelings.

I know just enough kernel to be dangerous: I know packets go in, sometimes they don't come out, and somewhere in between there's a black box that I was told is "the kernel networking stack."

Then I found cilium/pwru sitting in a repo I was poking around, and it broke my brain a little.

So I read the source, dragged my devops brain through it, and now I'm going to explain it to you the way I wish someone had explained it to me.

No kernel PhD required.

Some puns required.

The problem: packets don't have a call stack you can just `console.log`

As a web dev, when something's broken, I add a console.log, or I set a breakpoint, or worst case I print my way to enlightenment.

The request comes in, flows through my middleware, my handlers, my ORM, and I can trace every step because it's all just... functions calling functions, in my process, in my language.

A packet inside the Linux kernel does not work like that.

It gets handed from function to function across the network stack (ip_rcv, tcp_v4_rcv, netfilter hooks, qdiscs, the works), it can get cloned, NAT'd, encapsulated in a tunnel, handed to a virtual ethernet pair, sent through an eBPF program of its own, and dropped at literally any of a few thousand points, often silently.

There's no stack trace.

There's no packet.log().

The tool you reach for as a network person is tcpdump, which is great for seeing a packet arrive and a packet leave, but useless for seeing what happened to it in between, inside the kernel, especially when it never arrives at all.

That's the gap pwru (packet, where are you?) fills.

It's basically an eBPF-powered console.log for the kernel's packet path.

Attaching a debugger to (checks notes) every function in the kernel

Here's the first thing that made my jaw drop reading this codebase.

Instead of the pwru authors hand-picking a list of "interesting" kernel functions to trace (which is what I assumed, naively), they let BTF (BPF Type Format, basically the kernel's own type metadata) do the work for them.

In internal/pwru/utils.go, GetFuncs walks the entire kernel type database, looks at every single function's signature, and asks one question: "does any of your first five parameters point to a struct sk_buff?" If yes, that function touches a packet, and it gets added to the hit list.

if ptr, ok := p.Type.(*btf.Pointer); ok {
    if strct, ok := ptr.Target.(*btf.Struct); ok {
        if strct.Name == "sk_buff" && i <= 5 {
            funcs[name] = i
            continue
        }
    }
}

That's it. That's the whole discovery mechanism.

On a typical kernel this turns up a few thousand functions, and pwru then kprobes (or kprobe-multi attaches, in batches, concurrently) all of them, at once.

Every one of those probes runs the same handler, checks your filter, and if it matches, ships an event to userspace.

Coming from web dev, this is the equivalent of somebody saying "instead of adding logging to the 12 functions we think matter, let's just instrument literally every function in the entire codebase that touches a Request object" and then actually shipping it in a way that doesn't melt the server.

It's completely unhinged in the best way, and it works because eBPF probes are cheap enough (and the filtering happens in-kernel, before the event ever reaches userspace) that "just trace everything" is a viable strategy.

Here's roughly what that discovery-and-attach pipeline looks like:

Wait, you can reuse tcpdump filters here?

The second thing that made me feel at home: you don't write eBPF filter logic by hand, you write a normal pcap-filter expression.

The same syntax from tcpdump.

The stuff every devops person already has muscle memory for, like tcp and port 443 or host 10.0.0.5.

pwru --output-tuple 'host 1.1.1.1 and tcp'

How does that actually work under the hood? This is the part where I had to reread the code three times.

pwru takes your pcap expression, compiles it to classic BPF (cBPF, the old-school packet filter bytecode, same lineage as tcpdump -d) using cloudflare/cbpfc to translate cBPF into modern eBPF instructions, and then splices those raw instructions directly into the loaded eBPF program, at a specific marker function it planted for exactly this purpose:

for idx, inst := range program.Instructions {
    if inst.Symbol() == "filter_pcap_ebpf"+suffix {
        injectIdx = idx
        break
    }
}

In bpf/kprobe_pwru.c there's a deliberately empty, __noinline placeholder function called filter_pcap_ebpf_l3 / _l2 whose only job is to exist as an injection point:

static __noinline bool
filter_pcap_ebpf_l3(void *_skb, void *__skb, void *___skb, void *data, void* data_end)
{
    return data != data_end && _skb == __skb && __skb == ___skb;
}

pwru finds that function in the compiled instruction stream and literally performs bytecode surgery, cutting it out and stitching in your compiled filter instead, before the program is even loaded into the kernel.

It's like if your reverse proxy let you write location blocks in nginx syntax, but under the hood it was actually recompiling and hot-patching the C binary per request. Deranged. Also very cool.

The hard part: knowing it's "the same packet"

Okay here's the thing that actually made me appreciate why this tool needed to exist and isn't just "kprobe everything and print."

A packet does not keep a fixed identity as it flows through the kernel.

NAT rewrites its IP/port, so your 5-tuple filter (host 1.1.1.1) can stop matching halfway through the journey, right after the thing you were trying to debug happens.
It can get cloned (skb_clone) or copied (skb_copy) for things like local delivery plus forwarding.
It can cross a veth pair into another network namespace, get handed to an XDP program, or get bridged, where the original sk_buff might legitimately get freed and a new one used to represent conceptually "the same" packet.

So pwru maintains a small state machine to keep following a packet even after your original filter would technically stop matching.

Once a packet matches your filter once, its pointer gets remembered in a skb_addresses BPF hash map (bpf/kprobe_pwru.c), and every subsequent kprobe hit checks that map first, before even bothering with your filter again:

if (cfg->track_skb && bpf_map_lookup_elem(&skb_addresses, &skb_addr)) {
    tracked_by = _stackid ? TRACKED_BY_STACKID : TRACKED_BY_SKB;
    goto cont;
}

When the skb gets cloned, an fexit probe on skb_clone/skb_copy propagates the "yes, we're tracking this one" flag from the old pointer to the new one.

When the kernel finally frees it (kfree_skbmem), pwru cleans up the tracking entry so the map doesn't grow forever.

For the gnarlier case, like bridging, where the pointer identity is genuinely lost, there's a --filter-track-skb-by-stackid mode that fingerprints by call stack instead of pointer, so it can pick the "same" packet back up under a new address.

This is basically the eBPF equivalent of trying to correlate a request across microservices without a trace ID: you're stitching identity back together from context clues because nobody handed you a clean handle to hold onto.

Turning "packet vanished" into an actual reason

The best part for someone coming from iptables-land: when a packet dies, pwru doesn't just say "the trace stopped here, good luck."

It hooks kfree_skb_reason and decodes the kernel's skb_drop_reason enum, so you get an actual human string like SKB_DROP_REASON_NETFILTER_DROP instead of silence.

That's the difference between "curl hung and I have no idea why" and "curl hung, and here is the literal function and the literal drop reason, with a timestamp."

The README's example is exactly the workflow I'd have wanted a year ago: run a curl, install an iptables DROP rule, run pwru, and watch it print the exact function where the packet gets killed, instead of you bisecting iptables -L rules by hand at 2am.

Why this clicked for a devops brain

If you've ever debugged distributed systems, this whole tool is basically:

Structured, filtered logging (pcap-filter syntax you already know), applied to
Every relevant call site automatically (via BTF introspection instead of a hand-maintained list), with
Identity tracking across mutation and forking (NAT, clone, tunnel, bridge) so your trace doesn't just stop the moment the packet changes shape, and
A resolved root cause at the end (the drop reason) instead of a shrug emoji.

That's a debugging methodology, not just a tool.

It's the "attach a debugger to the whole system, but keep it filtered so it doesn't drown you, and correlate identity across boundaries" pattern, and it happens to be implemented with kprobes and BTF instead of trace IDs and Jaeger.

Here's the shape of what happens end to end, from the kprobe firing to a line on your screen:

Wrapping up

I still don't "know the kernel."

But I don't need to anymore, at least not for this. pwru turned "the kernel is a black box that eats packets" into "the kernel is a big, well-typed program I can attach cheap breakpoints to, filter with syntax I already know, and follow even when it tries to shapeshift on me."

If you're a web/devops person who's only ever fought the network stack from the outside with iptables and tcpdump, go read bpf/kprobe_pwru.c and internal/pwru/utils.go.

It reads less like kernel wizardry and more like a really well-designed observability tool that happens to live one layer lower than you're used to.

Packet, where are you? Increasingly, I actually know how to ask.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs — without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Git Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc is your braking system. It hooks into git commit and runs an AI review on every diff before it lands. 60-second setup. Completely free.

In short, git-lrc helps Prevent Outages, Breaches, and Technical Debt Before They Happen

At a glance: 10 risk categories · 100+ failure patterns tracked · every commit…

View on GitHub

6 Open Source Tools That Give You the Web Back

Athreya aka Maneshwar — Fri, 24 Jul 2026 12:39:50 +0000

You've probably noticed this if you've tried to fetch a public webpage in the last two years.

You write four lines of Python. You get a 403. You add a User-Agent header. You get a 403 with better manners.

You spin up headless Chrome and get a challenge page that spins forever.

Eventually you go looking at pricing pages for data APIs, where a cheerful landing page offers to sell you back the exact same public HTML for $100 a month.

Meanwhile the big labs vacuumed up that same web at a scale none of us will ever match, and now the standard way to read a page programmatically is to pay somebody.

The web went from "open by default" to "open, but only if you look like a person holding a mouse."

So let's talk about eight open source projects quietly clawing that access back. I've used most of these in anger. Some are brilliant.

Quick note on star counts: I mention a few, because they are a decent signal of "somebody else has hit the bugs before you." They are not a signal of maintenance. A repo can have 70k stars and a last commit from 2023. Always check the commit graph before you check the star count.

1. Firecrawl: the one that turned a URL into a prompt

What it does: you hand it a URL, it hands you clean markdown. Not HTML with the nav bar and the cookie banner and four newsletter modals. Markdown. Headings, paragraphs, links, done.

It also does more than single pages.

The crawl endpoint walks a whole site, map gives you a URL inventory without fetching everything, and structured extraction pulls typed JSON out of a page if you describe the shape you want.

from firecrawl import Firecrawl

app = Firecrawl(api_key="fc-...")
doc = app.scrape("https://example.com/docs/getting-started",
                 formats=["markdown"])
print(doc.markdown)

Reach for it when: you want the web as text, you want it now, and you would rather ship the feature than build a crawling team.

firecrawl / firecrawl

The API to search, scrape, and interact with the web at scale. 🔥

🔥 Firecrawl

The API to search, scrape, and interact with the web at scale. 🔥 The web context API to find sources, extract content, and turn it into clean Markdown or structured data your agents can ship with. Open source and available as a hosted service.

Pst. Hey, you, join our stargazers :)

Why Firecrawl?

Industry-leading reliability: Covers 96% of the web, including JS-heavy pages — no proxy headaches, just clean data (see benchmarks)
Blazingly fast: P95 latency of 3.4s across millions of pages, built for real-time agents and dynamic apps
LLM-ready output: Clean markdown, structured JSON, screenshots, and more — spend fewer tokens, build better AI apps
We handle the hard stuff: Rotating proxies, orchestration, rate limits, JS-blocked content, and more — zero configuration
Agent ready: Connect Firecrawl to any AI agent or MCP client with a single command
Media parsing…

View on GitHub

2. Crawl4AI: the same idea, but yours

What it does: an open source, async Python crawler that outputs LLM-ready markdown.

No API key. No credits. No rate limit other than the one your target site imposes and the one your conscience should.

import asyncio
from crawl4ai import AsyncWebCrawler

async def main():
    async with AsyncWebCrawler() as crawler:
        result = await crawler.arun(url="https://example.com")
        print(result.markdown)

asyncio.run(main())

Reach for it when: you have volume, you have infra people, or you have data you cannot legally hand to a third party service.

unclecode / crawl4ai

🚀🤖 Crawl4AI: Open-source LLM Friendly Web Crawler & Scraper. Don't be shy, join here: https://discord.gg/jP8KfhDhyN

🚀🤖 Crawl4AI: Open-source LLM Friendly Web Crawler & Scraper.

🚀 Crawl4AI Cloud API — Closed Beta (Launching Soon)

Reliable, large-scale web extraction, now built to be drastically more cost-effective than any of the existing solutions.

👉 Apply here for early access
We’ll be onboarding in phases and working closely with early users Limited slots.

Crawl4AI turns the web into clean, LLM ready Markdown for RAG, agents, and data pipelines. Fast, controllable, battle tested by a 50k+ star community.

✨ Check out latest update v0.9.2

✨ New in v0.9.2: Maintenance patch release. Fixes a MemoryAdaptiveDispatcher task/page leak when a streaming crawl is closed, Docker Playground "Advanced Config" and Monitor WebSocket auth, Playwright headless-shell packaging, and GPU (ENABLE_GPU=true) Docker builds. Release notes →

✨ Recent v0.9.0: Major secure-by-default release of the Docker API server. Auth is on by default, the server binds loopback unless given a token, and the…

View on GitHub

Also, both of these projects have converged on the same insight, which is fun to watch.

3. Browser-use: an agent with hands

What it does: wires an LLM to a real browser and lets it drive. Clicking, typing, scrolling, filling forms, logging in, navigating a multi step checkout.

You describe the goal in English, it figures out the DOM.

Reach for it when: the target is genuinely interactive, the volume is low, and the alternative is a human doing it by hand.

browser-use / browser-use

🌐 Make websites accessible for AI agents. Automate tasks online with ease.

What can Browser Use do?

Browser Use lets an AI agent use a web browser the same way you do — it opens pages, clicks buttons, types, and fills in forms. You describe the task, and it completes it. For example, you can have it:

📋 Fill Forms

Task: "Fill in this job application with my resume and information."

Example code ↗

🍎 Extract data

Task: "Extract structured data about my followers and export it as a CSV."

extract-followers.mp4

Browser Use Cloud Docs ↗

💻 QA Automation

Task: "QA test my local website and report any bugs, usability issues, and visual inconsistencies."

Browser Use CLI ↗

Quickstart

If you want to use Browser Use in your agent (Claude Code, Codex, Cursor, Hermes, OpenClaw, etc.), paste this prompt, and it sets everything up itself:

Install or upgrade browser-use to the latest stable version with uv using Python 3.12, run `browser-use skill

…

View on GitHub

4. Scrapy: the one that was doing this before it was cool

What it does: the Python crawling framework. Request scheduling, concurrency, retries, middleware, item pipelines, autothrottle, the works.

It has been in production since roughly 2008 and it has crawled more pages than every other tool on this list combined.

Reach for it when: high volume, stable, mostly static targets. It is the boring correct answer and boring correct answers pay the bills.

scrapy / scrapy

Scrapy, a fast high-level web crawling & scraping framework for Python.

Scrapy is a web scraping framework to extract structured data from websites. It is cross-platform, and requires Python 3.10+. It is maintained by Zyte (formerly Scrapinghub) and many other contributors.

Install with:

pip install scrapy

And follow the documentation to learn how to use it.

If you wish to contribute, see Contributing.

View on GitHub

5. Crawlee: the infrastructure you were about to rebuild badly

What it does: the Node.js (and now Python) crawling library from the Apify folks.

Proxy rotation, session management, browser fingerprint spoofing, automatic retries with backoff, request queues that survive a restart, and a unified API whether you are using plain HTTP or Playwright or Puppeteer under the hood.

Reach for it when: you are in the Node ecosystem, or your targets are actively hostile and you need the anti-blocking stack without paying for one.

apify / crawlee

Crawlee—A web scraping and browser automation library for Node.js to build reliable crawlers. In JavaScript and TypeScript. Extract data for AI, LLMs, RAG, or GPTs. Download HTML, PDF, JPG, PNG, and other files from websites. Works with Puppeteer, Playwright, Cheerio, JSDOM, and raw HTTP. Both headful and headless mode. With proxy rotation.

A web scraping and browser automation library

Crawlee covers your crawling and scraping end-to-end and helps you build reliable scrapers. Fast.

Your crawlers will appear human-like and fly under the radar of modern bot protections even with the default configuration. Crawlee gives you the tools to crawl the web for links, scrape data, and store it to disk or cloud while staying configurable to suit your project's needs.

Crawlee is available as the crawlee NPM package.

👉 View full documentation, guides and examples on the Crawlee project website 👈

Do you prefer 🐍 Python instead of JavaScript? 👉 Checkout Crawlee for Python 👈.

Installation

We recommend visiting the Introduction tutorial in Crawlee documentation for more information.

Crawlee requires Node.js 16 or higher.

With Crawlee CLI

The fastest way to try Crawlee out is to use the Crawlee CLI and choose the Getting started example. The CLI will…

View on GitHub

6. Scrapling: the scraper that heals itself

What it does: a Python scraper that remembers what an element was, so when the site redesigns and your .product-title becomes .ProductCard__title--x7f2, it re-locates the element by similarity instead of returning an empty list.

Reach for it when: you maintain many spiders over a long time and selector rot is your actual bottleneck.

D4Vinci / Scrapling

🕷️ An adaptive Web Scraping framework that handles everything from a single request to a full-scale crawl!

Effortless Web Scraping for the Modern Web

Selection methods · Fetchers · Spiders · Proxy Rotation · CLI · MCP

Scrapling is an adaptive Web Scraping framework that handles everything from a single request to a full-scale crawl.

Its parser learns from website changes and automatically relocates your elements when pages update. Its fetchers bypass anti-bot systems like Cloudflare Turnstile out of the box. And its spider framework lets you scale up to concurrent, multi-session crawls with pause/resume and automatic proxy rotation - all in a few lines of Python. One library, zero compromises.

Blazing fast crawls with real-time stats and streaming. Built by Web Scrapers for Web Scrapers and regular users, there's something for everyone.

from scrapling.fetchers import Fetcher, AsyncFetcher, StealthyFetcher, DynamicFetcher
StealthyFetcher.adaptive =

…

View on GitHub

About that "sell this as a service for $5,000 a month" thing

Every video on this topic ends with the same pitch: lead gen agencies charge thousands a month for this data, your cost is zero, go get rich.

I want to be careful here, because there is a real business in web data, but "your cost is zero" is doing an enormous amount of work in that sentence.

Your cost is not zero.

Your cost is residential proxies, which are the single biggest line item and which no open source project ships.

Your cost is CAPTCHA solving.

Your cost is the engineer-hours when four targets redesign in the same week.

Your cost is storage, monitoring, and the pager.

What those agencies are actually charging for is not the scraping code, which as you have just seen is free and excellent.

They are charging for the operational layer and the guarantee that the data shows up on Monday even though the site changed on Sunday.

That is a real service and it is worth real money.

Just go in knowing what you are actually selling.

The boring section that keeps you out of trouble

You knew this was coming.

Being able to scrape something is not the same as being allowed to, and the gap between those two is where people get their infrastructure banned or their company sued.

A short, non-lawyer summary of what I actually do:

Read robots.txt and honour it. Beyond ethics, it is self-interested: polite crawlers survive longer. Aggressive ones get IP ranges blocked, and then nobody on your team can scrape that domain.
Rate limit yourself before they rate limit you. Concurrency of 2 and a delay is almost always enough. Nobody needs 200 requests a second against a small site's origin server.
Check the Terms of Service, especially for anything behind a login. "Publicly accessible" and "you have permission" are different claims.
Personal data is a different legal universe. GDPR, CCPA and friends do not care that the data was on a public page. Scraping product prices and scraping names with email addresses are not the same activity.

Seriously. Open devtools, filter the network tab by Fetch/XHR, and look.

Roughly a third of the scrapers I have written could have been three lines against a JSON endpoint that was sitting there the whole time.

Scraping is what you do after that fails, not instead of checking.

Wrapping up

Six projects, one idea: the web is still readable, the tooling to read it is free and open, and most of the wall that showed up over the last two years is made of TLS fingerprints and inertia rather than actual locks.

Pick by job, not by star count. Start light. Check for an API. Be a polite guest on other people's servers.

And if you only take one thing from this: next time you get an inexplicable 403, before you reach for the browser, try impersonate="chrome". You will feel very silly and very happy.

What did I miss? I know some of you have a favourite obscure Go crawler you have been waiting for an excuse to talk about. Drop it in the comments, I read all of them.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs — without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Git Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc is your braking system. It hooks into git commit and runs an AI review on every diff before it lands. 60-second setup. Completely free.

In short, git-lrc helps Prevent Outages, Breaches, and Technical Debt Before They Happen

At a glance: 10 risk categories · 100+ failure patterns tracked · every commit…

View on GitHub

Tried building GitHub's search box in Go

Athreya aka Maneshwar — Thu, 23 Jul 2026 11:39:49 +0000

You know that little search box on GitHub issues? The one where you type is:open label:bug author:me created:>2024-01-01 and it just gets it? I always assumed there was some gnarly hand-rolled parser behind it, held together with regex and prayers.

So I decided to build my own version in Go, using a neat little library called participle (by Alec Thomas) that lets you define a parser as a plain Go struct.

Turns out the whole thing is surprisingly little code, and most of it reads like the grammar you would sketch on a napkin.

By the end of this post we will have a tiny tool that takes a search string, turns it into a typed syntax tree, and compiles that tree into safe, parameterized SQL.

Here is the money shot, so you know where we are headed:

$ make run q='is:open label:bug'
query: is:open label:bug
6 issue(s)

#   STATE  AUTHOR   CREATED     COMMENTS  LABELS         TITLE
1   open   octocat  2024-02-10  12        bug,urgent     Login button unresponsive on mobile
6   open   bob      2024-04-18  15        bug,p0,urgent  Memory leak in worker pool
8   open   octocat  2024-09-03  9         bug            Flaky test in CI
12  open   bob      2024-07-19  6         bug,p0         Rate limit not enforced
15  open   alice    2024-11-08  11        bug,urgent     Search returns stale results
18  open   bob      2024-10-22  10        bug,p0         Slow query on dashboard

Let's build it.

The filter string nobody wants to parse

Here is the version we all write first, be honest:

// the "I'll clean it up later" special
parts := strings.Fields(query)
for _, p := range parts {
    if strings.HasPrefix(p, "label:") {
        labels = append(labels, strings.TrimPrefix(p, "label:"))
    } else if strings.HasPrefix(p, "is:") {
        state = strings.TrimPrefix(p, "is:")
    }
    // ... 40 more else-ifs, each one a tiny betrayal
}

This works right up until someone types label:"help wanted" with a space in it. Or -author:bot to exclude a user. Or created:>2024-01-01 with a comparison.

Every one of those pushes you deeper into regex territory, and hand-rolled regex for this kind of thing has a way of solving one edge case and quietly creating two more.

Once you stop treating this as string munging and start treating it as an actual parsing problem, the solution gets a lot friendlier.

Participle: a grammar is just a struct

participle has a lovely core idea: you describe your grammar as a struct, annotate the fields with tags, and it builds the parser for you.

No separate .y grammar file, no code generation step.

The struct is the grammar.

Here is a taste. If you wanted to parse a single key:value pair, you would write:

type Pair struct {
    Key   string `parser:"@Ident"`
    Colon string `parser:"@Colon"`
    Value string `parser:"@Ident"`
}

The @ means "capture this into the field."

That's basically the whole trick.

Now let's scale it up to a real search language.

The AST: three little structs

Our search syntax is what I call "GitHub minimal": qualifiers like is:open, comparisons like comments:>=5, free text like login, negation with a leading -, and implicit AND between terms.

No OR, no parentheses (we will talk about those at the end).

The entire grammar fits in three structs:

// Query is the whole thing: a flat list of terms, all ANDed together.
type Query struct {
    Terms []*Term `parser:"@@*"`
}

// Term is one search unit: a key:value qualifier OR a free-text word,
// with an optional leading "-" to negate it.
type Term struct {
    Negated   bool       `parser:"@Dash?"`
    Qualifier *Qualifier `parser:"( @@"`
    Text      *Value     `parser:"| @(String | Ident | Number) )"`
}

// Qualifier is "key:value", e.g. is:open or created:>2024-01-01.
type Qualifier struct {
    Key string `parser:"@Ident Colon"`
    Op  string `parser:"@Op?"`
    Val *Value `parser:"@(String | Date | Number | Ident)"`
}

Read those tags out loud and they say what they mean.

@@* is "zero or more sub-structs." The ? after @Dash makes the negation optional.

The ( @@ | @... ) in Term is an alternation: a term is either a qualifier or a bare word.

What I like about this approach is that the AST doubles as documentation.

When a teammate asks what the search syntax supports, I point them at these three structs instead of a README that's probably out of date, because the structs are the parser and can't drift from what actually runs.

There is one subtle line doing a lot of work when we build the parser:

var parser = participle.MustBuild[Query](
    participle.Lexer(searchLexer),
    participle.Elide("whitespace"),
    participle.UseLookahead(2),
)

That UseLookahead(2) matters.

Both login (free text) and label:bug (a qualifier) start with an identifier.

The parser needs to peek ahead and check for a : before it decides which branch to take.

Lookahead of 2 lets it see the colon coming.

How the lexer handles the dash

The tokenizer has one detail worth slowing down for, because the dash character does three different jobs depending on where it shows up:

-author:bot -> the leading dash is negation
help-wanted -> the dash is part of a label name
2024-01-01 -> the dashes are date separators

If your lexer treats every - as a negation token, help-wanted becomes "help, NOT wanted," and your date turns into subtraction.

Neither of those is what you want.

The fix is worth understanding on its own, because it's a technique you'll reuse elsewhere.

participle's simple lexer is an ordered list of regex rules, and it takes the first one that matches. Order decides everything:

var searchLexer = lexer.MustSimple([]lexer.SimpleRule{
    {Name: "whitespace", Pattern: `\s+`},
    {Name: "String", Pattern: `"(\\.|[^"])*"`},
    {Name: "Date", Pattern: `\d{4}-\d{2}-\d{2}`},
    {Name: "Number", Pattern: `\d+`},
    {Name: "Op", Pattern: `>=|<=|>|<`},
    {Name: "Colon", Pattern: `:`},
    {Name: "Ident", Pattern: `[a-zA-Z_][a-zA-Z0-9_./-]*`},
    {Name: "Dash", Pattern: `-`},
})

Notice that Date, Number, and Ident all come before the bare Dash rule, and every one of them must start with a digit or a letter.

Walk through -author:bot one character at a time.

The lexer is sitting at the -. It tries Date, which needs a digit first, so no. It tries Number, same problem. It tries Ident, which needs a letter or underscore, and - is neither. Nothing longer can start here, so the plain Dash rule finally gets its turn, and that becomes our negation token.

Now walk through help-wanted.

The lexer starts at h, tries Ident, and the Ident pattern swallows the internal dash because I included - in its character class. One token, help-wanted, done.

The date 2024-01-01 gets grabbed whole by the Date rule before Number or Dash ever get a look.

So the dash only becomes a negation token when it literally cannot be anything else.

No special cases in the parser, no lookbehind, no state machine — just careful ordering of regex rules.

Here is the whole pipeline, from raw string to rows:

Compiling the tree into SQL

A parsed tree is nice, but nobody can query a Go struct directly.

We need SQL.

This is where the AST pays off, because walking a typed tree and emitting strings is fairly mechanical work, which is exactly what you want near a database.

The heart of the compiler is a registry that maps each qualifier key to a column and a comparison style:

var registry = map[string]fieldDef{
    "is":        {column: "state", kind: kindString},
    "state":     {column: "state", kind: kindString},
    "author":    {column: "author", kind: kindString, userAware: true},
    "assignee":  {column: "assignee", kind: kindString, userAware: true},
    "milestone": {column: "milestone", kind: kindString},
    "label":     {column: "", kind: kindLabel},
    "created":   {column: "created_at", kind: kindDate},
    "updated":   {column: "updated_at", kind: kindDate},
    "comments":  {column: "comment_count", kind: kindNumber},
}

Adding a new searchable field means adding one line here.

The grammar doesn't change, and neither does the lexer.

Each term compiles to a small SQL fragment plus its arguments:

switch def.kind {
case kindString:
    // is:open -> state = ?
    return def.column + " = ?", []any{value}, nil

case kindDate, kindNumber:
    // created:>2024-01-01 -> created_at > ?
    op := qf.Op
    if op == "" {
        op = "="
    }
    return def.column + " " + op + " ?", []any{value}, nil

case kindLabel:
    // labels live in a join table, so we ask "does a matching row exist?"
    sub := "EXISTS (SELECT 1 FROM issue_labels il " +
        "JOIN labels l ON l.id = il.label_id " +
        "WHERE il.issue_id = issues.id AND l.name = ?)"
    return sub, []any{value}, nil
}

Free text (a bare login) becomes a LIKE against the title and body.

Negation wraps the whole fragment in NOT (...). Implicit AND joins the fragments with AND. That's the entire compiler.

The part where I stop you from getting hacked

Look carefully at those returns.

The column names come from my registry, which is fixed code.

The user's value never gets glued into the SQL string. It goes into a separate []any of arguments, and the SQL only ever contains a ? placeholder.

Keeping user input and SQL structure in two separate places is what actually prevents injection here — it's not a cosmetic choice.

There is a --sql flag in the tool that prints exactly what gets sent to the database, so you can see the safety with your own eyes.

Watch what happens to a spicy query full of user input:

And a bigger one with negation, a date, a label join, and free text all at once:

Every value the user typed ends up in args.

The SQL itself is all structure and question marks.

If someone types author:'; DROP TABLE issues; -- it just becomes a string that matches zero authors, and your tables are unaffected.

By the way, author:me quietly became octocat in that first example.

The compiler resolves me to the current user, the same way GitHub does.

What the parsed tree actually looks like

If you are a visual thinker, here is the AST for is:open label:bug -author:bot drawn out. This is what those three structs produce in memory:

Three terms, hanging off one query, the third carrying a Negated: true flag.

The compiler walks this top to bottom and stitches the fragments together.

Making it real with SQLite

I wired this to a real database so it isn't just a toy that prints ASTs.

I used modernc.org/sqlite, a pure Go SQLite driver, which means no CGO, no C compiler, and go test just works on any machine.

The schema is three tables: issues, labels, and an issue_labels join table, which is exactly the thing that makes label: interesting to compile.

There is a seeded sample dataset with twenty issues so every example in this post is reproducible.

Run make demo and it fires a whole battery of queries at the database. A few highlights:

That second query, -author:bot is:closed, taught me a separate lesson. When I first ran it through the CLI, it errored out, because a query that starts with - looks like a command line flag to Go's flag package.

The fix is the standard POSIX -- separator (go run . -- "-author:bot is:closed") — the same "what does this dash mean" ambiguity from the lexer, showing up again one layer down at the command line.

Where this goes next

Right now there is no OR and no parentheses, on purpose, to keep the first version teachable.

Adding them is a satisfying next step: you introduce an OrExpr and AndExpr layer above the terms, and you get operator precedence essentially for free from how the structs nest.

Same AST idea, one more level deep.

Because the AST sits in the middle as a clean seam, SQL isn't the only possible backend.

You could compile the same tree into an in-memory func(Issue) bool for filtering a slice, or into an Elasticsearch query, or a Bleve query.

Parse once, target anything.

The whole thing is about 200 lines of Go: three structs for the grammar, one ordered lexer, one registry for the compiler.

That's the entire GitHub-style search box, minus the parts that would get me sued.

A big shoutout to Alec Thomas for participle.

The whole "your grammar is just a struct" idea is what made this fun instead of a chore, and his library quietly did all the heavy lifting while I got to take credit for it in a blog post.

All the code, the seeded database, and the tests are here: github.com/lovestaco/gh-search-dsl.

Clone it, run make demo, and try adding a new qualifier, it should only take one line.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs — without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Git Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc is your braking system. It hooks into git commit and runs an AI review on every diff before it lands. 60-second setup. Completely free.

In short, git-lrc helps Prevent Outages, Breaches, and Technical Debt Before They Happen

At a glance: 10 risk categories · 100+ failure patterns tracked · every commit…

View on GitHub

Your AI Re-Reads Your Whole Codebase Every Session. Hand It a Map Instead

Athreya aka Maneshwar — Mon, 20 Jul 2026 17:42:39 +0000

Let me paint you a picture you already know too well.

You open a fresh Claude Code (or Codex, or whatever coding agent you're loyal to this week) session.

You type one tiny question.

Something like "where do we handle retries?" And before your agent even thinks about answering, it quietly inhales half your repo.

Every file, every function, every stray utils.js that nobody has touched since the Obama administration. Thousands of tokens, gone, before you got a single useful word back.

That's the token tax.

You pay it every single session. And it's the reason your $20 plan sometimes feels like it's rationing you like it's 1943.

So when a tool showed up that promised to fix exactly this, I did the responsible thing: I got suspicious, then I tried it anyway.

The tool is called Graphify, and the short version is that it stops your AI from cramming for the same exam every morning.

Let me explain, because there's a genuinely clever idea underneath the hype.

The problem isn't your AI. It's the cramming.

Here's the thing about large language models reading raw files: they're doing it blind, every time.

There's no memory of the shape of your project between sessions.

So the model re-derives "how does this codebase fit together" from scratch, token by expensive token, on question number one.

The insight Graphify runs on isn't new, and the author is upfront about where it came from: an old note by Andrej Karpathy about building an LLM-friendly knowledge base. The pitch was simple. Instead of feeding a model your raw files over and over, index them once into something structured, then let the model query that.

// Detect dark theme var iframe = document.getElementById('tweet-2039805659525644595-189'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2039805659525644595&theme=dark" }

Graphify is a real, working version of that idea for your local folders.

You point it at a directory.

It compiles that directory into a knowledge graph. And from then on, your agent asks the graph instead of re-reading the world.

Okay, so what even is a knowledge graph here?

Fair question, because "knowledge graph" is one of those phrases people say to sound smart at meetups.

Strip the jargon and it's two things: nodes and edges.

Nodes are the pieces of your project (a function, a file, a component, a concept).

Edges are the relationships between them (this function calls that one, this doc describes that module, this config feeds that service).

Draw enough of those and clusters start to appear on their own.

See that red node with everything hanging off it? Graphify calls those god nodes, and they're not the little leaf nodes out at the edges.

They're the opposite: the most connected nodes in your whole project.

Your core abstractions. The stuff that, if it broke, would take the afternoon down with it.

Finding those automatically is weirdly delightful, because every codebase has three or four functions secretly holding the entire thing together, and now you get a list of them for free.

How it actually builds the thing

This is the part I found genuinely neat, so I'm going to nerd out for a second.

Graphify doesn't just throw your whole repo at a model and pray.

It splits the work in two:

For code, it parses the actual syntax tree.

No LLM, no tokens, no cost.

It just reads the code like a compiler would and pulls out functions, calls, and structure deterministically. That's the free lunch, and it's a big one.

For docs, papers, and images, where meaning matters more than syntax, it brings in a model to extract concepts and relationships.

That's the part that costs tokens, and it only runs on the stuff that actually needs interpreting.

Then it merges both, runs community detection to find the natural clusters, and hands you three files: an interactive graph.html, a plain-language GRAPH_REPORT.md, and the raw graph.json for anything programmatic.

One detail I appreciated: the report keeps an honest audit trail.

Every relationship is tagged as EXTRACTED (it's really in the code), INFERRED (the model reasoned it out, trust but verify), or AMBIGUOUS.

No pretending the guesses are gospel. I have trust issues with tools, and this one earned a little back.

The payoff: an actual map you can poke

Here's the interactive graph in motion:

You can toggle communities on and off, isolate the cluster you care about, and see how things connect instead of holding forty files in your head at once.

The first time you spot a dependency you didn't know existed, staring right at you as a line between two nodes, it's a small "oh, that's why that broke" moment. Cheaper than therapy.

The three commands that make it stick

The graph is nice to look at, but the reason it earns a spot in your workflow is querying.

Three commands do most of the heavy lifting:

query "how does auth work?" walks the graph and answers in plain language, citing the actual files.
path "AdminPanel" "Database" finds the shortest route between two concepts and shows you every hop.
explain "RateLimiter" gives you a human explanation of a single node using its neighborhood in the graph.

And when you change a bunch of files, you don't rebuild from zero. --update re-extracts only what changed.

Your map stays current without re-surveying the whole continent.

The bit your wallet cares about

Now the money question, literally.

Because your agent queries a compact graph instead of swallowing raw files, the token cost of "understand my project" drops hard.

The project claims around 70% fewer tokens, and on individual questions the reported reductions are measured in multiples, not modest percentages.

Your mileage will vary with repo size and question type, so take the exact number with a grain of salt, but the direction is not subtle.

Translation: the plan you're already paying for suddenly stretches a lot further. Same subscription, more actual work per dollar. That's the whole trick.

Who this is actually for

Straight answer: this shines when you read more than you write.

Onboarding onto a codebase somebody else built.

Doing research across a pile of code and docs.

Exploring a repo you cloned an hour ago and already regret.

In those situations, a pre-built map is exactly what you want.

If you're heads-down writing brand new code in a small project you already know cold, the graph buys you less. And you do pay an upfront cost to build it (the semantic pass on docs and images isn't free), though a code-only run leans on that deterministic parser and stays cheap.

It's a "spend a little now to save a lot later" deal, so spend it where later actually shows up.

Setup, if you're curious, is about as heavy as installing any Python tool: you need Python and uv (think of uv as npm, but for Python and in a good mood), then one install command, then you point it at a folder. That's the whole ceremony.

The takeaway

We spend a lot of energy making models smarter.

Graphify makes a quieter bet: give the model a decent memory of your project, and it stops wasting brainpower re-learning the map every morning.

It won't write your code for you.

But it will stop your AI from treating every session like the first day of school. Give your codebase a map. Your token budget might send a thank-you card.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs — without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Git Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc is your braking system. It hooks into git commit and runs an AI review on every diff before it lands. 60-second setup. Completely free.

In short, git-lrc helps Prevent Outages, Breaches, and Technical Debt Before They Happen

At a glance: 10 risk categories · 100+ failure patterns tracked · every commit…

View on GitHub

Your PDFs Are Eating Your LLM's Tokens for Breakfast

Athreya aka Maneshwar — Sat, 18 Jul 2026 17:48:36 +0000

Real talk for a second.

You drag a chunky PDF into your favorite AI chat, ask one innocent little question, and somewhere in the background your token budget just quietly combusted.

I want to walk you through why that happens, and the free Microsoft tool that has been sitting on GitHub the whole time waiting for you to notice it.

Grab a coffee. This one is going to save you money.

The problem nobody told you about

Here is the thing about PDFs. They are Pretty Darn Fat.

When you upload one to a model, it does not just read the words like you and I do.

It has to wade through the fonts, the layout coordinates, the half-broken tables, the embedded images, and every other bit of packaging that PDFs love to hoard.

All of that formatting noise gets turned into tokens, and tokens are the currency you are paying with.

Rough numbers: a single PDF page can run somewhere between 1,500 and 3,000 tokens depending on how messy it is. Do the math on a 20-page document and you can be looking at up to 70,000 tokens poof! That is before your first question. You paid the cover charge and you have not even ordered a drink yet.

Here is that same idea as a picture, because I like pictures.

The left path is where most of us live.

The right path is where I want to take you.

Enter MarkItDown

The fix is a free, open-source tool from Microsoft called MarkItDown.

It has blown past 110,000 stars on GitHub (sitting around 119k as I write this), so this is not some abandoned weekend hack.

It is a "boring tool that just works," which in developer language is the highest possible compliment.

What it does is beautifully simple. You give it a file, and it hands you back clean Markdown. That is it. That is the whole trick.

And by "a file" I mean almost anything you can throw at it: PDFs, Word docs, Excel sheets, PowerPoint decks, images, audio, HTML, and yes, even YouTube links, which it happily turns into a transcript.

It is a bit of a "convert anything to Markdown" Swiss Army knife.

Why does Markdown help so much? Two reasons, and both matter.

First, Markdown is featherweight. It keeps the structure that carries meaning (headings, lists, tables, links) and throws out the formatting fluff that does not. Less noise, fewer tokens, up to around 70 percent lighter in the good cases. Your mileage will vary, but the direction is always down.

Second, and this is the part people sleep on, models actually read Markdown better.

Mainstream LLMs were trained on mountains of Markdown and speak it natively.

They will even reach for it in their own answers when you did not ask them to.

So you are not just spending fewer tokens, you are handing the model its favorite format on a silver platter.

It is a genuine handshake moment.

Mark my words, once you see the format click, you will not want to go back.

The genuinely cool part: the MCP server

Here is where it stops being a manual chore.

MarkItDown ships an MCP server (the little markitdown-mcp package).

Wire it into any MCP-capable client (desktop assistants, editors like Cursor and VS Code, and friends), and instead of you converting files by hand, you just point the model at a file path or a URL and it reaches for the converter itself.

Under the hood it exposes a single tool, convert_to_markdown(uri), and the model knows when to call it.

So your flow goes from "export, convert, re-upload, sigh" to "hey, read this report and summarize it."

The conversion happens in the middle, quietly, without you babysitting it.

Setup is about a two-minute job. You install the package with pip, drop a small block into your client's MCP config, and then fully quit and reopen the app.

That last step trips people up constantly, so let me say it loudly: the MCP server only loads on a clean launch.

Closing the window is not quitting. Cmd or Ctrl plus Q, then reopen. Otherwise you will sit there wondering why nothing happened.

One honest note. This auto-magic only kicks in on clients that support MCP.

If you are in a plain browser chat, you can still get all the savings, you just run the file through MarkItDown yourself first and paste the Markdown in. Slightly more manual, same payoff.

The tl;dr

You have been paying a formatting tax on every file you feed your model, and Microsoft handed out the coupon months ago.

Convert to Markdown first, spend a fraction of the tokens, and get answers in the format the model likes best.

Set up the MCP server once and it mostly disappears into the background.

Two minutes of setup for up to 70 percent fewer tokens is the kind of trade I take every single time.

If you want to poke at it yourself, here is where to start:

The main repo: markitdown
The MCP server for the auto-convert trick: markitdown/tree/main/packages/markitdown-mcp

Go convert something. Your token budget has suffered enough.

If you tried this and it saved you a pile of tokens tell me in the comments. I read them.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs — without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Git Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc is your braking system. It hooks into git commit and runs an AI review on every diff before it lands. 60-second setup. Completely free.

In short, git-lrc helps Prevent Outages, Breaches, and Technical Debt Before They Happen

At a glance: 10 risk categories · 100+ failure patterns tracked · every commit…

View on GitHub

Nobody Painted That Rectangle Black

Athreya aka Maneshwar — Thu, 16 Jul 2026 16:54:20 +0000

You have done this.

Netflix is playing, something on screen is worth sharing, you hit screenshot, and you get a black rectangle where the video was.

The play button is there. The scrubber is there.

The actual show? Gone.

Same deal with screen recording, except weirder.

You are staring directly at the video while it plays, perfectly visible, in full color, and the saved recording comes out black.

Your eyes say one thing. The file says another.

Most of us file this under "Netflix blocked it" and move on with our lives.
But the mechanism underneath is stranger and honestly more elegant than "blocked."

So let's go layer by layer.

The mental model I had is wrong

Here is what I assumed:

I press screenshot
Something detects it
That something paints black over the protected area
I get a censored image

Reasonable. Also completely wrong.

Nothing detects anything. Nothing paints anything.

Sit with that, because the rest of this post falls out of it.

Two consumers, two composites

Here is the load-bearing idea, and it took me embarrassingly long to arrive at it: the screen and the screen recorder are not looking at the same image.

I had assumed there was one framebuffer, one canonical "what the phone currently looks like," and that a screenshot was simply a copy of it.

Nope. SurfaceFlinger, Android's compositor, does not render one image that everybody shares.

It renders a separate composite per output destination.

The physical panel is one destination.

The screenshot service is another. A cast session is a third.

For each destination, SurfaceFlinger walks the layer list and asks exactly one question per layer: does this layer belong in this output? For the panel, the answer is always yes.

For the screenshot output, any layer carrying FLAG_SECURE gets skipped.

So the video layer is never removed from the screenshot if its is never added.

Why it is black, specifically

This is my favorite part.

The capture buffer gets allocated and zeroed.

Normal layers write into it. The secure layer does not. Then the buffer gets encoded and handed over.

Zeros are black.

That is the whole thing. Nobody chose black.

There is no paintItBlack() sitting in AOSP.

Black is simply what untouched memory looks like when you interpret it as pixels. The rectangle is not censored, it is vacant.

It is the absence of a decision.

This also explains something I had seen a hundred times and never once registered: the black is exactly the video's shape, and the UI around it survives just fine.

Play button, scrubber, title text, all present.

Those are separate layers. Only one of them had the flag.

My bank is doing this too

So I went and screenshotted my banking app.

Same black frame. Password manager, same.

Whatsapp one view image screenshot? same.

Here is the entire implementation:

getWindow().setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
);

One call. Thirty seconds of work. That is the feature, shipped.

Netflix is playing an entirely different game

Everything so far is a policy.

SurfaceFlinger chooses to honor FLAG_SECURE.

The pixels sit in perfectly ordinary memory the whole time.

The compositor is just politely declining to copy them.

Which means: root the phone, patch SurfaceFlinger, flag ignored, banking screenshots work again. The whole protection is a gentleman's agreement enforced by code that the root user owns.

Netflix HD is not that.

With Widevine L1, decoded frames live inside the TEE, a separate secure world running on the same SoC.

The decrypted video never lands in memory the application processor can address.

It goes from the TEE into a protected buffer, gets composited, reaches your eyeballs, and the kernel never touches a single pixel of it.

There is no code to patch, because it is not code.

It is the memory controller saying no, in silicon xD

	Mechanism	Enforced by	Defeated by
Banking app	`FLAG_SECURE`	The OS, voluntarily	Root
Netflix HD	`FLAG_SECURE` + L1 secure buffers	The chip itself	Nothing on the device

So does rooting actually work?

Here is where I stop explaining and start asking.

For FLAG_SECURE, I think yes. It is policy, and root owns the policy. Patch SurfaceFlinger, stop honoring the flag, banking screenshots come back.

Netflix HD is where I run out of road. The frames are in the TEE. Root gets you the kernel, and the kernel is not the thing saying no. So what actually comes out the other end?

I have not tried it. No spare handset to brick.

So has anyone actually done this? Flashaholics, custom ROM people what did you get?

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs — without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Git Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc is your braking system. It hooks into git commit and runs an AI review on every diff before it lands. 60-second setup. Completely free.

In short, git-lrc helps Prevent Outages, Breaches, and Technical Debt Before They Happen

At a glance: 10 risk categories · 100+ failure patterns tracked · every commit…

View on GitHub

/proc, pkexec, and 678 commits

Athreya aka Maneshwar — Wed, 15 Jul 2026 18:12:51 +0000

Day 1 of Qt on Linux. I installed Stacer, opened the source, and found a few things worth stealing.

Every Qt tutorial builds a calculator or a todo list.

Those teach you the API.

They don't teach you how an app is shaped, where the OS code goes, where the root code goes, what holds twelve screens together.

So I went looking for a real app to read.

I found Stacer, a Linux system optimizer, installed it, poked every button, then opened the source.

It's abandoned, which is why it's good

Last commit August 2023, README says no further releases. 678 commits and then silence.

Which is perfect for reading.

Nothing moves under you, there's no "actually we refactored that last week," and at ~50 headers, 48 sources and 26 .ui forms you can read all of it in an evening or two.

A finished project sits still long enough to dissect.

The decision everything else hangs off

I read the build files first.

The top level CMakeLists.txt gives away the architecture:

add_subdirectory(stacer-core)
add_subdirectory(stacer)

Then from stacer-core/CMakeLists.txt:

find_package(Qt5 COMPONENTS Core Network REQUIRED)
add_library(${PROJECT_NAME} STATIC ${${PROJECT_NAME}_srcs})
target_link_libraries(${PROJECT_NAME} Qt5::Core Qt5::Network)

stacer-core is a static lib with no GUI components linked at all.

No Widgets, no Charts, nothing that can draw a pixel.

It's the whole "talk to the OS" layer, and it would happily compile into a headless CLI.

The app links it plus Widgets, Charts, Svg and Concurrent on top.

Most codebases claim a separation like this and then someone sneaks a QMessageBox into the data layer. Stacer can't. The linker would slap it.

The core splits three ways by verb:

Info/ reads system state
Tools/ changes system state
Utils/ is the primitives both are built on

Read, write, plumbing. I never had to grep for where anything lived, which in an unfamiliar codebase is a small miracle.

Every arrow points down.

/proc and roll

How does a system monitor monitor the system? I assumed a library, or a daemon, something official looking.

It reads text files.

#define PROC_CPUINFO "/proc/cpuinfo"
#define PROC_LOADAVG "/proc/loadavg"
#define PROC_STAT    "/proc/stat"

Core count: read /proc/cpuinfo, filter ^processor, count the lines.

Load average: read /proc/loadavg, split on whitespace, take the first three.

Clock speed: filter ^cpu MHz, split on the colon.

The CPU section of a system monitor is a regex over a text file. And procfs is how everything on Linux exposes itself, so once you notice you can't stop.

The bit that broke my brain

So CPU usage should be the same, right? Find the line, take the number.

There is no number.

/proc/stat gives you cumulative tick counters since boot — ticks spent in user mode, system, idle, iowait, ever.

They only go up.

CPU usage isn't a value you can read.

It only exists as a relationship between two samples: read the counters, wait, read again, and the shape of the change is the answer.

From cpu_info.cpp:

int CpuInfo::getCpuPercent(const QList<double> &cpuTimes, const int &processor) const
{
    const int N = getCpuCoreCount()+1;

    static QVector<double> l_idles(N);
    static QVector<double> l_totals(N);

    int utilisation = 0;

    if (cpuTimes.count() > 0) {
        double idle = cpuTimes.at(3) + cpuTimes.at(4); // idle + iowait
        double total = 0.0;
        for (const double &t : cpuTimes) total += t;

        double idle_delta  = idle  - l_idles[processor];
        double total_delta = total - l_totals[processor];

        if (total_delta)
            utilisation = 100 * ((total_delta - idle_delta) / total_delta);

        l_idles[processor] = idle;
        l_totals[processor] = total;
    }
    // ...clamped to 0..100
    return utilisation;
}

Those static locals. The function remembers: it stashes the previous idle and total per processor, diffs against them, overwrites them for next time.

Which makes an innocent looking getter stateful.

Call it twice in a row from two places and the second caller gets garbage, because the first one already consumed the delta.

The first call after launch is meaningless by definition.

Not a dunk — it's the correct algorithm, it's what top does, and the comment above it pastes in the /proc/stat column meanings for the next reader.

But it's a landmine, and it explains something further up the stack.

The refresh loop is refreshingly dumb. From dashboard_page.cpp:

connect(mTimer, &QTimer::timeout, this, &DashboardPage::updateCpuBar);
connect(mTimer, &QTimer::timeout, this, &DashboardPage::updateMemoryBar);
connect(mTimer, &QTimer::timeout, this, &DashboardPage::updateNetworkBar);

QTimer *timerDisk = new QTimer(this);
connect(timerDisk, &QTimer::timeout, this, &DashboardPage::updateDiskBar);
timerDisk->start(5 * 1000);

mTimer->start(1 * 1000);

One timer at 1s fanned out to three slots, another at 5s for disk because disk changes slowly and checking it is expensive.

Nothing pushes; the UI pulls on a clock. That's the whole update architecture.

The smartest thing in here

Stacer kills processes, purges caches, toggles systemd services, uninstalls packages, edits /etc/hosts.

All of it needs root. Stacer does not run as root.

From command_util.cpp:

QString CommandUtil::sudoExec(const QString &cmd, QStringList args, QByteArray data)
{
    args.push_front(cmd);

    QString result("");

    try {
        result = CommandUtil::exec("pkexec", args, data);
    } catch (QString &ex) {
        qCritical() << ex;
    }

    return result;
}

That's the function. Shove the command onto the front of the args, run pkexec instead.

polkit pops the auth dialog, tells the user which command wants elevation, and runs that one command as root.

So the app process is unprivileged for its entire life — a bug in the theming code can't rm -rf your home directory.

Privilege is granted per operation, at the moment of use, not once at launch for everything forever. And pkexec kill 1337 is a more honest dialog than "Stacer would like admin access, kthx."

Sixteen sudoExec call sites, sixteen places the user gets asked.

The alternative you see everywhere is a .desktop file that launches the whole GUI under sudo, so now your event loop and your stylesheet parser are root, forever, for the sake of one rm.

Tools/package_tool.cpp sits on top of this: same intent, dispatched to apt-get, dnf, yum, pacman or snap depending on the machine.

The UI just says "uninstall", and the packaging ecosystem stays on the other side of the wall.

Twelve screens

Each page is a directory under Pages/ with the Qt triple: .h, .cpp, .ui.

App news them all up at startup into a SlidingStackedWidget, a QStackedWidget subclass that animates transitions instead of hard cutting. Small thing, and most of why the app feels nicer than its feature list.

Best part: two pages don't always exist.

// APT SOURCE MANAGER
if (ToolManager::ins()->checkSourceRepository()) {
    aptSourceManagerPage = new APTSourceManagerPage(mSlidingStacked);
    mListPages.insert(7, aptSourceManagerPage);
    mListSidebarButtons.insert(7, ui->btnAptSourceManager);
} else {
    ui->btnAptSourceManager->hide();
}

An APT source manager on Arch is nonsense, so it checks for APT config and doesn't build the page.

Same for Gnome settings, which checks DESKTOP_SESSION and the distro string.

One binary reshaping itself around the machine it woke up on, hiding the button rather than showing you something broken.

Theming, or: CSS variables, hand rolled

QSS looks like CSS and lacks most of what makes CSS bearable. Notably, no variables.

So Stacer built them. Each theme is a style.qss plus a values.ini, both baked into the Qt resource system, and AppManager::updateStylesheet does this:

QString appThemePath = QString(":/static/themes/%1/style").arg(mSettingManager->getThemeName());
mStyleValues = new QSettings(QString("%1/values.ini").arg(appThemePath), QSettings::IniFormat);

mStylesheetFileContent = FileUtil::readStringFromFile(QString("%1/style.qss").arg(appThemePath));

// set values example: @color01 => #fff
for (const QString &key : mStyleValues->allKeys()) {
    mStylesheetFileContent.replace(key, mStyleValues->value(key).toString());
}

qApp->setStyleSheet(mStylesheetFileContent);

emit SignalMapper::ins()->sigChangedAppTheme();

Read the stylesheet, string replace every @color01 with #fff from the ini, apply globally.

A preprocessor in nine lines. Swapping themes is pointing at a different folder.

Two details worth stealing. Widgets opt into styling with setAccessibleName("danger") and the QSS selects on it — an accessibility field as a CSS class, which is either beautiful or slightly rude depending on your mood, but it's a known Qt move and it works.

And that emit SignalMapper::ins()->sigChangedAppTheme() at the end. SignalMapper is a global QObject that exists purely as a signal bus.

No logic, three signals:

signals:
    void sigChangedAppTheme();
    void sigUninstallStarted();
    void sigUninstallFinished();

Widgets that paint themselves (the circle bars, the charts) can't get colors from a stylesheet, so they need to know when the theme changed and re-read.

Without the bus, AppManager needs a pointer to every widget that cares.

With it, it shouts into the void and whoever cares listens. Good signal to noise ratio, and I'll see myself out.

What I'm stealing

Split the OS layer into a target that can't link Widgets — the linker enforces the boundary better than my discipline does.

Split that layer by verb.

Never run the whole app as root; pkexec per command is four lines and it's the difference between a bug and a catastrophe.

Poll with QTimer, two rates for two costs, ship it.

QSS plus a token file gives you variables. A signal bus beats N pointers when a global thing changes and unknown widgets care. And know when a singleton is load bearing versus lazy, in here it's holding the delta math together, and it's also why nothing is testable.

If you want to trace one thing end to end, do the CPU percentage.

Timer fires in dashboard_page.cpp, through InfoManager::getCpuPercents, into CpuInfo::getCpuPercents, which reads /proc/stat as text, diffs it against static state from a second ago, and hands a number to a hand painted CircleBar.

Every layer of the app in one number, once a second, on a project nobody maintains anymore.

Next I want to build something with SlidingStackedWidget, and work out whether the .ui files are worth it or whether I should just write layouts by hand.

If you've got opinions, I'd love to hear them, because right now I have two and they're both wrong xD

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs — without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Git Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc is your braking system. It hooks into git commit and runs an AI review on every diff before it lands. 60-second setup. Completely free.

In short, git-lrc helps Prevent Outages, Breaches, and Technical Debt Before They Happen

At a glance: 10 risk categories · 100+ failure patterns tracked · every commit…

View on GitHub

A Dash of dev.to: My Blog Stats Now Live in the Terminal

Athreya aka Maneshwar — Tue, 14 Jul 2026 19:38:18 +0000

I check my dev.to stats more often than I would ever admit in a job interview.

Reactions, views, comments, the little numbers that go up, and the ones that stubbornly refuse to.

Normally that ritual means opening a browser, clicking into the dashboard, and squinting at one article at a time like I'm reading tea leaves.

I wanted something calmer.

One terminal window.

My top articles ranked by likes, by views, and by comments, all on screen at once, quietly refreshing itself while I pretend to do real work.

So I built it in an afternoon.

It took a tiny Go program, one wonderful archived project doing the heavy lifting, and two bugs I absolutely did not order but got served anyway.

Let me walk you through it, bugs and all.

The plan (which looked suspiciously simple)

The plan had three moving parts.

One, dev.to already hands you your own data.

There is an endpoint, GET /api/articles/me, you send your API key in an api-key header, and you get back every article you have published with the fields that matter already counted for you: positive_reactions_count, page_views_count, and comments_count.

No scraping, no HTML parsing, no crying.

You can generate a key at your dev.to settings under Extensions.

Two, I did not want to build a whole TUI from scratch.

Grids, colors, borders, keyboard handling, refresh loops. Life is short xD

Three, therefore, I needed something that already draws pretty terminal dashboards and would happily show my numbers if I fed it nicely.

That third thing exists, and it is called devdash.

Enter devdash (and a well earned shoutout)

{ % embed https://github.com/Phantas0s/devdash %}

devdash is a highly configurable terminal dashboard by Matthieu Cneude, better known as Phantas0s.

It has widgets for GitHub, Google Analytics, Google Search Console, Travis, and more, and the entire layout is driven by a single YAML file.

Rows, columns, t-shirt sizes, colors, all declarative.

It is a genuinely lovely piece of Go.

Two small catches. It has been archived since 2023. And it has precisely zero concept of what dev.to is.

Now, I could have forked it, added a proper Forem service, wired up structs, written tests, and opened a pull request into a repo that is politely closed for business.

Instead I found the lazy door, and it was already unlocked.

devdash has a widget called lh.table, the localhost table.

You hand it a shell command, it runs that command, and it renders whatever the command prints as a bordered table.

It splits each line of output on whitespace and slots the pieces into columns. That is the whole contract.

So devdash does not need to know about dev.to.

It just needs a command that prints rows. I can be that command.

If Matthieu ever reads this: thank you for building a tool flexible enough to be abused this gracefully.

Go bother Matthieu on X and tell him his archived project is still out here pulling shifts.

Here is the shape of the whole thing.

The little Go binary in the middle is the only thing I actually had to write.

I called it devto-stats.

It fetches all my articles (paginating 100 at a time until dev.to runs out), keeps only the published ones, sorts them by whichever metric devdash asks for, and prints clean rows.

req.Header.Set("api-key", apiKey)
resp, _ := client.Do(req)
// GET https://dev.to/api/articles/me?per_page=100&page=N

And the config just points three table widgets at three flavors of that command.

- name: lh.table
  options:
    title: " MOST VIEWED "
    command: "./bin/devto-stats -mode=table -sort=views -limit=10"
    headers: "#,Article,Views"
    border_color: green

Three of those blocks, colored red, green, and yellow, sitting side by side. In theory, done.

In theory.

my dashboard tried to DDoS my own account xD

I turned it on. Overview strip populated. Most Liked, glorious. Most Commented, present.

a comma walked into my table and everything fell over

Most Viewed finally rendered. And it rendered wrong.

The first row looked fine, then every row below slid one column right.

Titles in the numbers column, numbers nowhere.

I recognized the article where it started.

My top post is titled "Good Bye CRUD APIs, Hello Sync".

Look at the punctuation.

Here's what devdash does under the hood: it splits each line on whitespace to get cells, joins those cells back together with commas, then splits the whole batch on commas again to chunk it into rows of N columns.

A comma inside a title is indistinguishable from a comma devdash added on purpose.

One title becomes two cells, the row has four pieces instead of three, and because the chunking is global, every row after it is shifted forever.

The real fix belongs upstream, in a repo that isn't taking visitors.

So I fixed it on my side, where I control the output.

My binary already slugifies titles to survive the whitespace split.

I just taught it to evict commas too.

s := strings.Join(strings.Fields(title), "-")
s = strings.ReplaceAll(s, ",", "") // devdash re-splits the table on commas

One line. The comma-tose table woke right up.

The payoff

Here is the raw feed one panel runs on, straight out of the binary, real numbers from my actual account:

devdash takes three of those feeds and frames them into colored, bordered, self refreshing tables sitting shoulder to shoulder: Most Liked in red, Most Viewed in green, Most Commented in yellow, with a summary strip across the top.

Ctrl+R forces a refresh, Ctrl+C quits, and left to its own devices it repaints itself every five minutes.

444 articles, all of them accounted for, no browser, no clicking, just a quiet terminal telling me the truth about which posts people actually read.

What I actually learned

The best integration is often no integration. devdash never learned about dev.to.

I made dev.to speak devdash's language instead, and a tool that stopped being maintained in 2023 rendered 2026 data without a single change to its source.

The whole thing, Go helper, YAML, and Makefile, is here: lovestaco/devto_devdash.

Bring your own API key.

And real gratitude to Matthieu Cneude for devdash.

Sometimes the best tool for the job is one somebody stopped working on years ago, sitting there quietly, still perfectly happy to dash off one more dashboard.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs — without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Git Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc is your braking system. It hooks into git commit and runs an AI review on every diff before it lands. 60-second setup. Completely free.

In short, git-lrc helps Prevent Outages, Breaches, and Technical Debt Before They Happen

At a glance: 10 risk categories · 100+ failure patterns tracked · every commit…

View on GitHub

Fusuma: Write Markdown, Get Slides, PDFs, and a Self-Made Social Card

Athreya aka Maneshwar — Mon, 13 Jul 2026 12:22:29 +0000

A fusuma (襖), if you didn't grow up around one, is the sliding door in a traditional Japanese house.

No hinges, no swinging into someone's face, you just slide it and the room becomes a different room.

So when hiroppy named his Markdown-to-slides tool fusuma, the pun was already built into the product: you write one flat file, and sliding between sections turns it into a presentation.

I see what you did there, and I respect it.

I hadn't used fusuma before this week.

I installed it, scaffolded a real project, wrote actual slides explaining fusuma using fusuma, ran the build pipeline, and then went spelunking through node_modules because the CLI output during build said something that made me stop and go "wait, it's doing what."

We'll get to that. First, the basics.

The pitch: one file, no editor

You install it, run one command, and you have a deck:

npm install fusuma -D
npx fusuma init

That scaffolds a slides/ folder, a style.css, and a .fusumarc.yml config.

Your actual content lives in plain Markdown, and every --- on its own line starts a new slide.

That's the entire authoring model.

No slide objects, no proprietary file format, no clicking "insert text box" forty times.

<!-- classes: title -->

# Hello😃

---

<!-- section-title: Bye👋 -->

## Bye👋

That HTML-comment syntax above # Hello😃 isn't decoration, it's a directive fusuma's parser reads to apply a .title CSS class to that slide, and section-title sets what shows up in the sidebar navigation.

It's a clever trick: keep the file valid, renderable Markdown for anyone viewing it on GitHub, while smuggling presentation metadata through comments a plain Markdown renderer just ignores.

Here's that exact idea rendered for real, from a four-slide deck I built (using fusuma) to explain fusuma, running the pop theme:

Once you're happy with the content, npx fusuma start gets you a dev server on :8080 that hot reloads on every save, no full page refresh, no build step in the way of your edit loop:

$ npx fusuma start
  fusuma  Compiled successfully
  fusuma  Server running at http://localhost:8080/

Then, when you're actually done, the same file turns into whatever you need next:

npx fusuma build   # optimized static HTML/JS bundle
npx fusuma pdf     # the deck as a single PDF
npx fusuma deploy  # pushes build/ straight to GitHub Pages

One Markdown source, sliding into whichever output you need. There's the pun again. I promise I'll ease up.

I built the meta version: fusuma slides about fusuma

Every screenshot above came out of that same real project, not a mockup: a four-slide deck (slides/0-slide.md) that explains fusuma using fusuma, with the built-in pop theme enabled through one CSS import, @import '@fusuma/client/assets/style/themes/pop.css';.

That's the entire theming API.

The code blocks you see highlighted are running through Prism via @fusuma/prism-loader, and the whole thing is bundled with webpack 5 underneath.

The part where I stopped and said "wait, what"

Here's what actually made me open the source. I ran npx fusuma build in a folder that had no git remote configured, and got this:

- Fetching the remote origin url...
 build  The remote origin url of this repo isn't found.
 build  If you want to generate og:image, please set fusumarc.meta.url

Fine, minor warning, no big deal. But "generate og:image" made me curious about how it generates that image, because most tools either template it with a canvas library or just skip it.

So I went digging in packages/fusuma/src/server/dynamicRenderingServer.js, and it turns out fusuma doesn't template the social preview card.

It launches an actual headless Chrome via Puppeteer, points it at your freshly built deck on a throwaway local server, and takes a real screenshot of your real first slide to use as the og:image.

Then, using that same open browser tab, it runs pa11y (not Lighthouse, despite what you'd guess) against the live page for an accessibility audit, filtering out a couple of known-noisy rules and anything inside a <code> block.

So the "build" step isn't only a bundler running.

It's a bundler, and then a whole disposable browser opening your own presentation and taking its own picture before anyone else sees it.

That one got me.

While I was in the @fusuma/mdx-loader source, I found three directive-driven features that never came up in the docs I'd already read.

Fusuma parses your Markdown as MDX, which means fenced blocks and HTML comments can get swapped for actual JSX components at build time:

A fenced block tagged chart ` or `mermaid gets swapped for a <div class="mermaid"> that renders as a live Mermaid diagram in the deck itself.
Wrap a JS code block with an  comment and fusuma adds an "execute" button next to it that runs your snippet live, in the browser, in front of your audience. Actual runtime demos, no separate tab.
 drops in an inline SVG QR code generated at build time, presumably so people can scan your slide instead of squinting at a URL.

None of that is advertised anywhere near the top of the README.

You'd only find it by writing the comment syntax from memory of some other tool and hoping, or by reading mdxPlugin.js like I did.

Would I actually use it

For a quick, versionable, git-diffable slide deck, yes, honestly.

The zero-config setup is real, the hot reload loop for start is fast, and the fact that your accessibility audit and your og:image both fall out of the same Puppeteer pass is a genuinely clever bit of engineering, not just marketing copy.

I'd stop short of building a 200-slide conference keynote in it since there's no visual editor for anyone who isn't comfortable in Markdown, but for internal tech talks, this-is-how-our-service-works decks, or documenting a tool by making slides about the tool (see above), it's a solid, honest little door to slide open.

If you want to try it yourself, the source is at hiroppy/fusuma, and if you're curious about the self-screenshotting build step, the exact file is right here: dynamicRenderingServer.js. Slide responsibly.

Thanks to about_hiroppy for such a smooth software.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs — without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Git Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc is your braking system. It hooks into git commit and runs an AI review on every diff before it lands. 60-second setup. Completely free.

In short, git-lrc helps Prevent Outages, Breaches, and Technical Debt Before They Happen

At a glance: 10 risk categories · 100+ failure patterns tracked · every commit…

View on GitHub

I Poked a 10-Year-Old Chat Protocol With a Stick

Athreya aka Maneshwar — Sun, 12 Jul 2026 17:49:36 +0000

So here's how I spent my weekend.

I went digging through old GitHub repos looking for something forgotten, found a project called lhttp, and instead of just reading the README like a reasonable person, I cloned it, compiled it, ran it, and poked it with a stick until it did something weird.

It did something weird. We'll get there.

What even is lhttp

lhttp describes itself as "a http like protocol using websocket to provide long live, build your IM service quickly scalable without XMPP."

Translation: it's a tiny text protocol, styled like HTTP, that rides on top of a websocket connection instead of a raw TCP socket.

The pitch is that you get HTTP's readability (commands, headers, a body) but with a connection that stays open, so you can push messages to clients instead of waiting for them to ask nicely.

Under the hood, when you want to run more than one lhttp server (because one server is never enough once your chat app takes off, right?), all the servers talk to each other through NATS, specifically an ancient bundled copy of gnatsd.

Every server subscribes to the same message bus, so it doesn't matter which server a client is connected to.

Publish a message on server 1, and a client sitting on server 3 still gets it.

Here's the cluster idea, minus the ASCII art from the README:

Nice idea, honestly. Small gnat-sized message broker, quietly doing the heavy lifting so the actual servers can stay dumb and stateless.

Naming a broker after an insect that's small but annoyingly persistent feels like accidental self-awareness.

The wire protocol itself is charmingly blunt:

LHTTP/1.0 chat
content-type:json
publish:channel_jack

{"to":"jack","message":"hello jack"}

Command line, headers, blank line, body.

If you've ever hand-rolled an HTTP request in telnet for fun, this will feel instantly familiar.

Getting a decade-old Go project to build again

Here's where I expected pain.

This repo uses Godeps, a vendor/ folder frozen in time, and a Godeps.json that proudly declares "GoVersion": "go1.6".

For context, Go modules didn't exist yet in 2016.

People vendored dependencies by literally copying the source into your repo and hoping nobody touched it again.

I have Go 1.24 installed. I fully expected to spend my evening untangling import paths.

export GOPATH=/some/path/gopath
mkdir -p "$GOPATH/src/github.com/fanux"
ln -s /path/to/lhttp "$GOPATH/src/github.com/fanux/lhttp"
cd "$GOPATH/src/github.com/fanux/lhttp"
GO111MODULE=off go build .

Exit code zero. First try. No fights, no missing symbols, no "this API doesn't exist anymore."

Old-school GOPATH mode plus a vendor folder from the Obama administration, and Go 1.24 just shrugged and compiled it.

Same story for the actual demo server (websocketServer/test.go, which despite the filename is a real main package) and the tiny static file server in lhttp-web-demo that just serves the chat UI. Both compiled clean with zero source changes.

One small archaeology note for anyone following along: the main README's Docker instructions tell you to expose port 8081 for the lhttp server.

The actual source code hardcodes :8581.

One digit off, in the docs, for what appears to be the project's whole life. Nobody tell them. Actually, somebody should tell them.

Turning it on

Three processes, three jobs:

./gnatsd -p 4222 &          # the message bus
./lhttp_server &             # the actual chat server, listening on :8581
./demo_server &               # serves index.html on :9090

With everything up, I didn't even bother with a browser first.

I went straight for a raw websocket connection in Python, because I wanted to see the bytes.

ws.send("LHTTP/1.0 chat\r\n\r\nHello from the blog experiment!")
ws.recv()
# 'LHTTP/1.0 auth\r\ncontent-type:image/png\r\n\r\nHello from the blog experiment!'

I sent plain text under the chat command.

I got back a response labeled command auth, with a header claiming the content type is image/png. My text message. Labeled as a PNG.

The demo's ChatProcessor apparently relabels every reply this way regardless of what you send it, which I can only assume was a debugging leftover that nobody removed before shipping the reference demo.

It's the kind of bug you'd only find by actually running the thing instead of reading the README, which is exactly why I'm writing this instead of just linking you the repo.

Pub/sub worked exactly as advertised, though. Two connections, one subscribes to a channel, the other publishes:

# client A
ws.send("LHTTP/1.0 subpub\r\nsubscribe:room1\r\n\r\n")
# client B
ws.send("LHTTP/1.0 subpub\r\npublish:room1\r\n\r\nHey room1, anyone here?")
# client A receives:
# 'LHTTP/1.0 subpub\r\npublish:room1\r\n\r\nHey room1, anyone here?'

Clean fanout through NATS, no drama. Good, functioning building block.

The bug where you talk to yourself

The actual chat demo (the one with the Vue.js frontend and the little GIF in the README) doesn't use a generic subpub command.

It uses chat for everything, subscribing to a channel called chatroom the moment the page loads, then publishing to that same channel every time you hit Send.

So I replicated exactly what the browser does, using two raw connections named, obviously, Jack and Mike.

jack.send("LHTTP/1.0 chat\r\nsubscribe:chatroom\r\n\r\n")
mike.send("LHTTP/1.0 chat\r\nsubscribe:chatroom\r\n\r\n")

jack.send("LHTTP/1.0 chat\r\npublish:chatroom\r\n\r\nyo mike, lhttp works!")

Jack received two messages back. Mike received one.

jack got:
  'LHTTP/1.0 auth\r\ncontent-type:image/png\r\n\r\nyo mike, lhttp works!'
  'LHTTP/1.0 chat\r\npublish:chatroom\r\n\r\nyo mike, lhttp works!'

mike got:
  'LHTTP/1.0 chat\r\npublish:chatroom\r\n\r\nyo mike, lhttp works!'

Here's why. The chat command handler always fires off a direct personal reply the instant it receives anything (that's the mislabeled "auth"/"image/png" echo from earlier).

Separately, and completely independently, the pub/sub filter re-publishes your message to the NATS channel you're posting to.

Since you subscribed to your own chatroom when you opened the connection, you're also a subscriber of the very channel you just published to.

Nobody else in the room sees the duplicate. Only the sender does.

Which means if you were building on this today without checking, you'd get bug reports along the lines of "why does my own message show up twice but nobody else's does," and the answer would sound completely made up until you draw this exact diagram.

So, is it fast?

The README claims 10,000 messages published in 0.04 seconds on a single core with 1GB of RAM, which is a wildly specific benchmark from 2016 that I have no way to reproduce on identical hardware anymore.

Instead of just repeating someone else's decade-old number, I ran my own, on whatever this machine happens to be:

for i in range(10000):
    ws.send(f"LHTTP/1.0 chat\r\n\r\nmsg-{i}")
for i in range(10000):
    ws.recv()

10,000 request/response round trips over a single websocket, from a single-threaded Python client, no batching tricks: 0.558 seconds, about 17,900 messages per second.

Not the same benchmark, not the same hardware, not really a fair comparison at all, but it does confirm the core loop isn't doing anything silly like blocking on disk or sleeping between messages.

For a text parser held together with string indexing (buildMessage in wsHandler.go walks the raw string character by character, no regex, no fancy tokenizer), that's respectable.

Would I actually use this

Honestly? Probably not for anything new.

golang.org/x/net/websocket (what lhttp is built on) has been the "please use gorilla/websocket or nhooyr.io/websocket instead" example in Go circles for years now, and the protocol's own reference demo has a bug you can find in about ten minutes of poking.

But as a piece of "here's how people solved real-time messaging before everyone standardized on Socket.IO or plain WebSocket JSON frames," it's a genuinely fun read, and it's kind of wonderful that a 2016 vendor folder can still be handed to a 2026 Go compiler and just work without complaint.

If you want to try breaking it yourself, the two repos are linked above. Bring your own Jack and Mike.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs — without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Git Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc is your braking system. It hooks into git commit and runs an AI review on every diff before it lands. 60-second setup. Completely free.

In short, git-lrc helps Prevent Outages, Breaches, and Technical Debt Before They Happen

At a glance: 10 risk categories · 100+ failure patterns tracked · every commit…

View on GitHub

DEV Community: Athreya aka Maneshwar

A VPN Is a Lie You Tell Your Kernel

First, the uncomfortable truth about VPNs

The hard part is not tunneling, it is the phone book

The token is the entire network

Step 1: finding each other at a rotating rendezvous

Step 2: the gossip room, sealed twice

Step 3: the ledger, or "eventual consistency by shouting"

Step 4: an actual packet, end to end

The bit I did not expect to enjoy: leaderless leader election

Now, about that token

The layer cake

What I actually took away

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Git Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

How terminal-sharing tools put your shell in a browser

what even is a terminal

The simplest possible version: ttyd

What if you don't trust the server?

The key delivery trick

Two flavors of crypto

TermPair: AES-128-GCM with counter IVs

sshx: Argon2 stretched key with AES-CTR

The part that makes sshx feel fast

Sessions, state, and the boring stuff that matters

So which one should you use

The takeaway

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Git Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

I'm a Dev Who Barely Knows the Kernel. Here's How I'm Learning How to Track a Packet with pwru

The problem: packets don't have a call stack you can just console.log

Attaching a debugger to (checks notes) every function in the kernel

Wait, you can reuse tcpdump filters here?

The hard part: knowing it's "the same packet"

Turning "packet vanished" into an actual reason

Why this clicked for a devops brain

Wrapping up

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Git Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

6 Open Source Tools That Give You the Web Back

1. Firecrawl: the one that turned a URL into a prompt

firecrawl / firecrawl

The API to search, scrape, and interact with the web at scale. 🔥

🔥 Firecrawl

Why Firecrawl?

2. Crawl4AI: the same idea, but yours

unclecode / crawl4ai

🚀🤖 Crawl4AI: Open-source LLM Friendly Web Crawler & Scraper. Don't be shy, join here: https://discord.gg/jP8KfhDhyN

🚀🤖 Crawl4AI: Open-source LLM Friendly Web Crawler & Scraper.

🚀 Crawl4AI Cloud API — Closed Beta (Launching Soon)

3. Browser-use: an agent with hands

browser-use / browser-use

🌐 Make websites accessible for AI agents. Automate tasks online with ease.

What can Browser Use do?

📋 Fill Forms

Task: "Fill in this job application with my resume and information."

🍎 Extract data

Task: "Extract structured data about my followers and export it as a CSV."

💻 QA Automation

Task: "QA test my local website and report any bugs, usability issues, and visual inconsistencies."

Quickstart

4. Scrapy: the one that was doing this before it was cool

scrapy / scrapy

Scrapy, a fast high-level web crawling & scraping framework for Python.

5. Crawlee: the infrastructure you were about to rebuild badly

apify / crawlee

A web scraping and browser automation library

Installation

With Crawlee CLI

6. Scrapling: the scraper that heals itself

D4Vinci / Scrapling

🕷️ An adaptive Web Scraping framework that handles everything from a single request to a full-scale crawl!

Effortless Web Scraping for the Modern Web

About that "sell this as a service for $5,000 a month" thing

The problem: packets don't have a call stack you can just `console.log`