Weekly ux-pain digest delivery: move to Vercel-cron→authenticated-POST-to-hub→PM-drains-on-reconnect (remove relay-row/always-on-agent dependency). Blocked on llmmsg-maintainer answers: (1) can Vercel POST to hub from outside the reverse tunnel with an auth key, (2) unread-buffer retention/TTL must exceed weekly digest interval so an offline PM still receives it. Applies to mars (replace MARS-84 relay-row) + venus + pluto toast-ports. db agents are NOT 24/7 so a db-host cron is not viable; only nw agents + maybe PMs run 24/7.
BOTH PREMISES ANSWERED AND CONFIRMED SOUND - pm-llmmsgsrv-cc, 2026-09-11, measured live. GO given by pmmaster-evolutiva-cc on Elazar behalf. This row sat for weeks on two questions that had never actually been put to the hub maintainer; they were asked today and answered in minutes. (a) CAN VERCEL POST TO THE HUB FROM OUTSIDE THE TUNNEL - YES, and no tunnel is involved at all. Public ingress is Caddy on llmmsg-hub.pensanta.com (also hub-t.pensanta.com) to 127.0.0.1:9703. No IP restriction. The only gate is an exact shared bearer; anything else is 401 at the edge, verified live over the public name resolving to 91.99.136.171. (b) UNREAD BUFFER RETENTION - there is NO TTL. Messages are kept until drained and in fact are never deleted: zero DELETE FROM messages anywhere in hub.mjs. Unread is cursor-based (WHERE recipient = ? AND id > cursor) and cursors live in their own prune-safe table, so they survive a roster prune. A PM offline for a week receives everything on reconnect. Coverage limit stated by the maintainer and kept here: that negative covers hub.mjs only - external cron was not audited for a reaper. SO THE DESIGN IS NOT DEAD. Build it: Vercel cron to authenticated POST to the hub to PM drains on reconnect, replacing the MARS-84 relay-row and the always-on-agent dependency. Applies to mars first, then the venus and pluto toast-ports. THREE CONSTRAINTS THAT ARE EASY TO MISS AND EACH BREAKS IT SILENTLY. (1) The sender must register FIRST - an unregistered producer is not a delivery failure you will see. (2) A raw-curl producer uses the field named agent, NOT the field named from; the wrong field name is the kind of thing that returns 200 and delivers nothing. (3) LIMIT 200 per drain call - a large backlog needs REPEATED drains, not one, so a drain that returns 200 rows must not be read as inbox-empty-afterwards. That last one is the same shape as every other defect on the board today: a call that succeeds while doing less than the caller assumes. CREDENTIAL: the edge bearer goes into Vercel env and pm-llmmsgsrv-cc will DM it when this is actually being built, not before. Ask when you start, not now. ACCEPTANCE is a delivered digest, not a 200 from the hub. Send one, drain it from the recipient side, and read the content back. NOTE ON THIS ROW HISTORY: an earlier version of this text lost two field names to shell backtick execution. If any sentence here reads as if a word is missing, that is why - the authoritative statement is constraint (2) above.
Activity
-
coder-mars-cc
-
was: (empty)
-
was: BOTH PREMISES ANSWERED AND CONFIRMED SOUND - pm-llmmsgsrv-cc, 2026-09-11, measured live. GO given by pmmaster-evolutiva-cc on Elazar's behalf. This row sat for weeks on two questions that had never actually been put to the hub maintainer; they were asked today and answered in minutes. (a) CAN VERCEL POST TO THE HUB FROM OUTSIDE THE TUNNEL - YES, and no tunnel is involved at all. Public ingress is Caddy on llmmsg-hub.pensanta.com (also hub-t.pensanta.com) to 127.0.0.1:9703. No IP restriction. The only gate is an exact shared bearer; anything else is 401 at the edge, verified live over the public name resolving to 91.99.136.171. (b) UNREAD BUFFER RETENTION - there is NO TTL. Messages are kept until drained and in fact are never deleted: zero DELETE FROM messages anywhere in hub.mjs. Unread is cursor-based (WHERE recipient = ? AND id > cursor) and cursors live in their own prune-safe table, so they survive a roster prune. A PM offline for a week receives everything on reconnect. Coverage limit stated by the maintainer and kept here: that negative covers hub.mjs only - external cron was not audited for a reaper. SO THE DESIGN IS NOT DEAD. Build it: Vercel cron -> authenticated POST to the hub -> PM drains on reconnect, replacing the MARS-84 relay-row and the always-on-agent dependency. Applies to mars first, then the venus and pluto toast-ports. THREE CONSTRAINTS THAT ARE EASY TO MISS AND EACH BREAKS IT SILENTLY. (1) The sender must /register FIRST - an unregistered producer is not a delivery failure you will see. (2) A raw-curl producer uses field , NOT ; the wrong field name is the kind of thing that returns 200 and delivers nothing. (3) LIMIT 200 per drain call - a large backlog needs REPEATED drains, not one, so a drain that returns 200 rows must not be read as 'inbox empty afterwards'. That last one is the same shape as every other defect on the board today: a call that succeeds while doing less than the caller assumes. CREDENTIAL: the edge bearer goes into Vercel env and pm-llmmsgsrv-cc will DM it when this is actually being built, not before. Ask when you start, not now. ACCEPTANCE is a delivered digest, not a 200 from the hub. Send one, drain it from the recipient side, and read the content back.
-
coder03-mars-ca