open https://gitlab.synchro.net/main/sbbs/-/work_items/1249

`sbbs/+/action/post/SUBCODE` is published from exactly one place: `sbbs_t::postmsg()` (src/sbbs3/postmsg.cpp:349), the interactive Terminal Server path. Every other way a message can enter a sub-board is silent on the topic.

For a system carrying networked message areas, that is most of the traffic. A consumer subscribed to `action/post` sees local interactive posts and nothing else, with no indication that other categories exist.

(A user's own REP upload is filed separately as a bug, since `useron` there is the actual author and the existing payload applies unchanged. This request covers the paths where there is no local user, or the local user is not the author.)

## The gaps

**1. QWKnet node uploading a REP to us as hub** -- `sbbs_t::unpack_rep()`, src/sbbs3/un_rep.cpp:500.
`useron` is the *node's* account, not the message author; the author is `msg.from` on a remote system.

**2. QWK packet import from a hub** -- `sbbs_t::unpack_qwk()`, src/sbbs3/un_qwk.cpp:343.
No local user at all.

Both 1 and 2 are `sbbs_t` methods with `struct mqtt* mqtt` already in scope (src/sbbs3/sbbs.h:516) and a populated `smbmsg_t msg` at the call site, so each is a few lines next to the existing `signal_sub_sem()` call.

**3. NNTP** -- exec/nntpservice.js:1000 posts via `MsgBase.save_msg()`, landing in `savemsg()` (src/sbbs3/postmsg.cpp:437).
Publishing from `savemsg()` would cover NNTP and every other API poster at once, but its signature carries no `struct mqtt*` and it is `DLLEXPORT`ed (src/sbbs3/sbbs.h:1410), so adding a parameter is an ABI change for external callers. An overload or a variant avoids that. The same option exists one level down in `signal_sub_sem()`, which already sits on the postmsg / writemsg / un_qwk / un_rep paths, with the same missing-parameter question. Note jsexec has no `mqtt` at all (no `sbbs_t`, no `mqtt_startup()`), so scripts run from the command line would publish nothing either way.

**4. FidoNet** -- src/sbbs3/sbbsecho.c.
The largest piece. SBBSecho contains no MQTT code, and it does not call `signal_sub_sem()`; it open-codes the semaphore touch at sbbsecho.c:3934, so there is no shared chokepoint to hook. Publishing would require its own broker session, and `mqtt_startup()` wants both an `scfg_t*` and a `struct startup*`, which SBBSecho has no equivalent of. Since it runs as a periodic event rather than a daemon, that also means connect/publish/disconnect per toss, with a slow or unreachable broker able to delay mail tossing.

## The payload question

Worth settling before any of the above, since it is the part that is hard to change once something consumes it. The current payload assumes a local user:

```
timestamp user_number alias posts_today total_posts recipient title
```

On import there is no such user, or the available one is not the author. Two options:

* Put `0` in the user-number slot and `msg.from` in the alias slot, letting consumers read 0 as "not a local user".
* Append an origin field (`local` / `qwk` / `nntp` / `fido`). Appending stays compatible with any consumer that splits on tab and indexes.

Either way this changes what the topic means. Today `action/post` is "a user on this system posted", and it pairs reliably with the `logon_posts` and `user_posted_msg()` accounting. Broadened, it becomes "a message entered this sub by any route", which is more useful for monitoring but would silently start counting network traffic for anyone using it to measure local activity. The monitor:mqtt wiki page should say which it is.

## Suggested order

Decide the payload convention, then do the two QWK paths (small, self-contained), then NNTP via whichever of `savemsg()` / `signal_sub_sem()` is preferred, and leave FidoNet until someone wants it enough to justify giving SBBSecho a broker connection.

-- *Authored by Claude (Claude Code), on behalf of @rswindell*
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)