Drafted by Claude (Opus 5), an LLM made by Anthropic, and posted at the
direction of andy5995.
Problem
A vote in VOTING.DAT names the message it applies to by Message-ID, and nothing
else. The only place the reader can resolve that Message-ID is the HEADERS.DAT
of the packet it is currently reading, so a vote count is displayed only when
the ballot and the message it votes on arrive in the same packet. When they
do not, the ballot is parsed and then silently has nowhere to go.
That turns out to be the common case rather than an edge case, because the BBS
exports each message once, when it is new. Anyone voting on a message is
necessarily doing so after it was exported, so their ballot travels in a later
packet than the message did. The two only coincide when someone happens to vote
in the window between the message being posted and the reader downloading it.
The practical effect is backwards from what a user expects: votes on your own
messages almost never appear, because your messages reach you in the packet
that first carries them, and any votes on them follow afterwards. The more
promptly the reader is used, the more reliably it outruns the votes. Observed
directly: two upvotes arrived in one packet for two messages that had been
delivered in the previous one, and the reader displayed nothing, while the BBS
itself had sent a notification about them.
Nothing can be recovered from the orphaned ballot alone. Its own record carries
the voter's name but an empty recipient and an empty subject, so a list of
unattached votes could say who voted but not what they voted on — only a bare
Message-ID.
Proposal
Keep what is needed to resolve a Message-ID beyond the packet that carried it.
When a packet is read, retain each message's Message-ID together with enough
context to identify it later — at minimum the subject, the area, and the message
number. A ballot in a later packet can then be matched against that store and
reported, even though the message itself is long gone.
Design points to settle
- Where the store lives and what keys it. Read status is already persisted
per packet; this needs to be per BBS instead, since its whole purpose is to
outlive any one packet.
- How it is bounded. It grows with every message ever read, so it needs a
cap, an age limit, or both. A busy network carries thousands of messages a
week.
- How an out-of-packet vote is presented. The message it refers to is not in
the current packet, so there is no letter to hang a counter on. That likely
means a separate view rather than the existing inline display.
- Whether it is worth the state. This is the first thing in the reader that
would need a database spanning packets. Declining to build it is a legitimate
outcome; in that case the limitation should at least be documented plainly, as
the current wording in the manual understates it.
I have confirmed the cause from real packets, but have not prototyped any of the
proposal, and the storage cost has not been measured.
Problem
A vote in VOTING.DAT names the message it applies to by Message-ID, and nothing
else. The only place the reader can resolve that Message-ID is the HEADERS.DAT
of the packet it is currently reading, so a vote count is displayed only when
the ballot and the message it votes on arrive in the same packet. When they
do not, the ballot is parsed and then silently has nowhere to go.
That turns out to be the common case rather than an edge case, because the BBS
exports each message once, when it is new. Anyone voting on a message is
necessarily doing so after it was exported, so their ballot travels in a later
packet than the message did. The two only coincide when someone happens to vote
in the window between the message being posted and the reader downloading it.
The practical effect is backwards from what a user expects: votes on your own
messages almost never appear, because your messages reach you in the packet
that first carries them, and any votes on them follow afterwards. The more
promptly the reader is used, the more reliably it outruns the votes. Observed
directly: two upvotes arrived in one packet for two messages that had been
delivered in the previous one, and the reader displayed nothing, while the BBS
itself had sent a notification about them.
Nothing can be recovered from the orphaned ballot alone. Its own record carries
the voter's name but an empty recipient and an empty subject, so a list of
unattached votes could say who voted but not what they voted on — only a bare
Message-ID.
Proposal
Keep what is needed to resolve a Message-ID beyond the packet that carried it.
When a packet is read, retain each message's Message-ID together with enough
context to identify it later — at minimum the subject, the area, and the message
number. A ballot in a later packet can then be matched against that store and
reported, even though the message itself is long gone.
Design points to settle
per packet; this needs to be per BBS instead, since its whole purpose is to
outlive any one packet.
cap, an age limit, or both. A busy network carries thousands of messages a
week.
the current packet, so there is no letter to hang a counter on. That likely
means a separate view rather than the existing inline display.
would need a database spanning packets. Declining to build it is a legitimate
outcome; in that case the limitation should at least be documented plainly, as
the current wording in the manual understates it.
I have confirmed the cause from real packets, but have not prototyped any of the
proposal, and the storage cost has not been measured.