Sysop Bible

Sysop definition and multiple sysops

See sections 5.1 and 5.2 in 03-sysop-commands.md and the Access Control wiki:

• Levels 90–99 mark operators
• Co-sysops get least-privilege flags/exemptions
• Remote editing cannot escalate past your own powers

A healthy board has a written (even private) note of who can:

• Restart sbbs / the OS
• Change DNS and public ports
• Hold QWK / Fido session passwords
• Approve network feeds and moderate heated echoes

Wiki: https://wiki.synchro.net/access:index

Message Base Moderation

When a sub is “out of control,” Synchronet can require review of posts from users matching the sub’s Moderated Posting User ARS (configured in SCFG on the sub-board). That ARS is default deny when blank — only matching users are moderated.

How moderation works (wiki)

1. A matching user’s post is flagged moderated.
2. Normal readers cannot see messages at/after the oldest unvalidated moderated message until a sub-op or sysop validates or deletes it.
3. When a sub-op/sysop reads, they are prompted to validate; declining leads to a delete prompt. Doing neither leaves the blockage in place — including for network export.
4. If you see:

WARNING: You are reading messages past the last unvalidated message

an older unvalidated message (number included in the warning) is still blocking view/export. Handle that message before worrying about later ones.

Operating tips

• Check moderated subs daily if you enable the feature.
• Give trusted sub-ops clear ARS so they can validate without full sysop level.
• On networked echoes, understand whether moderation fits hub rules before enabling.
• Pair with twitlist / content filters for automated junk, but keep a human in the loop for judgment calls.

Wiki: https://wiki.synchro.net/howto:moderation · https://wiki.synchro.net/access:requirements · https://wiki.synchro.net/config:message_areas

Online sysop commands (daily use)

The string-command module is documented in section 5.4. For Bible-style ops, memorize a small set and rely on ;HELP / ! for the rest:

• User lookup / edit while handling mail or complaints (;UEDIT)
• Message delete/edit/validate paths shown on operator menus while reading
• Node status awareness (who is hung, who needs a chat page)
• Avoid experimenting with bulk destructive commands on live networked subs

Full tables: https://wiki.synchro.net/module:str_cmds

Care-and-feeding rhythms

Daily

• Skim hack log / failed logins if the board is Internet-facing
• Clear moderated queues
• Notice stuck nodes (node utility or Control Panel)

Weekly

• Backup ctrl/ + data/ (and text/, mods/)
• Review new users for obvious throwaway/abuse patterns
• Confirm QWK/Fido events ran (packet dates, echo traffic)

After upgrades

• Read release notes / install:dev if on development builds
• Diff mods/ against new exec/
• Re-test one door, one echo, mail to sysop, and web hit

Community

• Publish clear local rules in text files users actually see
• Separate local rant space from moderated global echoes
• Document co-sysop expectations so moderation is consistent

When things go wrong

Wiki: https://wiki.synchro.net/howto:moderation · https://wiki.synchro.net/module:str_cmds · https://wiki.synchro.net/howto:block-hackers · https://wiki.synchro.net/util:sbbsecho

Tone and ethics (non-technical, still practical)

The wiki will not run your community for you. Technical access control implements policy; it does not invent it. Decide what is local-only vs networked, what is moderated vs free, and how co-sysops escalate to you — then encode that with levels, flags, ARS, and moderation flags as described in chapters 03–05.

Wiki hubs: https://wiki.synchro.net/access:index · https://wiki.synchro.net/howto:moderation · https://wiki.synchro.net/module:str_cmds