chore: raise the db memory limit and rate-limit social writes

Two smaller operational items.

POSTGRES 512M -> 1G. DATABASE_MAX_CONNECTIONS is 30 for a ~100-guest event (feed
polling + SSE + uploads at once), and 30 backends plus Postgres 16's default
shared_buffers leaves very little headroom at 512M. An OOM here doesn't degrade one
feature -- every request path touches the database, so it takes the event down.
Memory is the cheaper knob than shrinking the pool back and reintroducing the
queueing it was raised to fix. .env.example now names the pairing explicitly, the way
it already does for COMPRESSION_WORKER_CONCURRENCY.

SOCIAL WRITES WERE UNTHROTTLED. toggle_like, add_comment and delete_comment were the
only mutating endpoints in the app with no limit at all -- upload, join, recover,
export and admin login all carry one. Asymmetric coverage rather than a deliberate
decision.

Low severity, and honestly so: a like fans an SSE broadcast to every client, but the
export regeneration a comment deletion triggers is contained (REGEN_DEBOUNCE 20s,
workers born with their epoch, superseded ones inert). So the ceiling is 120/min --
far above anything a real guest produces. This bounds a script, not an enthusiastic
double-tapper.

ONE bucket across all three actions: separate buckets would let a caller triple the
aggregate write rate by alternating between them. Keyed per USER, matching the feed
and upload limits -- at a venue every guest is behind one NAT, and an IP key is what
made the /join and /feed limits turn guests away in the first place.

Migration 020 seeds both keys, and both are wired into the admin allowlist, the
config UI and the e2e reseed -- the step two earlier per-area toggles missed, which
left switches that existed in code and could never be flipped.

Tests: 4 e2e, including that the shared bucket really is shared (the part most likely
to be lost in a refactor) and that one guest hitting the ceiling doesn't block
another behind the same IP.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.env.example

@@ -18,6 +18,10 @@ POSTGRES_PASSWORD=CHANGE_ME_use_a_strong_password
 POSTGRES_DB=eventsnap
 # Connection pool size. Default 10. For a busy event (~100 guests polling the feed
 # + SSE + uploads at once) raise to ~30 so requests don't queue on a pool permit.
+# PAIRED WITH THE DB CONTAINER'S MEMORY LIMIT: 30 backends plus Postgres 16's default
+# shared_buffers is already snug in the 1G that docker-compose.yml allots the `db`
+# service. If you raise this, raise `db.deploy.resources.limits.memory` with it — an
+# OOM in Postgres doesn't degrade one feature, it takes the whole event down.
 DATABASE_MAX_CONNECTIONS=30
 
 # ── Authentication ────────────────────────────────────────────────────────────
@@ -54,8 +58,26 @@ EXPORT_PATH=/exports
 #   max image size    20 MB
 #   max video size   500 MB
 #   estimated guests 100
-#   quota tolerance  0.75  (fraction of disk that triggers the low-storage warning)
+#   quota tolerance  0.75  (see below — NOT a warning threshold)
 # Adjust these in the admin UI before the event if needed.
+#
+# quota_tolerance is the MULTIPLIER IN THE PER-USER QUOTA FORMULA, not the point at
+# which anything warns you:
+#
+#     per_user_limit = floor(free_disk * quota_tolerance / active_uploaders)
+#
+# It is recomputed against LIVE free space on every upload, so it self-throttles: guests
+# converge on a fixed point at tolerance/(1+tolerance) of the free space you started
+# with — 43% at 0.75, i.e. ~30 GB of a fresh 70 GB.
+#
+# Raising it therefore AUTHORISES GUESTS TO FILL MORE OF THE DISK. Setting 0.95 in the
+# belief that it means "warn me later" moves the fixed point to ~49% and eats the
+# headroom the keepsake needs — and the keepsake needs a lot, because Gallery.zip and
+# Memories.zip are each roughly a second copy of every original (both store media
+# uncompressed). Budget for media + 2x media, or move exports to their own volume.
+#
+# 0.75 is the tested default. Lower it if the box is tight; raise it only if you have
+# provisioned export headroom separately.
 
 # ── Workers ───────────────────────────────────────────────────────────────────
 # Number of parallel image/video compression workers. Default 2. This is the main

