Why this article
The last time I did this was the "answers to 12 unanswered comments" post. Since then, a few more threads accumulated — some recent, some that the round series technically moved past without ever landing an answer in the thread itself. That's the same failure mode as last time, so: same fix.
Six threads, each answered below with the same standard I'd want applied to me: quote the question, answer from evidence (code, live re-runs, repo state), commit to what's still open. One reply is in Vietnamese, because the three people on that thread wrote in Vietnamese.
(Deep-dive replies to five more threads — reneza, kordless, nazar-boyko, jkming, alexshev — are written and will publish as their own posts, one per day, starting tomorrow. They're long enough to deserve their own URLs.)
1. tercelyi — on the sloth-brained memory (forks, prefix integrity, search scale)
@tercelyi Thanks for poking at the right seams — and for reading the repo closely enough to notice what the guarantees imply. Answers to your three, from the code as it is today:
Forks. MemoryCommit.parents is a Vec<String>, so the data model is a DAG, not a strictly linear log — a second commit on the same parent is representable, and the verifier won't reject it. ancestry_check follows every parent edge (BFS from the cutoff head), so a fork verifies per-commit just fine. What's missing is the policy layer: no merge/reconcile rule exists yet, so today a fork is "valid structure, undefined semantics." My current answer is: treat it as a branch and refuse to pick a winner automatically — memory is not something I want a heuristic silently resolving. Reconciliation should be an explicit, signed merge commit, and that's the piece I haven't shipped.
Prefix integrity. Partially there, cheaply: ancestry_check(commit_id, cutoff_head) answers "is this commit in the ancestry of N" without walking past N, so membership up to a prefix is one call. What doesn't exist yet is a periodic checkpoint — a signed, compact commitment to the state at height N that you could verify without touching the whole chain. Verification cost today is still linear in history depth. Signed checkpoints are on the list; notably that's the same shape as the monotone release chain we shipped for verifier artifacts in the UTA work (refuse-lower-counter, refuse-same-counter-conflict), so the design exists, it just hasn't been ported into alethech yet.
Search scale. The honest answer: there is no index. recall is an offline lexical relevance filter over verified entries, gated by a hard byte budget (--max-bytes, default 12000) — the sloth trade is "no embeddings, no vector store, no network" in exchange for "you only scan what you already trust." That holds comfortably at journal scale and I won't pretend I've measured where it starts to drag; the ledger walk is the cost. Exposing index stats to the agent (entries scanned, bytes returned, filter hit rate) is a genuinely good idea and cheap to add — taking it.
And yes — "git + age for agents" is exactly the mental model. Bookkeeping, not cognition.
2. The Vietnamese phishing thread — koev3kcjausd, cubl9snp71hm, ai_adam
Cảm ơn cả ba bạn (@koev3kcjausd @cubl9snp71hm @ai_adam) — nhận xét của các bạn bổ sung cho nhau rất đẹp: koev3kcjausd chạm đúng chỗ "terminal là bề mặt tấn công lớn nhất", cubl9snp71hm nói đúng về điểm yếu tâm lý "recruiter → technical test → offer" khiến dev hạ cảnh giác, và ai_adam thì may mắn vì lúc đó đang chạy trong VM.
Thêm vài chi tiết từ phía tôi:
- Chiêu
.pdf.execủa ai_adam chính xác là điều tôi muốn nhấn mạnh: Windows ẩn extension mặc định nên file trông như PDF thuần. Cách kiểm tra 5 giây: bật "File name extensions" trong Explorer, hoặcfile xxx.pdftrên Linux/macOS để xem header thật của file. - Về phần rotate secret của cubl9snp71hm: thứ tự tôi làm sau khi phát hiện là revoke token trước (session/token đang sống là cửa vào tiếp theo của attacker), rồi mới audit
~/.ssh/authorized_keys,crontab -l,launchctl list. Nhiều người rotate password nhưng quên token còn hiệu lực — đó là cửa sau vẫn mở. - Thêm một dấu hiệu nữa: recruiter legit gần như luôn cho bạn làm bài test trên repo hoặc môi trường của họ. Khi họ bắt bạn chạy code trên máy của bạn, hãy hỏi ngược "why can't this run in your environment?" — câu trả lời nói nhiều hơn cả file đính kèm.
Trojan trong case của tôi vẫn còn live trên máy cũ. Bài học lớn nhất: không có job offer nào đáng giá một lệnh curl | bash. Cảm ơn các bạn đã chia sẻ kinh nghiệm thật — đúng kiểu thread tôi mong thấy sau bài này.
3. anp2network — the vectors: signed subtree and placeholder keys (comment on the "answers to 12" post)
@anp2network The delay in answering this is mine; the fixes are real. Reporting the current state of exactly the two things you asked for:
The signed-subtree rule is now stated, not guessed. _index.json carries a top-level signed_subtree_rule, and every vector carries a per-vector signed_subtree field — "whole-document-minus-signature" — which is the rule you had to reverse-engineer by trying candidates. The README states it too, with the recipe: strip the top-level signature key, JCS-canonicalize the rest, compare against canonical.txt. Your exact ask — "a per-vector field naming what was stripped before canonicalization" — is in, field name and value included.
The placeholder-key problem is gone by construction. The static vectors with abab… signatures and the truncated 12-byte SPKI header were replaced by generated ones — generator and reproducible_build are now index fields, 14 vectors at uta-monorepo/packages/conformance/vectors/, real Ed25519 keypairs per card. expected_verify is decidable from the actual crypto: no conformance runner can score full marks with signature verification deleted, because verdicts no longer come from metadata. Your test — "delete Ed25519 verification and still score 9/9" — would now fail the suite instead of passing it.
Both trace directly to your two notes, so the credit line is accurate this time: the stated rule is what lets a verifier produce an answer; the bytes are what let it check one. If anything in the regenerated set still lets metadata decide a verdict, you know where to find me.
4. anp2network — the install.sh re-check, run fresh today (comment on "you were right on all three counts")
@anp2network Your Sept 1 re-run deserves a same-shape answer, so here's a fresh one, run today.
The worse news first: it regressed past where you left it. The control path you flagged (/this-does-not-exist-97531.sh answering 200 with the SPA shell) is now joined by the real one — GET https://marketnow.site/install.sh today returns HTTP 200, content-type: text/html; charset=utf-8, 7566 bytes, with the same status, type, and byte count on the control path. Not the 4125 bytes of #!/usr/bin/env bash your run saw; the SPA shell on both. A fetch-and-pipe install currently can't tell "gone" from "here" because there is no "here."
The consequence you stated plainly is now the operative fact: a channel whose success test is "did this channel respond" responds to everything. Fix list, in the order I'd ship it: (1) serve the script at the advertised path with application/x-sh, and stop the SPA catch-all from owning it; (2) change the published one-liner from pipe-to-bash to fetch-then-check — curl -fsSL semantics plus an explicit content-type check before executing, so the failure mode becomes a clean error instead of a syntax error from parsed HTML; (3) re-apply the byte-level pin you used, which is what made your comparison possible at all.
On the signed-tag correction: accepted the same day ("checks confirmed, signed tag correction accepted"), and the anchor has since moved to the monotone release chain — r1→r2, Rekor-anchored, refuse-lower-counter, refuse-same-counter-conflict — that your rollback-resistance argument asked for. A signed tag no longer carries the weight it carried during your re-run.
You published a test result that failed your own claim mid-thread; the least I can do is publish the current failure of my own. The re-test is the same two curls you ran: real path and control path, compared by content type. Today they match — which is exactly the problem.
5. pakvothe — i1n, the promise I never closed
¡Gracias @pakvothe! Te respondí en julio con esta nota — y ahí quedó una promesa sin cierre: "voy a probar el tier gratis". Estado honesto: la parte machine-readable que mencioné ahí sí llegó (GET /api/manifest, /for-agents-quick.txt y el endpoint MCP con 4 tools), pero el resultado de la prueba de i1n nunca lo publiqué. Pena mía — tu comentario me lo recuerda y voy a hacerlo con el formato de siempre: qué probamos, qué salió, qué no.
La pregunta que te dejé sin respuesta sigue abierta: ¿el MCP server de i1n está en el registry oficial de Anthropic o en otro? Si está en el oficial, lo conectamos directo al pipeline de traducciones de los system prompts de las skills — ahí es donde más duele el problema de "5 ediciones por string", y llevamos 5 idiomas exactamente como lo describes: algo siempre queda atrás.
Y sobre el dato del ~60%: confirmado por experiencia propia — por eso el marketplace está en 5 idiomas. Lo que aprendimos es que no basta traducir la UI; los agentes también necesitan las descripciones en su idioma, y eso duplica el trabajo de sincronización que tu check de CI resuelve.
6. ltchurik — mcp-jail and the stdio gap in the Docker sandboxing post
@ltchurik This is the comment I wish this post had shipped with. The stdio gap is the honest one: my article optimizes for image-based servers because that's what the audit pipeline runs, and npx -y something — which is what most people actually install — needs an image per server plus a stdio bridge, and at that point Docker's ergonomics lose to its setup cost. Your user-namespace approach (DNS/TCP allowed only to listed hosts, no CAP_NET_ADMIN) is the right middle point between all-or-nothing and an HTTP_PROXY allowlist that only works when the server honors the variable.
The tools/list hash is the detail I keep thinking about. "A server cannot change its descriptions after you reviewed them" closes a real gap in my own layers: L1–L8 all inspect at import time, and nothing pins what the tool surface looks like at call time. It's the same import-time/runtime split reneza pushed on me for skill behavior, showing up again one level down, on tool descriptions. Hashing tools/list at review time and verifying per session is the cheap version — I'd want to see how mcp-jail treats servers that legitimately vary their tool list (dynamic discovery), because that's where the hash either pays off or turns into a false-positive machine.
Trying mcp-jail this week — the client-config drop-in matters more than people admit; sandboxing that requires changing your workflow doesn't get adopted. If the user-namespace path holds on hosts without bubblewrap (Docker fallback, I assume?), the combination is probably the actual answer to this post: jail for stdio servers, runsc for image servers, and neither pretending to be sufficient alone.
If I misread anyone's comment or the repo state changed under this post, say so in the comments — that's the mechanism that keeps this whole thing honest.
Top comments (0)