Implements the notification system foundation and all v1 delivery channels that need no external infrastructure (specs 00/01/04/05 in docs/superpowers/plans/notifications/): Foundation (spec 01): - episode_availability seeding + per-library seed markers: "newly available" means newly released to this server, so back-catalog imports and first scans never flood (verified on dev: 1.13M episodes seeded silently) - release_events -> profile_series_interest fanout worker with settling delay, per-series burst caps, FOR UPDATE SKIP LOCKED multi-node claims, and a guarded last-notified cursor - interest index maintained via a userstore provider decorator so every favorites/watchlist/progress mutation path (REST, jellycompat, imports, playback) feeds it; progress writes only recompute on state transitions - durable per-profile inbox + read state, forward-sync cursor API, websocket channel with short-lived single-use handshake tickets - web UI: sidebar badge, inbox page, toasts, per-profile preferences - startup/daily tasks: availability seeding, interest rebuild, retention Outbound webhooks (spec 04): - Discord embeds (text-only per the v1 privacy contract) and generic JSON signed Stripe-style with per-webhook secrets - HTTPS-only + private-destination guard enforced at registration and at connect time (DNS-rebinding mitigation); URLs/secrets encrypted at rest - durable per-target outbox enqueued in the fanout transaction, lease-based claims, 24h exponential retry, 3x-consecutive-4xx auto-disable with an in-app notice (loop-guarded) Web push (spec 05): - VAPID keypair self-provisioned at startup (single atomic JSON setting, private half encrypted at rest) — no third-party accounts needed - payloads E2E-encrypted (RFC 8291); 404/410 treated as unsubscribe - service worker + subscribe flow in Settings -> Notifications Shared SMTP core (internal/mail): - feature-agnostic mail.Sender over live email.* settings, STARTTLS or implicit TLS, encrypted password, admin Email settings page with synchronous test send; no consumer yet by design (digest is v1.5) APNs/FCM (specs 02/03) are deferred to v2; the capability endpoint reports them unavailable so clients render truthfully. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
32 lines
1.5 KiB
Go
32 lines
1.5 KiB
Go
package notifications
|
|
|
|
import "math"
|
|
|
|
// episodeKeySeasonMultiplier folds (season, episode) ordinals into a single
|
|
// sortable integer key. The 1,000,000 multiplier accommodates absolute-
|
|
// numbered anime catalogs (10,000+ episodes flattened into one season) while
|
|
// keeping the combined value inside PostgreSQL's integer range for any
|
|
// realistic season number. Scanners must not emit episode numbers at or above
|
|
// the multiplier; ValidEpisodeOrdinals rejects such rows at ingest.
|
|
const episodeKeySeasonMultiplier = 1_000_000
|
|
|
|
// episodeKeyMaxSeason is the largest season number whose key still fits in a
|
|
// PostgreSQL int4 (episode_key columns). Higher values come from mis-parsed
|
|
// metadata (e.g. date-style season folders) and must be excluded everywhere a
|
|
// key is computed, in Go and in SQL alike.
|
|
const episodeKeyMaxSeason = (math.MaxInt32 - (episodeKeySeasonMultiplier - 1)) / episodeKeySeasonMultiplier
|
|
|
|
// EpisodeKey returns the canonical progression key for an episode. Every
|
|
// component that stores or compares episode progression and release state
|
|
// must use this helper so keys stay mutually comparable.
|
|
func EpisodeKey(seasonNumber, episodeNumber int) int {
|
|
return seasonNumber*episodeKeySeasonMultiplier + episodeNumber
|
|
}
|
|
|
|
// ValidEpisodeOrdinals reports whether the ordinals can be folded into an
|
|
// episode key that fits in an int4 without collisions.
|
|
func ValidEpisodeOrdinals(seasonNumber, episodeNumber int) bool {
|
|
return seasonNumber >= 0 && seasonNumber <= episodeKeyMaxSeason &&
|
|
episodeNumber >= 0 && episodeNumber < episodeKeySeasonMultiplier
|
|
}
|