michael/Sentinel
SHA256
1
0
Fork 0
Code Issues Pull requests Projects Releases 4 Packages Wiki Activity Actions
4 releases 5 tags
  • 3.2.0 cf66d18b28

    3.2.0
    All checks were successful
    validation / validate-release (push) Successful in 34s
    Details
    Stable

    michael released this 2026-08-03 12:30:54 +02:00 | 0 commits to main since this release

    Sentinel 3.2.0

    Sentinel 3.2.0 is a configuration and operability release. It introduces per-mode threshold persistence, a greatly expanded setup dashboard, actionable human-readable diagnostics, intelligent no-op change detection, and structured retroassignment job reporting.

    Highlights

    • Per-mode thresholds. Ban thresholds and windows are now stored independently for AutoMod and message mode. Switching modes restores each mode's last-used values instead of resetting to defaults.
    • Expanded setup dashboard. Disable, AutoMod management, delete-history, auto-retroassign, ban DM toggle/message/invite, exemption removal, and AutoMod adopt/repair are all now first-class dashboard controls.
    • Human-readable diagnostics. Validation and reconciliation findings are now keyed by stable codes and rendered as actionable, operator-facing guidance via a dedicated findings catalog.
    • No-op change detection. Configuration writes that produce no effective change no longer create a revision or trigger reconciliation; command and dashboard responses surface "No changes were needed."
    • Structured retroassign jobs. Retroactive assignment now tracks assigned, skipped, and failed counts with terminal status (completed, cancelled, failed), and cancelled jobs automatically restart when protection is ready.
    • Standardized log severity. logCritical is renamed to logError; ban events now log at info severity, aligning structured output with conventional severity labels.

    Detection & Configuration

    • Schema migration v5 → v6 adds ban_threshold_automod, ban_window_automod, ban_threshold_message, and ban_window_message columns with CHECK constraints. Existing rows are backfilled from the current mode's values during migration.
    • A new effectiveThresholds() helper resolves the active threshold/window pair for the current mode, falling back to mode defaults when per-mode values are unset.
    • setMode now persists the outgoing mode's current thresholds before switching, so round-tripping between modes preserves operator-tuned values.
    • The updateDesired store path normalizes the candidate patch against current settings and skips revision bumps when no mutable desired field actually changes, eliminating spurious reconciliation cycles.
    • Policy activation now tracks the last activated revision, policy epoch, and assignment signature, so redundant "protection ready" logs are suppressed and auto-retroassign only fires when the role, exemption set, or toggle actually changes.

    Commands & Setup Dashboard

    • New slash commands: /sentinel delete-history <seconds> and /sentinel auto-retroassign <enabled>.
    • The setup dashboard gains a second action row with Disable, AutoMod, Delete History, and Auto-Retroassign buttons.
    • Ban DM settings are split into separate controls: a toggle, a message editor modal, and an appeal-invite editor modal.
    • Exemptions now support in-dashboard removal via a second user-select menu, alongside the existing add selector.
    • AutoMod management is surfaced in the dashboard with managed/verify-only selection, an adopt-existing-rule modal, and a repair button.
    • Dashboard and status fields now report changes pending activation, manual actions pending, cleanup required, delete-history seconds, and auto-retroassign state, with humanized controller-state labels (Active, Applying changes, Not fully active, Disabled, Stopping).
    • All command and dashboard mutation responses use consistent wording: "applied" on success, "not fully active" on degradation, and "No changes were needed" for no-ops.

    Diagnostics & Logging

    • A new src/findings.ts catalog maps internal finding codes to actionable operator messages covering missing permissions, log-channel problems, trap-role health, AutoMod rule health, stale cleanup, and bot membership.
    • Reconciliation and validation results are now routed through humanizeFinding, replacing raw internal strings in user-facing output.
    • Degrade reporting is deduplicated: the same degradation message is logged once per occurrence rather than on every reconciliation pass.
    • logCritical is renamed to logError across the codebase (logging.ts, ban.ts, runtime.ts, process-supervisor.ts, detection-service.ts, events.ts); ban events are now logged at info level instead of critical.

    Exports & Defaults

    • Safe configuration exports now include dm_on_ban, ban_delete_message_seconds, and enable_retroactive_role_assignment.
    • The default ban DM message no longer references the literal role name @Do not ping; it now says "the trap role," keeping the default applicable regardless of the configured trap-role name.

    Full changelog: 89444dd...6a13c1b

    Downloads
  • 3.1.0 89444dd7f3

    3.1.0
    All checks were successful
    validation / validate-release (push) Successful in 33s
    Details
    Stable

    michael released this 2026-07-10 14:54:05 +02:00 | 5 commits to main since this release

    Sentinel 3.1.0

    Sentinel 3.1.0 is a milestone release focused on reliability, operational maturity, and safe scaling for multi-guild moderation deployments. It brings durable, revision-tracked enforcement, ownership-aware reconciliation of Discord resources, hardened deployment tooling, and a new opt-in policy for immediate bans on a spam bot's very first message.

    Highlights

    • First-message immediate bans. Optionally enabled in both AutoMod and message modes. Toggle it via /sentinel first-message-ban <enabled> or directly from the setup dashboard.
    • Per-guild runtime rewrite. Each guild now runs inside a serialized, generation-fenced controller, ensuring clean separation and race-free execution.
    • Durable state in SQLite. Detection evidence, policy epochs, enforcement claims, leases, retry tracking, and recovery state are all persisted to disk.
    • Bounded role-assignment workers. Background role assignment now respects rolling rate limits while reserving throughput for incoming members.
    • Ownership-aware repair. Sentinel-managed roles and AutoMod rules are reconciled only when the bot explicitly owns them.
    • Supervised lifecycle management. Startup supervision, retention scheduling, graceful shutdown, and isolated per-guild initialization are all built in.
    • Hardened release packaging. Node.js 24 support, a non-root OCI container image, SBOM generation, production dependency audits, and built-artifact smoke tests.

    Detection & Enforcement

    • Ban operations are idempotent, leased, retryable, and recoverable — a restart will not lose or duplicate enforcement.
    • Policy epochs prevent cross-version enforcement. Evidence collected under an old policy can never trigger actions under a newer configuration.
    • AutoMod events are accepted only from attributable BLOCK_MESSAGE actions originating from the currently verified rule.
    • Message edits are durably deduplicated while still catching newly introduced trap-role mentions.
    • Stale asynchronous operations are fenced out — outdated runtime or resource state can never be published.
    • External resources are read-only. Roles and AutoMod rules not explicitly adopted by Sentinel are never modified.
    • Retroactive role assignment now runs as a bounded background job, keeping it from overwhelming the bot's operation.

    Commands & Configuration

    • Slash-command registration is now surgical — it creates or updates only /sentinel and leaves all other application commands untouched.
    • Discord-facing inputs undergo stricter validation: length limits, channel-type checks, permission verification, and role-hierarchy enforcement.
    • Status and configuration exports now surface policy revisions, resource health, reconciliation errors, and first-message-ban state.
    • Configuration exports are delivered as an allowlisted JSON attachment, deliberately omitting sensitive or identifying fields.
    • Setup-dashboard updates are guarded by configuration revisions, preventing stale writes from overwriting newer settings.

    Deployment

    • The supported runtime is now standardized on Node.js 24 and npm 11.
    • Ships a non-root OCI image with persistent SQLite storage at /data/sentinel.sqlite.
    • The build pipeline includes source and test type-checking, coverage gates, dependency audits, CycloneDX SBOM generation, and offline smoke validation.
    • CI produces a verified release archive containing built output, dependency manifests, SBOM, container inputs, and operator documentation.

    Full changelog: c8ae311...89444dd

    Downloads
  • 3.0.0 59d6d4c999

    3.0.0
    All checks were successful
    push / validate (push) Successful in 17s
    Details
    Stable

    michael released this 2026-07-06 00:30:59 +02:00 | 17 commits to main since this release

    Sentinel 3.0.0

    Sentinel 3.0.0 marks a fundamental architectural shift. What was once a single-server bot driven by a flat config file is now a fully fledged, multi-guild moderation platform — with per-server persistent state, a Discord-native admin experience, and a guided first-run setup flow.

    Highlights

    • One process, many servers. A single Sentinel instance now safeguards any number of Discord guilds simultaneously, each with its own configuration, runtime state, event pipeline, and log destination.
    • SQLite-backed settings. Per-guild configuration and exemption lists live in a durable SQLite database rather than config.json.
    • Guided setup dashboard. The new /sentinel setup command walks administrators through every facet of configuration — log channel, detection mode, trap role, thresholds, ban DMs, exemptions, validation, enablement, and retroactive assignment.
    • Slash commands across the board. Every piece of configuration and day-to-day operation is now exposed through Discord slash commands. No file editing, no restarts.
    • Independent guild lifecycles. Each enabled server boots its own runtime; a validation failure in one guild never degrades protection in another.
    • Environment-driven process config. Tokens, database path, application ID, and command-registration scope are set through environment variables or a .env file.
    • Automatic legacy migration. Existing config.json values are imported into SQLite on first run for a frictionless upgrade.

    Detection & Runtime

    • A per-guild runtime manager routes Discord events exclusively to the relevant server controller, keeping guilds fully isolated.
    • Both AutoMod and message detection modes are supported and switchable at runtime — no restart needed.
    • AutoMod is now the recommended default: a ban triggers after 3 blocked pings within 1 hour.
    • Message mode defaults to an immediate ban after 1 ping within 30 seconds.
    • Trap-role assignment, reapplication, recovery from deletion, and AutoMod-rule repair all execute within each guild's isolated context.
    • Bot accounts and exempt users are skipped for both assignment and enforcement.
    • Logging is strictly guild-scoped — one server's activity never leaks into another's log channel.

    Commands

    • Core: /sentinel status, validate, enable, disable, mode, log-channel, thresholds, retroassign, export-config.
    • Trap roles: creation, adoption, and renaming.
    • AutoMod: managed mode toggle, rule adoption, and rule repair.
    • Ban DMs & appeals: configurable pre-ban direct messages with optional appeal-server invite.
    • Exemptions: per-guild trusted-user management.
    • All configuration commands require Manage Server or Administrator.
    • Slash-command registration can be global, limited to selected guilds, or disabled entirely via process configuration.

    Deployment & Migration

    • Local .env files load automatically; exported environment variables take precedence.
    • DISCORD_TOKEN is the canonical token setting; SENTINEL_BOT_TOKEN remains as a legacy alias.
    • The SQLite database defaults to sentinel.sqlite, overridable with SENTINEL_DB_PATH.
    • config.json settings import automatically on upgrade, but the file is deprecated for ongoing use.
    • New deployments should configure each server through /sentinel setup, run validation, then explicitly enable protection.
    • Documentation has been expanded to cover installation, Discord permissions and intents, commands, migration, configuration, day-to-day operation, and troubleshooting.

    Testing & Quality

    • Comprehensive test coverage added for multi-guild isolation, settings persistence, interactions, setup flows, Discord events, role management, AutoMod behavior, queues, bans, and logging.
    • V8-based coverage reporting with enforced thresholds.
    • CI pipeline runs the full coverage-enabled test suite alongside type-checking and production builds.

    Full changelog: 8adddb6...59d6d4c

    Downloads
  • 2.0.0 2d5c9cf47d

    2.0.0 Stable

    michael released this 2026-07-05 21:57:03 +02:00 | 27 commits to main since this release

    Sentinel 2.0.0

    Sentinel 2.0.0 introduces Discord AutoMod-powered honeypot detection. Sentinel can now intercept trap-role pings before they reach a channel, tally blocked attempts inside a rolling window, and ban repeat offenders once a configurable threshold is crossed. The original message-based detection mode remains available and fully functional.

    Highlights

    • AutoMod detection mode. Discord's native AutoMod blocks trap-role mentions before they are posted; Sentinel counts those blocked attempts toward enforcement.
    • Threshold-based enforcement. Define how many pings are tolerated within a rolling window before a ban is issued.
    • Managed AutoMod rules. Sentinel can create, enable, update, adopt, and recreate its own Sentinel Honeypot rule automatically.
    • Verify-only mode. Prefer to manage the AutoMod rule externally? Sentinel can enforce against an existing rule without modifying it.
    • Leaner intents. AutoMod mode skips the privileged Message Content intent entirely.
    • Message-independent bans. Enforcement can fire from AutoMod events alone — no Discord message object required.

    Detection & Enforcement

    • Only attributable BLOCK_MESSAGE actions from the configured AutoMod rule and guild count toward enforcement. Alert actions, unrelated rules, other guilds, bots, and exempt users are all ignored.
    • Each user's attempt count is tracked independently within the configured rolling window.
    • When managing a rule, Sentinel preserves any existing regex patterns while injecting the trap-role mention pattern.
    • Deleted managed rules are recreated automatically; missing, disabled, or incompatible externally managed rules produce critical diagnostics instead.
    • Message mode retains its existing messageCreate and messageUpdate behavior unchanged.
    • AutoMod-triggered bans record the ping count and rolling-window duration in their audit-log reason.
    • Ban operations accept guild and user inputs directly — no offending message needed.
    • Message-mode enforcement still attempts to delete the triggering message before banning.
    • Discord bans now respect the configured message-deletion window.

    Configuration & Permissions

    • detection_mode selects the strategy: message (default) or automod.
    • ban_threshold and ban_window_seconds govern enforcement timing.
    • manage_automod_rule controls rule ownership; automod_rule_id enables verify-only operation against an external rule.
    • ban_delete_message_seconds configures Discord's message-history deletion window on ban.
    • AutoMod mode requires Manage Guild, Manage Roles, and Ban Members permissions.
    • AutoMod mode uses the AutoModerationConfiguration and AutoModerationExecution gateway intents rather than message-content intents.

    Compatibility

    • Existing deployments stay on message mode unless explicitly switched.
    • Message mode bans after a single ping by default.
    • AutoMod mode bans after three blocked pings within one hour by default.
    • AutoMod attempt counters are in-memory and reset on restart.

    Full changelog: 1f314ad...2d5c9cf

    Downloads