README.md

@@ -34,7 +34,6 @@ A guest scans the QR code on their way in, types their name, and is immediately
 ### Planned (v1.x)
 
 - Individual file download button
-- Low-disk alert (< 10 GB free)
 - Event banner / cover image
 - Chunked resumable upload for large videos
 - Host-curated story highlights
@@ -231,6 +230,45 @@ so a host takedown or a ban actually revokes access to the bytes.
 
 ---
 
+## Sizing the disk
+
+`postgres_data`, `media_data` and `exports_data` are all Docker named volumes under
+`/var/lib/docker/volumes`, so **they share one filesystem**. Filling it does not
+degrade one subsystem — Postgres stops being able to write and the whole event goes
+down.
+
+Uploads are self-limiting. `per_user_limit = free_disk × quota_tolerance ÷
+active_uploaders` is recomputed against live free space on every upload, so guests
+converge on a fixed point at `tolerance / (1 + tolerance)` of the free space you
+started with — **43%** at the default 0.75. On an 80 GB box with ~70 GB free after
+the OS and images, media settles at ~30 GB and stops.
+
+**The keepsake is what the 80 GB baseline does not cover.** `Gallery.zip` and
+`Memories.zip` are built concurrently and each is roughly a second copy of every
+original: both write their media `Compression::Stored`, and `Memories.zip` streams the
+untouched original for every video and for every image at or under 5 MB. So a release
+wants room for **two more copies of the gallery** on top of the gallery itself.
+
+| Stage | Used | Free (80 GB box) |
+|---|---|---|
+| Fresh box (OS + images) | ~10 GB | ~70 GB |
+| Guests reach the quota fixed point | ~40 GB | ~40 GB |
+| Host releases → both archives | ~100 GB | **ENOSPC** |
+
+Two ways to size for it:
+
+- **Provision ~3× your expected media** on one volume (media + two archives), or
+- **give `exports_data` its own volume** so a full export cannot reach Postgres, and
+  size that one at ~2× expected media.
+
+This is no longer silent. The export refuses up front with the two numbers rather than
+hitting ENOSPC halfway through a multi-GB write, a rebuild reclaims the superseded
+generation before it starts (so peak is one generation, not two), and the host
+dashboard warns as soon as the keepsake would not fit — which is the only point at
+which anyone can still do something about it.
+
+---
+
 ## Backup
 
 There are **three** things to back up, and they live in three different places.
@@ -242,9 +280,12 @@ never exported into an operator's shell — so every command below runs through
 ```bash
 # 1. Database snapshot. Runs pg_dump inside the db container (the app image has no
 #    postgres client), reading credentials from the compose environment.
+#    --clean --if-exists makes the dump SELF-CLEANING: without it the restore below
+#    aborts on the first "already exists" against a database that has ever booted,
+#    which is every database you would actually want to restore over.
 mkdir -p ./backups
 docker compose exec -T db \
-  sh -c 'pg_dump -U "$POSTGRES_USER" "$POSTGRES_DB"' \
+  sh -c 'pg_dump --clean --if-exists -U "$POSTGRES_USER" "$POSTGRES_DB"' \
   | gzip > ./backups/db_$(date +%Y-%m-%d).sql.gz
 
 # 2. Uploaded media (originals + derivatives) out of the named volume.
@@ -261,7 +302,7 @@ docker run --rm \
   -v eventsnap_exports_data:/src:ro -v "$PWD/backups":/backup \
   alpine tar czf /backup/exports_$(date +%Y-%m-%d).tar.gz -C /src .
 
-# Weekly offsite sync of the three artefacts above.
+# Offsite sync of the three artefacts above.
 rsync -az ./backups/ user@storagebox.example.com:backup/eventsnap/
 ```
 
