Files

T

retoorandClaude Opus 4.8 115e403e67 whatsapp: native C++ client + terminal-screenshot tool

Native WhatsApp Web multi-device client in C++ (src/whatsapp/, namespace
detz::wa), built on OpenSSL plus a vendored public-domain ed25519 ref10
(third_party/ed25519, zlib) for XEdDSA and the nayuki QR generator
(third_party/qrcodegen, MIT); no new runtime dependency.

- WaCrypto, WaBinary, WaProto, WaNoise, WaSignal, WaDevice, WaSocket,
  WaClient, WaStore, WaQr, WaWizard.
- Verified offline against golden vectors captured from the real Baileys
  client (tests/whatsapp_data, from jfelipesjc/wa-go, MIT): HKDF/PBKDF2 RFC
  vectors, XEdDSA roundtrips, codec battery 19/19, ClientPayload byte-exact,
  the Noise handshake, and a 4-exchange Signal session byte-exact. Unit test
  build/whatsapp_test (16/16), run_all step whatsapp.unit.
- Verified live against web.whatsapp.com: `detz --whatsapp-link` connects,
  completes the Noise handshake, receives pair-device, renders a scannable QR
  in the terminal, and persists the device to the vault (whatsapp/<profile>.db).
  Also --whatsapp-status / --whatsapp-unlink.
- Agent tools whatsapp_send and whatsapp_contacts (detz-only, in DetzTools).
- Pairing completion after the phone scans, and the message send path
  (usync + prekey fetch + Signal encrypt + send node), are ported faithfully
  from whatsmeow but unverified in-tree (no linked account in development).
  send_image and own-device fan-out are not wired yet. See docs/whatsapp.md.

Also in this snapshot: the terminal-screenshot tool (src/termshot/,
terminal_screenshot, docs/termshot.md, research/terminal-screenshot-rendering)
and a concurrent session's in-progress llm/muse failover changes carried along
in the shared files.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-10-27 18:22:24 +01:00

1.4 KiB

Raw Blame History

jiro4989/textimg README

Metadata

Field	Value
Institute	Molodetz Institute — Research & Retrieval Division
Subject	terminal-screenshot-rendering
Document type	Source Dossier
Tier	1
Source title	jiro4989/textimg README
Source URL	https://github.com/jiro4989/textimg
Source publisher / author	jiro4989
Source type	repository
Source date (published)	Unknown — not stated
Date researched	2026-10-27
Researched by	tai (agent), model: Claude Opus 5.5, on behalf of retoor
Research method	direct page fetch
Confidence	Medium
Status	Active

Summary

textimg converts ANSI or 256-color text to PNG, JPG or GIF, using a system CJK font chosen per OS.

Key findings

Default font on Linux /usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc; override with TEXTIMG_FONT_FILE or -f.
Supports 8, 256 and 24-bit SGR colors; PNG default; animated GIF option.
Emoji need extra image files or an emoji font; not tested on Windows; MIT.

Pros / strengths

Clear statement of color support levels a renderer must cover.

Cons / limitations / caveats

Depends on a system font that a headless server usually lacks; external Go binary.

Relevance to tai

Rejected; its system-font dependency is the exact failure an embedded bitmap font avoids.

Changelog

Date	Change
2026-10-27	Initial dossier created.

1.4 KiB Raw Blame History