Add Wirepeek to DevTools Extensions > Workflow

[SYNCRoSoft]

Supersedes #195 - same change, re-submitted so the commit is authored under the email my Google CLA is signed with (the first attempt used my GitHub noreply address, which the CLA bot can't match). I'll close #195.

Adds Wirepeek to DevTools Extensions > Workflow, at the bottom of the section per contributing.md.

Why it belongs here: it's a DevTools panel for traffic the Network tab shows but doesn't decode. WebSocket frames arrive on the wire as 42["event",{...}] - Engine.IO packet type 4 wrapping Socket.IO type 2 - with a bare 2 heartbeat mixed into application traffic, and binary payloads shown as an opaque blob. Wirepeek resolves the framing into event names and a JSON tree, and unwraps nested base64/gzip, MessagePack, CBOR and Thrift. It hooks WebSocket.prototype in the page's main world at document_start, so it captures the handshake and survives reloads - which the Network tab cannot when DevTools is opened after the connection.

Read-only, no account, no backend, one permission (storage). Free.

Disclosure: I'm the author. Published to the Chrome Web Store on 2 July 2026, well past the two-week guideline in contributing.md, and I use it daily on my own real-time work.

[paulirish]

Interesting. I don't like the feeling of a closed source chrome extension recommended for developers.

But the decoding seems kinda of cool, and so I'm feeling like it makes sense just to bring this decoding over into Chrome DevTools itself. What do you think about that?

[SYNCRoSoft]

Fair objection — I'd rather fix it than argue it.

The decoding is now open source: https://github.com/SYNCRoSoft/wirepeek-decoders (Apache-2.0). Pure functions, no DOM, no extension APIs: engine.io/socket.io framing, MessagePack, CBOR, Thrift compact, JWT, gzip/deflate, LZ4, base64-wrapped JSON, JSON hiding behind a one- or two-character op-code, and a printable-ratio check that separates "encrypted" from "merely encoded" — entropy doesn't, base64 and ciphertext sat at 5.1 vs 5.3 bits/char in my samples. 14 test files, 72 tests, and they run standalone in that repo.

On moving it into DevTools: yes, and I think that's where it belongs. The extension exists because the Messages tab shows you the bytes but not the meaning — if DevTools decodes them, that reason mostly goes away, and I'd rather it did. I signed the Google CLA in August, so I can contribute properly rather than leave a repo for someone to copy.

One design note in case it's useful either way: binarydecode rejects any serializer that doesn't fully consume the buffer, because a decoder that returns plausible garbage is worse than one that gives up.

And please don't merge this PR on my account — your objection holds as long as the extension itself is closed. Happy to close it and open an issue about the decoding instead, if that's a better place to track it.