@@ -274,6 +315,82 @@ from a directory called `eventsnap`. Confirm yours with `docker volume ls`.
 > stops it being reachable except through the ticket-gated download handler.
 > Backing up only the media volume therefore loses every generated keepsake.
 
+### When to run it
+
+**A nightly cron is the wrong shape for this app.** Every irreplaceable byte is
+created inside one eight-hour window, and nobody can retake a wedding. Run the three
+commands above:
+
+1. **The night of the event**, once uploads have stopped. This is the backup that
+   matters; everything else is a formality.
+2. **After the host releases the gallery**, so the generated keepsake is captured too.
+3. Weekly thereafter, until the event is archived and torn down.
+
+Take the DB dump and the media tarball **back to back**, without uploads in flight
+between them. Upload rows reference files by path — a database from 22:00 and a media
+volume from 23:00 gives you rows pointing at files the dump doesn't know about, and
+rows whose files aren't in the tarball. Locking uploads from the host dashboard first
+(**Uploads sperren**) makes the pair genuinely consistent.
+
+---
+
+## Restore
+
+An untested backup is not a backup. Run this once against a scratch host **before**
+the event — it is roughly ten minutes, and it is the only way to find out that your
+tarball is empty or your dump is truncated while that is still a small problem.
+
+```bash
+# 0. Stop the app FIRST. Migrations run on boot and a live pool will fight the
+#    restore — a booting app against a half-restored schema can leave the migration
+#    table and the schema disagreeing, which is its own recovery problem.
+#    Leave `db` running: the dump is restored through it.
+docker compose stop app caddy
+
+# 1. Database. The dump carries its own DROPs (step 1 of Backup), so this replaces
+#    rather than collides. A dump taken WITHOUT --clean --if-exists will abort here
+#    on the first "already exists" — restore that one into a fresh empty database
+#    instead.
+gunzip -c ./backups/db_2026-07-29.sql.gz \
+  | docker compose exec -T db \
+      sh -c 'psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" --set ON_ERROR_STOP=1'
+
+# 2. Media. NOTE the `--numeric-owner` and the chown: the app runs as a
+#    NON-ROOT user (uid 100, gid 101 — `addgroup -S app && adduser -S app`), and a
+#    restore that lands root-owned files makes every upload fail with EACCES deep in
+#    the write path, surfacing to the guest as a generic 500 with nothing in the UI
+#    to suggest permissions. The explicit chown is what guarantees it — BusyBox tar
+#    (which is what `alpine` ships) has no --same-owner, and restores ownership only
+#    because it runs as root here.
+docker run --rm \
+  -v eventsnap_media_data:/dst -v "$PWD/backups":/backup:ro \
+  alpine sh -c 'tar xzf /backup/media_2026-07-29.tar.gz -C /dst \
+                    --numeric-owner && chown -R 100:101 /dst'
+
+# 3. Exports. Same volume-name caveat, same ownership rules.
+docker run --rm \
+  -v eventsnap_exports_data:/dst -v "$PWD/backups":/backup:ro \
+  alpine sh -c 'tar xzf /backup/exports_2026-07-29.tar.gz -C /dst \
+                    --numeric-owner && chown -R 100:101 /dst'
+
+# 4. Back up. Migrations run, then export recovery re-arms any keepsake whose file
+#    didn't come back with the volume.
+docker compose up -d app caddy
+docker compose logs -f app        # watch for "migrations applied"
+
+# 5. Verify — all three, not just the first.
+curl -fsS https://DOMAIN/health && echo            # → ok
+#   … then sign in as host and confirm the feed renders images (proves the media
+#   volume restored AND is readable by uid 100), and that the keepsake downloads.
+```
+
+If the media volume restored but images 404 while the feed lists them, the paths are
+there and the bytes aren't — check `docker compose exec app ls -ln /media/originals`
+and confirm both the files and the `100:101` ownership.
+
+The restore is deliberately **not** automated. It is rare, destructive, and the one
+operation where a script that half-works is worse than a checklist someone reads.
+
 ---
 
 ## Running the backend test suite
