BBS - Bulletin Board System

Post by **Pretorian** » 03 Jan 2013, 23:35

This is a post from JVK's blog. I don't know if this is implemented anywhere.

New commands
MHE to transfer a message header
MBO to transfer a message body (post or retrieve).

Both the server and the client announces the support for this system by announcing support for BBS0 in the SUP command (HSUP ADBBS0).
At this point the hub will transfer the message list after a user logged in, just like it would for INF messages (that is, if the server policy is to allow the user to read these messages).

The message list is sent as a chain of MSH messages, and any newly posted messages will be broadcasted as a MHE message to all BBS0 compliant users (to unsubscribe, send HSUP RMBBS0).

Command details
MHE parameters:
MI - Message ID (4 bytes, BASE32)
MF - Message is a child of message ID (allows threading)
ID - CID of user (optional)
NI - Nick of user (optional)
TM - Time posted/altered (seconds since the unix Epoch) (optional)
SU - Subject / topic (optional)
FL - Flags* (0 - reserved, 1 - active, 2 - closed, 3 - deleted, 4 - sticky, 5 - not allowed)
*)

A note about flags:
- The reserved state is used internally on the hub before a message is posted (header exists, body is missing).
- The active state is used for any normal posted message
- When the closed state is used, no replies or updates are accepted.
- When the deleted flag is used, the message should be deleted.
- When the sticky flag is used the message should "persist".
- The "Not allowed" state is used for the hub to deny posts/updates.

MBO parameters
MI - Message ID
TX - Text (optional)

Retrieving messages
A message can be retrieved by sending a HMBO {message-Id} to the hub. The hub will then reply with the a IMBO {message data} to the hub if successful. If the message does not exists, a status message equivalent to incorrect flag (STA 143)

Cache policy
A client SHOULD cache messages on a per hub basis, so that the hub does not need to retransmit all messages always.
The server MAY expire messages, these messages will later not be transmitted as part of the message list, a client should clean up cached messages periodically. For example weekly, unless they are updated by the hub (annouced in the message header list).
The cache key should be based on the message ID (MI) and the timestamp (TM) flags.

Posting message to the hub
A client can post (and modify) a message by sending a MHE command with a new and unique message ID.
Example usage:
Client: HMHE MI1234 MF0 SUHello\sworld FL0
Server: IMHE MI1234 MF0 ID{cid} NI{nick} TM{time(0)} SUHello\sworld FL0
Client: HMBO MI1234 TX{message}
Server: IHME MI1234 MF0 ID{cid} NI{nick} TM{time(0)} SUHello\sworld FL1 (message is sent to all)
At this point each client can download the message (unless it is already cached, which SHOULD be the case for the poster).
Client: HMBO MI1234
Server: IMBO MI1234 TX{message}
Security considerations
Only authorized users should be able to use this system, and the hub should log all messages with the originating IP of each user.

A hub can deny posting a message by sending:
IHME MI1234 FL5 SUposting\snot\sallowed"
A hub can deny viewing messages by not announcing them to unauthorized users. Unauthorized users requesting a message body which is unavailable should be ignored.