@@ -348,7 +465,7 @@ Open:
 - [ ] SSE delta-fetch on foreground reconnect (scaffolded in [sse.ts](frontend/src/lib/sse.ts), not wired)
 - [ ] Live diashow / slideshow mode — see [docs/CONCEPT_DIASHOW.md](docs/CONCEPT_DIASHOW.md)
 - [ ] Individual file download button per post
-- [ ] Low-disk alert (< 10 GB free)
+- [x] Low-disk alert — host dashboard warns below 10 GB free, or whenever the keepsake would not fit
 - [ ] Event banner / cover image
 - [ ] Chunked resumable upload for files > 100 MB
 - [ ] Shared Tailwind config between main app and export-viewer

backend/migrations/020_social_rate.down.sql

@@ -0,0 +1 @@
+DELETE FROM config WHERE key IN ('social_rate_per_min', 'social_rate_enabled');

backend/migrations/020_social_rate.up.sql

@@ -0,0 +1,16 @@
+-- Per-user rate limit for social writes (likes, comments, comment deletions).
+--
+-- These were the only writes in the app with no limit at all. Every other mutating
+-- path -- upload, join, recover, export, admin login -- carries one; social.rs
+-- carried none, so the coverage was asymmetric rather than deliberately open.
+--
+-- Severity is genuinely low for an invited-guest event, and the amplification worry
+-- turned out to be contained: a like fans an SSE broadcast to ~100 clients, but the
+-- export regeneration it could otherwise trigger is debounced (REGEN_DEBOUNCE 20s)
+-- and superseded workers are inert. So this closes the gap for symmetry, not urgency,
+-- and the ceiling is set high enough that no real guest will ever meet it -- a
+-- double-tapping enthusiast at a wedding is not the thing being defended against.
+INSERT INTO config (key, value) VALUES
+    ('social_rate_per_min',  '120'),
+    ('social_rate_enabled',  'true')
+ON CONFLICT (key) DO NOTHING;

backend/src/handlers/admin.rs

@@ -127,6 +127,9 @@ pub async fn patch_config(
         // Same shape for /recover: the per-(ip, name) bucket is the anti-guessing control,
         // this only bounds a name-cycling flood in front of a cost-12 bcrypt (migration 019).
         ("recover_ip_rate_per_min", true, 1.0, 100_000.0),
+        // Aggregate ceiling on likes + comments + comment deletions, per user per minute.
+        // These were the only mutating endpoints with no limit at all (migration 020).
+        ("social_rate_per_min", true, 1.0, 100_000.0),
         ("quota_tolerance", false, 0.0, 1.0),
         ("estimated_guest_count", true, 1.0, 1_000_000.0),
     ];
@@ -141,6 +144,7 @@ pub async fn patch_config(
         // missing from this allowlist — so the switch existed in code and could never be flipped.
         "admin_login_rate_enabled",
         "recover_rate_enabled",
+        "social_rate_enabled",
         "quota_enabled",
         "storage_quota_enabled",
         "upload_count_quota_enabled",

backend/src/handlers/social.rs

@@ -10,8 +10,40 @@ use crate::error::AppError;
 use crate::models::comment::{Comment, CommentDto};
 use crate::models::hashtag::{self, Hashtag};
 use crate::models::upload::Upload;
+use crate::services::config;
 use crate::state::AppState;
 
+/// Throttle a social write. Keyed PER USER, like the feed and upload limits and for the same
+/// reason: at a venue every guest sits behind one NAT, so an IP key hands the whole party a
+/// single bucket and the most active guest starves everyone else.
+///
+/// These were the only mutating endpoints in the app with no limit at all — the coverage was
+/// asymmetric, not deliberately open. The ceiling is set well above anything a real guest
+/// produces; this bounds a script, not an enthusiastic double-tapper.
+async fn check_social_rate(state: &AppState, user_id: Uuid) -> Result<(), AppError> {
+    let rate_limits_on = config::get_bool(&state.config_cache, "rate_limits_enabled", true).await;
+    let social_rate_on = config::get_bool(&state.config_cache, "social_rate_enabled", true).await;
+    if !(rate_limits_on && social_rate_on) {
+        return Ok(());
+    }
+    let rate_limit = config::get_usize(&state.config_cache, "social_rate_per_min", 120).await;
+    // ONE bucket across likes, comments and comment deletions. Separate buckets would let a
+    // caller triple the aggregate write rate just by alternating between them.
+    state
+        .rate_limiter
+        .check_with_retry(
+            format!("social:{user_id}"),
+            rate_limit,
+            std::time::Duration::from_secs(60),
+        )
+        .map_err(|retry_after_secs| {
+            AppError::TooManyRequests(
+                "Zu viele Aktionen. Bitte warte kurz und versuche es erneut.".into(),
+                Some(retry_after_secs),
+            )
+        })
+}
+
 #[derive(Serialize)]
 pub struct LikeResponse {
     /// The caller's like state *after* this toggle. The client sets `liked_by_me` from
@@ -35,6 +67,7 @@ pub async fn toggle_like(
     if user.is_banned {
         return Err(AppError::Forbidden("Du bist gesperrt.".into()));
     }
+    check_social_rate(&state, auth.user_id).await?;
 
     // Event-scope: the upload must belong to the caller's event (404 otherwise),
     // matching the host handlers' find_by_id_and_event pattern.
@@ -141,6 +174,7 @@ pub async fn add_comment(
     if user.is_banned {
         return Err(AppError::Forbidden("Du bist gesperrt.".into()));
     }
+    check_social_rate(&state, auth.user_id).await?;
 
     // Event-scope: only comment on an upload that belongs to the caller's event.
     Upload::find_by_id_and_event(&state.pool, upload_id, auth.event_id)
@@ -216,6 +250,7 @@ pub async fn delete_comment(
     if auth.is_banned {
         return Err(AppError::Forbidden("Du bist gesperrt.".into()));
     }
+    check_social_rate(&state, auth.user_id).await?;
     let comment = Comment::find_by_id(&state.pool, comment_id)
         .await?
         .ok_or_else(|| AppError::NotFound("Kommentar nicht gefunden.".into()))?;

backend/src/handlers/test_admin.rs

@@ -63,6 +63,7 @@ pub async fn truncate_all(
             ('export_rate_per_day',        '3'),
             ('join_ip_rate_per_min',       '60'),
             ('recover_ip_rate_per_min',    '30'),
+            ('social_rate_per_min',        '120'),
             ('quota_tolerance',            '0.75'),
             ('estimated_guest_count',      '100'),
             ('compression_concurrency',    '2'),
@@ -71,6 +72,7 @@ pub async fn truncate_all(
             ('feed_rate_enabled',          'false'),
             ('export_rate_enabled',        'false'),
             ('join_rate_enabled',          'false'),
+            ('social_rate_enabled',        'false'),
             ('admin_login_rate_enabled',   'false'),
             ('quota_enabled',              'false'),
             ('storage_quota_enabled',      'false'),

docker-compose.yml

@@ -17,7 +17,15 @@ services:
     deploy:
       resources:
         limits:
-          memory: 512M
+          # 1G, not 512M. DATABASE_MAX_CONNECTIONS defaults to 30 for a ~100-guest event
+          # (feed polling + SSE + uploads at once), and 30 backends plus Postgres 16's
+          # default shared_buffers leaves very little headroom at 512M. An OOM here does
+          # not degrade one feature — it takes the event down, because every request
+          # path touches the database. Memory is the cheaper knob than shrinking the
+          # pool back and reintroducing the queueing it was raised to fix.
+          #
+          # Raising DATABASE_MAX_CONNECTIONS further means raising this too.
+          memory: 1G
 
   app:
     build:

e2e/specs/03-feed/social-rate-limit.spec.ts

@@ -0,0 +1,136 @@
+/**
+ * Regression guard — likes, comments and comment deletions are rate limited.
+ *
+ * These were the only mutating endpoints in the app with no limit at all. Every other write path
+ * -- upload, join, recover, export, admin login -- carried one; `social.rs` carried none, so the
+ * coverage was asymmetric rather than deliberately open.
+ *
+ * Severity is genuinely low for an invited-guest event, and the amplification worry is contained:
+ * a like does fan an SSE broadcast to every connected client, but the export regeneration a
+ * comment deletion triggers is debounced (REGEN_DEBOUNCE 20s) and superseded workers are inert. So
+ * this closes the gap for symmetry, and the ceiling is set well above anything a real guest
+ * produces -- it bounds a script, not an enthusiastic double-tapper.
+ *
+ * The bucket is shared across all three actions on purpose: separate buckets would let a caller
+ * triple the aggregate write rate just by alternating between them. That is what the second test
+ * pins, and it is the part most likely to be lost in a refactor.
+ *
+ * Keyed per USER, not per IP — at a venue every guest is behind one NAT, so an IP key would hand
+ * the whole party one bucket. Third test.
+ */
+import { test, expect } from '../../fixtures/test';
+import { seedUpload } from '../../helpers/seed';
+import { BASE } from '../../helpers/env';
+
+const like = (jwt: string, uploadId: string) =>
+  fetch(`${BASE}/api/v1/upload/${uploadId}/like`, {
+    method: 'POST',
+    headers: { Authorization: `Bearer ${jwt}` },
+  });
+
+const comment = (jwt: string, uploadId: string, body: string) =>
+  fetch(`${BASE}/api/v1/upload/${uploadId}/comments`, {
+    method: 'POST',
+    headers: { Authorization: `Bearer ${jwt}`, 'Content-Type': 'application/json' },
+    body: JSON.stringify({ body }),
+  });
+
+test.describe('Social — rate limit', () => {
+  test('a burst of likes past the ceiling returns 429 with Retry-After', async ({
+    api,
+    adminToken,
+    guest,
+  }) => {
+    await api.patchConfig(adminToken, {
+      rate_limits_enabled: 'true',
+      social_rate_enabled: 'true',
+      social_rate_per_min: '3',
+    });
+
+    const g = await guest('Tapper');
+    const uploadId = await seedUpload(g.jwt);
+
+    // Sequential, not parallel: a toggle flips state, so ordering matters for the assertion.
+    const statuses: number[] = [];
+    for (let i = 0; i < 5; i++) statuses.push((await like(g.jwt, uploadId)).status);
+
+    expect(statuses.slice(0, 3), 'the first three are within the ceiling').toEqual([200, 200, 200]);
+    expect(statuses.slice(3), 'everything past it is refused').toEqual([429, 429]);
+
+    const limited = await like(g.jwt, uploadId);
+    expect(limited.status).toBe(429);
+    expect(
+      limited.headers.get('retry-after'),
+      'a 429 without Retry-After tells the client nothing about when to come back'
+    ).toBeTruthy();
+  });
+
+  test('likes and comments share one bucket', async ({ api, adminToken, guest }) => {
+    // THE assertion. Per-action buckets would let a caller triple the aggregate write rate by
+    // alternating, which defeats the point of having a ceiling at all.
+    await api.patchConfig(adminToken, {
+      rate_limits_enabled: 'true',
+      social_rate_enabled: 'true',
+      social_rate_per_min: '2',
+    });
+
+    const g = await guest('Mixer');
+    const uploadId = await seedUpload(g.jwt);
+
+    expect((await like(g.jwt, uploadId)).status).toBe(200);
+    expect((await comment(g.jwt, uploadId, 'schön!')).status).toBe(201);
+    // Two writes spent, whichever endpoints they went to.
+    expect(
+      (await comment(g.jwt, uploadId, 'noch eins')).status,
+      'a comment must consume the same budget a like does'
+    ).toBe(429);
+    expect((await like(g.jwt, uploadId)).status).toBe(429);
+  });
+
+  test('one guest hitting the ceiling does not block another', async ({
+    api,
+    adminToken,
+    guest,
+  }) => {
+    // Keyed per user, not per IP. Every request in this suite comes from one address, which is
+    // exactly the venue-NAT shape that made the /join and /feed limits turn guests away.
+    await api.patchConfig(adminToken, {
+      rate_limits_enabled: 'true',
+      social_rate_enabled: 'true',
+      social_rate_per_min: '2',
+    });
+
+    const noisy = await guest('Noisy');
+    const quiet = await guest('Quiet');
+    const uploadId = await seedUpload(noisy.jwt);
+
+    for (let i = 0; i < 3; i++) await like(noisy.jwt, uploadId);
+    expect((await like(noisy.jwt, uploadId)).status).toBe(429);
+
+    expect(
+      (await like(quiet.jwt, uploadId)).status,
+      'a second guest behind the same IP must have their own budget'
+    ).toBe(200);
+  });
+
+  test('flipping social_rate_enabled off bypasses the limit', async ({
+    api,
+    adminToken,
+    guest,
+  }) => {
+    // The toggle has to actually be honoured, or the admin switch is decorative — the failure
+    // mode two other per-area toggles already shipped with.
+    await api.patchConfig(adminToken, {
+      rate_limits_enabled: 'true',
+      social_rate_enabled: 'false',
+      social_rate_per_min: '2',
+    });
+
+    const g = await guest('Unlimited');
+    const uploadId = await seedUpload(g.jwt);
+
+    const statuses: number[] = [];
+    for (let i = 0; i < 6; i++) statuses.push((await like(g.jwt, uploadId)).status);
+    expect(statuses.every((s) => s === 200)).toBe(true);
+  });
+});

frontend/src/routes/admin/+page.svelte

@@ -84,9 +84,16 @@
 				{ key: 'feed_rate_enabled', label: 'Feed-Limit aktiv', kind: 'bool' },
 				{ key: 'export_rate_enabled', label: 'Export-Limit aktiv', kind: 'bool' },
 				{ key: 'join_rate_enabled', label: 'Join-Limit aktiv', kind: 'bool' },
+				{ key: 'social_rate_enabled', label: 'Interaktions-Limit aktiv', kind: 'bool' },
 				{ key: 'upload_rate_per_hour', label: 'Upload-Limit pro Stunde', kind: 'number' },
 				{ key: 'feed_rate_per_min', label: 'Feed-Anfragen pro Minute', kind: 'number' },
-				{ key: 'export_rate_per_day', label: 'Export-Downloads pro Tag', kind: 'number' }
+				{ key: 'export_rate_per_day', label: 'Export-Downloads pro Tag', kind: 'number' },
+				{
+					key: 'social_rate_per_min',
+					label: 'Interaktionen pro Minute',
+					kind: 'number',
+					hint: 'Likes, Kommentare und Kommentar-Löschungen zusammen, pro Gast. Bewusst hoch angesetzt — soll ein Skript bremsen, keinen begeisterten Gast.'
+				}
 			]
 		},
 		{
@@ -105,7 +112,20 @@
 					kind: 'bool',
 					hint: 'Reserviert für künftige Anzahl-Limits.'
 				},
-				{ key: 'quota_tolerance', label: 'Toleranz (0–1)', kind: 'number' },
+				{
+					key: 'quota_tolerance',
+					label: 'Speicher-Anteil für Gäste (0–1)',
+					kind: 'number',
+					// "Toleranz (0–1)" with no hint invited exactly the wrong reading — that a higher
+					// number means "warn me later". It is the multiplier in
+					// `floor(freier Speicher × Anteil / aktive Uploader)`, so raising it authorises
+					// guests to fill MORE of the disk, not less.
+					hint:
+						'Anteil des freien Speichers, den alle Gäste zusammen belegen dürfen: ' +
+						'Limit = freier Speicher × Anteil ÷ aktive Uploader. Kein Warnschwellenwert — ' +
+						'ein höherer Wert gibt MEHR Speicher frei. Das Keepsake braucht zusätzlich ' +
+						'etwa das Doppelte der Mediengröße; 0,75 ist der getestete Standard.'
+				},
 				{ key: 'estimated_guest_count', label: 'Geschätzte Gästezahl', kind: 'number' }
 			]
 		},