Scoped to direct messages only, and deliberately narrower than the
existing push/desktop "offline" (not connected to this room's channel
right now, which fires on every message) -- email uses GlobalPresence
instead (no open connection anywhere, or appear_offline), since the
other participant could easily just be active in a different room.
Debounced to the first unread message in the conversation rather than
firing on every message in a burst, resetting once they mark it read.
Reuses the existing SMTP/send_email infrastructure from the invite
feature, so it silently no-ops if SMTP isn't configured, same as
everywhere else that already uses it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Message.deleted_at has existed since the initial schema but was never
wired up -- no WS envelope, no permission check, no frontend concept of
it at all. Soft delete, author-only (mirrors the existing edit
permission exactly): content and any attached image/file are cleared
and the underlying MessageImage/MessageFile row and stored file are
actually removed, not just detached, so the message becomes a "This
message was deleted" tombstone with nothing left to recover through a
stale attachment URL. A deleted message can no longer be edited or
reacted to.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
checkForUpdate() was a bare `void registration?.update()` -- a failed
fetch (most plausible right when it's triggered by a WS reconnect, i.e.
the network just flapped from a backend restart) vanished with nothing
caught or logged, leaving only the hourly interval as a fallback. Now
logs the failure instead of swallowing it, and a third trigger checks
for an update whenever a backgrounded tab becomes visible again, so a
tab that misses both the reconnect-triggered check and the hourly timer
still gets a chance the moment someone actually looks at it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
is_archived was previously only exposed on the admin-only AdminRoom
schema and checked in one place (excluding a room from Browse rooms) --
for anyone already a member it was a complete no-op: still in their
sidebar, still fully postable, no indication anywhere it was archived.
Expose is_archived on the regular RoomRead/MyRoomItem schemas, drop
archived rooms from the sidebar list (while keeping them directly
reachable via URL so history stays readable), and reject new messages
in one -- both the WS "message" handler and incoming webhooks -- with a
clear "archived and read-only" response instead of silently no-op'ing
or a confusing membership error.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Typing ":name" now shows a matching-shortcode dropdown (same
join/leave/arrow-key UX as the existing @mention and #room autocompletes),
selecting one inserts the actual glyph immediately rather than leaving
literal ":name:" text. A bare ":" with nothing typed yet suggests
recently-used emoji instead of an arbitrary slice of the ~950 known
shortcodes.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The sidebar shows every DM's online/offline dot at once, but the only
existing signal for a presence change (member_updated) is broadcast to
a room's own channel, which Presence only delivers to a connection that
currently has that specific room joined -- never true for a DM sitting
unopened in the sidebar. Add a dedicated per-user broadcast
(dm_presence_update) sent to each of a user's DM partners on their own
per-user channel whenever their global online/offline state changes, so
the sidebar dot updates without needing that DM to be the open room.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
list_site_invites returned every invite ever sent, so the admin UI's
"Pending invites" section kept showing accepted/revoked rows forever
(just relabeled with a status badge) instead of dropping them. Filter
the query to pending only, and have the revoke action remove its row
from local state immediately instead of leaving a relabeled one behind.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Desktop mode's focus gating (from #49) made losing OS focus send "leave"
for every open room, which stopped live message delivery to that room,
not just notification eligibility -- so a message wouldn't render until
the room was manually left and rejoined. Room join/leave is now gated on
visibility alone, matching the browser; notification eligibility gets its
own separate signal (a "focus"/"blur" WS frame tracked by a new
Redis-backed FocusPresence), so a connected-but-unfocused desktop member
still gets notified without losing live delivery.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Two related fixes:
1. A hidden DM's un-hide-on-new-message path only cleared
RoomMembership.hidden_at in the DB -- it never told an already-open
client to refresh. The only existing signal for that room
(unread_update) does setRooms(prev => prev.map(...)), which is a
no-op for a room that isn't in `prev` at all -- exactly what a
hidden DM is. Now broadcasts the same room_added signal a brand new
DM gets (via UPDATE ... RETURNING to know exactly who was
un-hidden), reusing the fix already established for that class of
bug.
2. While debugging #1's test, found the actual root cause behind the
deploy-blocking migrations from earlier this session: every
WebSocket connection shares one AsyncSession for its entire
lifetime, and SQLAlchemy opens a transaction implicitly on first
use. Nothing ever committed it -- not the initial auth lookup, not
any of the several read-then-continue branches in the message loop
(join/message/edit/reaction all check membership this way). A
connection that's just sitting open (which for a real user can be
hours) was holding that transaction open the entire time, which is
exactly what blocked ALTER TABLE twice in production this session
(confirmed both times via pg_stat_activity -- idle in transaction
for 30+ minutes on this exact query shape). Now commits once after
connection setup and once after every frame via a try/finally
wrapping the whole dispatch, so no exit path (including the many
`continue`s) can leave a transaction open while idling on the next
receive_json().
Verified end-to-end in the browser (a hidden DM reappears in an
already-open tab with zero reload when the other person messages
again) and via a new WS-level test reproducing the exact scenario.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neither participant could get rid of a DM at all -- Leave/Delete were
both deliberately hidden for DMs during the initial build to sidestep
an edge case (removing a membership would break find_or_create_dm's
exactly-two-members assumption), but that left no way out whatsoever.
RoomMembership.hidden_at is a per-viewer display flag, not a
membership deletion: hiding a DM only sets it on your own membership
row, so it disappears from just your sidebar without touching the
other participant's copy or any messages. It's automatically cleared
(reappearing) in two cases: a new message arrives in the room
(broadcast_new_message), or find_or_create_dm resolves back to the
same room because either person re-opens it from the People list --
both count as the conversation being active again.
Also fixes two now-flaky tests (test_message_edit, test_reactions):
broadcast_new_message doing more work before returning shifted timing
enough to expose a pre-existing race where a per-user-channel frame
(desktop_notification/unread_update) could legitimately arrive before
a connection's own "joined" ack. Broadened their existing _recv()
noise-filtering helper (already used for member_updated) to cover
those types too, and used it at the two call sites that were reading
raw receive_json() instead.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
start_dm_endpoint created the room and membership correctly but never
sent the room_added signal every other "you're now in a room" path
(add_member) already sends -- without it, GET /rooms/mine is only
fetched once at app mount, so a DM started against an already-open
client stayed completely invisible until a manual reload. The
recipient still got an offline push/desktop notification (that path
is independent, via _notify_offline_members), just nothing to
actually open when they went looking in an already-loaded session.
Added a test mirroring the existing add_member broadcast test exactly
(recipient connected but never joined any room channel, proving the
signal alone is what tells their client the room exists) -- it failed
before this fix and passes now.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
A DM is a Room with a new is_dm flag, not a separate model -- reuses
all the membership/message/WS plumbing Room already has instead of
duplicating it. The room's `name` (still required + globally unique)
is an internal, never-displayed token derived deterministically from
the two participants' sorted user IDs (dm_room_name), which makes
find-or-create a single indexed lookup and gets free race-condition
safety from the existing unique constraint -- a concurrent double-
start from both people just hits the same IntegrityError->retry-as-
lookup path create_room already established.
Both participants get the plain 'member' role (no owner/admin
distinction makes sense for a 1:1 DM), which incidentally reuses
every existing role gate to block add-member, room-settings edits,
and join-via-browse on a DM for free. update_room also gets an
explicit is_dm guard independent of that, since renaming a DM isn't
just a privacy concern -- it would silently corrupt the find-or-create
invariant. DMs are excluded from both Browse Rooms and the admin
portal's room listing (fully private, per scope).
GET /api/rooms/mine precomputes each DM's other participant (name,
avatar, presence) as dm_partner in one batched query, so the sidebar
can render a DM row without a fetch per row. Frontend: a new "Direct
Messages" sidebar section (searchable by partner name, not the
internal room name), clicking someone in the People list starts or
resumes a DM, and the chat header/composer/RoomInfoPanel all render
the partner's identity instead of a room name where it's a DM.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
delete_room() only ever cleaned up Message and RoomMembership rows,
but none of the FK constraints referencing a room (or its messages)
are declared ON DELETE CASCADE at the DB level -- confirmed across
every migration that added one. Any room that ever had an image/file
attachment, an incoming webhook, an outgoing event subscription, or
was ever #referenced from a message in a *different* room (the one
that originally surfaced this as a message_room_references FK
violation in production) couldn't be deleted at all.
Now explicitly cleans up, in dependency order: message mentions,
reactions, and room-references (both the message-id and room-id
directions), the messages themselves, then room-scoped images/files
(including unlinking the actual stored files after a successful
commit, not just their DB rows) and incoming webhooks/event
subscriptions, before removing memberships and the room.
Added a test reproducing the full scenario -- attachments,
integrations, and a cross-room reference all on one room -- that
would have 500'd before this fix, plus a sanity check that deleting
the room doesn't touch the unrelated room that referenced it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Without requireInteraction, the OS default auto-dismiss (a few seconds
on most platforms) was closing notifications before they were
reliably noticed. Browser/PWA push only -- the Desktop bridge is a
separate codebase with its own native notification handling.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Shows the app version, links the AGPL-3.0-or-later license text, and
links the source repo -- AGPL's own suggested-usage text recommends
exactly this ("if your software can interact with users remotely...
its interface could display a 'Source' link"), not just a courtesy
credits screen.
Version comes from package.json at build time via a Vite `define`
(__APP_VERSION__), so it can't drift from what's actually released.
License text is served at /LICENSE via a frontend/public/ symlink to
the repo-root LICENSE, the same pattern already used for the user
guide. Also bumps both package manifests to 1.0.0 ahead of tagging
the first release.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds the verbatim license text as LICENSE, sets license metadata in
both package manifests, and links it from both README.md files.
Chosen specifically for the network-copyleft clause (AGPL §13): a
modified version run as a hosted service must offer its source to
that service's users, which plain GPL's distribution-only trigger
doesn't cover.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
On mobile, a file input with no accept hint (needed to allow arbitrary
file attachments) makes some Android browsers fall back to a generic
chooser -- Camera, Camera Video, Files -- with no direct Photos/Gallery
shortcut, confirmed via a screenshot showing exactly that. Android
can't reliably offer both "any file type" and a gallery shortcut from
a single input, so the attach button now opens a small menu: "Photo or
video" uses a new input with accept="image/*,video/*" (should surface
the OS media picker's gallery shortcut), "File" keeps today's
unrestricted picker. Upload routing (handleFile) is unchanged either
way.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
A "People" button next to "Browse rooms" opens a modal listing every
site user with an online/offline status dot, online users sorted
first. No backend changes needed -- GET /api/users (the user
directory) and GET /api/users/online (a snapshot of who's connected
anywhere in the app, backing every avatar's status dot already) both
already existed from other features, just never had a UI surface of
their own for regular members.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
MessageList auto-scrolled to the bottom in a useEffect keyed on
messages.length, but .message-image has no reserved width/height (only
max-width/max-height caps) -- unlike UserAvatar and LinkPreviewCard's
thumbnail, which both reserve fixed pixel dimensions. If a message near
the bottom of a room's history has an image attachment, that scroll ran
before the image loaded; the image then grew the container a moment
later, leaving the view scrolled short of the true bottom until the
user scrolled down manually.
Now tracks whether the view is pinned to the bottom (via a scroll
listener) and re-runs the scroll whenever any image inside the list
finishes loading, but only while still pinned -- a late-loading image
in history you've deliberately scrolled up to read won't yank you back
down. A single capture-phase 'load' listener on the container catches
every image (load doesn't bubble, but capture-phase listeners on an
ancestor still see it) without wiring an onLoad prop through each one.
Verified with a direct A/B comparison against the pre-fix code: same
scrolled-away state, same synthetic image load event -- old code never
calls scrollIntoView, new code does and lands back at the bottom.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
USER_GUIDE.md at the repo root is the single source of truth --
frontend/public/USER_GUIDE.md symlinks to it so the same file is both
readable directly in the repo and served by the app, rendered on a new
/help page reusing the existing markdown renderer. Scoped to regular
member features (messaging, rooms, attachments, notifications,
profile); room admin/site admin features are intentionally left out.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Presence (which gates push, desktop notifications, and the unread dot)
only tracked document.visibilityState, which in Electron only flips on
minimize/hide -- not on losing OS focus, e.g. alt-tabbing away with the
window still open. That left the offline-audience computation treating
an unfocused-but-visible desktop window as "present," so notifications
never fired unless the app was actually minimized to tray.
Desktop mode now also requires document.hasFocus() before considering
a room joined; regular browser-tab behavior (visibility alone) is
unchanged. Verified in-browser: losing focus sends a leave frame,
regaining it sends join + gets acked.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Offline members now also get a desktop_notification WS envelope
alongside the existing Web Push send, since Electron has no push
delivery service configured. The client only acts on it when
window.dsDesktop is present and the user's local preference allows it,
so the server needs no awareness of which clients are Electron.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Mirrors the @mention autocomplete exactly -- same trigger-detection
logic (factored into a shared detectTriggerQuery helper, parameterized
on '@' vs '#'), same arrow-key/Enter/Tab/Escape keyboard handling, same
dropdown. Suggests rooms the user belongs to, filtered by name prefix,
showing the room's description as a subtitle when it has one.
MentionAutocomplete.css is renamed to ComposerAutocomplete.css with
generic class names (composer-autocomplete-primary/-secondary instead of
-username/-display-name), now shared by both the mention and room-
reference dropdowns instead of being mention-specific.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Mirrors the existing @-mention system's shape: a regex finds #roomname
tokens, extract_referenced_room_ids validates them against rooms the
*sender* actually belongs to (mirrors mentions' "must be a real member"
rule -- referencing a private room the sender isn't in would otherwise
leak its existence), and a MessageRoomReference join row is stored per
match in create_message. No notification/unread layer, unlike mentions --
referencing a room has no "you were referenced" semantics.
Rendering is the same markdown-link rewrite trick MessageContent.tsx
already uses for mentions (#username -> [#username](mention:username)),
but resolved against the *viewer's* own room list (threaded down from
ChatShellPage's room state through ChatPane/MessageList) rather than the
stored server-side reference -- a reference to a room the current viewer
isn't in quietly renders as plain text instead of a link, same as an
@mention of someone outside the room does. The href scheme renders a
real react-router Link instead of mentions' inert span, since a room
reference is meant to be navigable.
mention_service.strip_code_spans (was _strip_code_spans) is now shared
between both extraction paths rather than private to one module.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The Files/Integrations/Room settings section toggles used a trailing
"+"/"-" glyph -- confusing as a collapse/expand affordance. Replaced with
a small chevron placed before the label, pointing right when collapsed
and rotating 90deg clockwise (pointing down) when expanded, the more
conventional disclosure-triangle pattern.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
is_private was previously only settable at room creation. RoomUpdate now
accepts it, update_room() applies it, and PATCH /api/rooms/{id} allows a
site admin to make the change even for a room they haven't joined (in
addition to the existing room owner/admin gate) -- require_room_role
normally 403s a non-member before the role check ever runs, so this is a
deliberate bypass for site admins specifically.
Flipping the flag has no effect on existing members either direction
(confirmed is_private is only ever checked at self-serve join time) --
it purely controls Browse Rooms visibility and future self-joins.
Frontend: RoomInfoPanel's "Room settings" section is now visible to room
owner, room admin, or site admin (was owner-only), with a privacy toggle
reusing NewRoomModal's existing toggle-switch UI. "Delete room" stays
owner-only, now nested inside that wider section rather than gating the
whole thing.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
A URL that points straight at an image file (Content-Type: image/*) has
no HTML to scrape Open Graph tags from, so the fetch found nothing and
the message showed no preview at all -- reported against
https://imgs.xkcd.com/comics/creepy.png.
link_preview_service now recognizes an allowed image content-type (same
list storage.py uses for uploads) before falling through to the HTML/og:
path, and returns the URL itself as the preview (LinkPreview.is_image).
No need to download the body -- the already-SSRF-validated URL is the
image. The frontend renders that case as a real expandable image
(message-image + lightbox, same as an actual attachment) instead of the
small title+description card, which would have nothing to show anyway.
Verified end-to-end against the reported URL.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Slack/Discord-style link unfurling: the first http(s) URL in a message's
content gets a small preview card (title/description/image/site name)
fetched from the page's Open Graph tags.
Backend:
- Message.preview_url (extracted at create/edit time, cheap regex, no
I/O) points at a link_previews cache row keyed by URL -- the same URL
posted in different messages/rooms fetches once, and a failed fetch is
cached too so a dead URL isn't retried on every reference.
- The actual fetch runs in a background asyncio.create_task from
broadcast_new_message/broadcast_message_update, on its own DB session,
so a slow third-party site never delays message delivery. A separate
"link_preview" WS envelope carries the result once it resolves.
- SSRF protection reuses app/services/ssrf.py's validate_target_url
(renamed from UnsafeWebhookUrlError to UnsafeUrlError now that it's
shared with webhooks), but re-validates before every hop of a redirect
chain rather than once up front -- redirects are followed manually so
each intermediate URL is checked before it's ever connected to.
- Parsed with stdlib html.parser -- no new dependency.
Frontend: a LinkPreviewCard rendered under message content when present,
patched into state live via the new WS envelope and included in message
history for reloads.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Real screenshots (Playwright, headless) from a clean demo room/users
created for this purpose and removed afterward: the main chat view
(Markdown, mentions, reactions), the custom theme builder mid-edit, the
same room under a custom theme, and a mobile-width view.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Both were thin/stale for what the project has actually grown into (the
frontend README still framed things as "Phase 1-6" and listed maybe a
third of the current src/ tree). Added a Features section and tech-stack
summary to the root README, and refreshed the frontend README's layout
listing to match what's actually in src/ today.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Every top-level page independently hardcoded a full-viewport height
(.chat-shell: 100vh, .admin-page: 100%, .login-screen family: min-height
100vh), assuming it alone owned the whole viewport. UpdateBanner renders
globally above all of them (App.tsx), so its height just stacked on top
instead of the page shrinking to make room -- on ChatShellPage specifically
(overflow: hidden), that clipped the bottom of the screen and hid the
composer behind the visible edge.
Made #root a flex column shared by the banner and whichever page is
routed, with each page now using flex: 1; min-height: 0 to fill whatever
space is actually left instead of assuming the full viewport.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Root cause, confirmed live against Postgres and reproduced end-to-end
through two real WebSocket connections: ws/chat.py shares one AsyncSession
for a whole connection's lifetime. A read-only action (e.g. a "join"
frame's membership check) can leave a transaction open with nothing to
commit it until the next write. Postgres's now()/CURRENT_TIMESTAMP
returns that transaction's *start* time in that case, not the actual
statement's -- so a reply sent after any idle/reading period got
timestamped to when the idle period started, sorting it before messages
that were genuinely sent earlier. This is independent of the two earlier
#45 fixes (missing ORDER BY tiebreakers, a stale-response race on
reload) -- both were real bugs, but this was the actual mechanism behind
"my message appears before theirs even though theirs was sent first."
Switched Message.created_at and MessageReaction.created_at from
func.now() to func.clock_timestamp(), which always reflects the actual
moment of execution regardless of how long the transaction has been
open. Migration is a plain column-default change -- no table rewrite, no
lock risk, round-trips cleanly.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The spacing scale (tokens.css) jumps from --sp-4 (1rem) to --sp-6
(1.5rem) -- there's no --sp-5. Three places referenced it anyway, so
those margin declarations were invalid at compute time and silently
resolved to 0:
- ThemeBuilderModal.css's .custom-theme-preview margin-bottom -- the bug
the user actually noticed, as a ~0px gap between the preview mockup and
the color fields below it that read as a visual overlap.
- Modal.css's .modal-divider -- a shorthand `margin: var(--sp-5) 0
var(--sp-4)`, where one invalid value invalidates the whole
declaration, so every <hr class="modal-divider"> (ProfileModal's
section separators, etc.) has had zero margin on both sides.
- AdminPage.css's .admin-invite-list margin-bottom.
All three now use --sp-6, matching the spacing tier that was clearly
intended.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Splitting the builder into a preview column and a fields column still
capped the mockup at half the dialog's width. Give it the full width of
the modal instead (name field on top, preview below spanning the whole
dialog, fields and the native-controls toggle underneath), and scale up
CustomThemePreview's own fixed pixel dimensions (~1.4x: avatar, sidebar,
paddings, font sizes) so the extra room reads as a genuinely bigger
mockup rather than the same small one with more empty space around it.
Modal width bumped from 820px to 960px to match.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The theme editor used to expand inline inside ProfileModal, whose .modal
is capped at min(380px, 100%) -- too narrow to comfortably see the live
CustomThemePreview mockup it's built around. Pulled the editor out into
a new ThemeBuilderModal (min(820px, 95vw), two-column layout above 680px)
opened on top of the profile modal, same stacked-dialog pattern already
used by ImageLightbox/FilePreviewModal. No changes to the theme data
model, activation, save, or delete behavior.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
refreshHistory() fires twice in quick succession on a fresh load -- once
on mount, again when the WS 'joined' envelope arrives shortly after (for
the #37 rejoin-resync case) -- with nothing preventing a slower/stale
response (e.g. the service worker's NetworkFirst cache falling back on a
delayed request) from resolving last and overwriting a newer, correct
one. Track the latest-initiated request and drop any response that isn't
from it.
Confirmed via a production DB check that there are no duplicate
created_at timestamps, ruling out the timestamp-precision theory -- the
actual scrambling was two competing fetches racing, not a data problem.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
A backend restart during a deploy kills every open WebSocket, and the
chat socket's existing reconnect-with-backoff already re-fires onopen
within seconds -- reuse that as a reliable "the server just restarted"
signal to check for a new service worker version, instead of waiting up
to an hour for UpdateBanner's poll. The hourly poll stays as a fallback.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The 12 color pickers (Background, Sidebar background, Surface, Border,
etc.) gave no indication of what each one actually affects without
trial and error. Adds a miniature, self-contained mockup of the real
chat UI above the picker grid -- a sidebar with room rows, a message
with an avatar/mention/role badge, a composer, a danger button -- styled
from inline styles bound to the draft colors (not the --ds-* custom
properties, since those reflect whatever theme is currently active, not
necessarily the one being edited).
Hovering or focusing either a color input or its matching element in
the mockup highlights both, using a fixed amber outline that stays
visible regardless of the theme's own palette -- makes the mapping
between the 12 fields and where they actually show up immediately
obvious in either direction, without needing to activate the theme and
go look around the rest of the app.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Two independent gaps, both fixed since the report was ambiguous about
which "chats" meant:
- ChatPane.tsx concatenated history (REST-fetched) and live (WS-pushed)
without sorting, so anything that could desync receipt order from
send order -- a rejoin/resync racing a still-in-flight WS message,
which opening the same room on another device triggers directly via
a fresh socket connection -- could render messages out of
chronological order. Now sorted by created_at (stable sort, so
same-timestamp messages keep their relative order).
- list_member_rooms/list_open_rooms/list_recent_messages ordered by
created_at alone, with no secondary tiebreaker. Postgres doesn't
guarantee a stable order for tied rows across separate query
executions, so two rooms/messages sharing an identical timestamp
(a real possibility -- rapid sends, bulk-created rooms) could come
back in a different order on two separate fetches, i.e. two devices.
Added id as a secondary sort key everywhere this showed up.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
MessageImage has no stored original filename, so this relies on a bare
`download` attribute (no explicit filename) rather than adding
filename support server-side to match the file-attachment pattern --
the image-serving response's existing Content-Type header is already
enough for the browser to infer a sensible extension on its own.
RoomInfoPanel's Files section reuses the same shared ImageLightbox
component, so its image rows get the same download button for free
with no separate change needed there.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Both account-creation surfaces now require the password twice:
- Web signup (invite-based self-service): SignupComplete gains a
password_confirm field with a model_validator backstop server-side,
plus a client-side match check in SignupPage.tsx for immediate
feedback -- the client check is the primary UX, the server check is
defense in depth so the guarantee doesn't rely on the client alone.
- CLI (python -m app.cli create-user): password is now an optional
positional argument. If omitted, prompts interactively via getpass
(hidden input) twice, retrying on mismatch -- matching what "entered
twice and verified" actually means for a human typing blind. Passing
the password directly as before still works unchanged, for scripted/
automated provisioning.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Reuses the existing upload path unchanged: handleFileSelected's body is
now handleFile(file), called from both the file-input's onChange and a
new onDrop handler on the composer, so drag-and-drop and the "Attach a
file" button share the exact same size-check/branch-on-content-type/
error-surfacing logic rather than duplicating it.
Only the first dropped file, matching the existing single-attachment-
per-message limit. A dashed-border overlay appears while dragging over
the composer for discoverability; a nested dragenter/dragleave counter
keeps it from flickering as the drag crosses child element boundaries.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@username tokens in a sent message are parsed against the room's actual
members (skipping fenced/inline code, so pasted code isn't misread) and
recorded as MessageMention rows, reusing #38's read-tracking and
offline-member broadcast infrastructure rather than building a parallel
notification path:
- Sidebar: a mentioned-and-unread room shows a distinct highlight-
colored badge instead of (not alongside) the plain unread dot --
computed the same way as has_unread, just scoped to messages that
mention the caller, and cleared by the same last_read_at mark-read
flow.
- Push notifications: a mentioned offline recipient gets "X mentioned
you: ..." instead of the generic "X: ...", still per-recipient since
the same message can page some room members and not others.
- Message rendering: a validated @username is highlighted inline,
implemented by turning it into a `[@username](mention:username)` link
before markdown parsing and overriding link rendering to style
`mention:`-scheme links as a span instead of an anchor -- reuses
markdown-to-jsx's existing parser rather than hand-rolling text-node
splitting.
- Composer: typing @ opens an autocomplete dropdown of matching room
members (arrow keys to navigate, Enter/Tab/click to insert, Escape or
moving the cursor away to dismiss).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Replaces the single custom_theme_colors blob (one palette per user) with
a proper CustomTheme table -- users can now save, name, and switch
between as many custom palettes as they like, not just one.
Data model: users.active_custom_theme_id references whichever saved
CustomTheme (if any) is currently active; theme='custom' + that id
together determine what's rendered. The migration data-migrates any
already-saved single palette into a named CustomTheme row on upgrade,
and best-effort backfills the active one back into the old column shape
on downgrade.
New endpoints under /api/custom-themes: list, create, rename/recolor,
delete (falls back the user to a preset if the deleted theme was
active, so the two theme columns can never disagree), and activate.
UserRead.active_custom_theme is only populated when theme == 'custom'
even though the DB deliberately keeps the id set while a preset is
active, so switching to a preset and back doesn't lose the saved
palette.
ProfileModal now lists saved themes as swatches (click to activate,
pencil to edit -- active or not, trash to delete with a confirm), plus
a "+ New" button that creates, activates, and opens the editor for a
fresh theme immediately.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Extends the existing fetch-and-bypass-Content-Disposition pattern
already used for text/markdown previews: the PDF's bytes are fetched
into a Blob and handed to the browser's native viewer via a blob: URL,
which carries no HTTP headers of its own. That sidesteps
Content-Disposition: attachment the same way a script-initiated fetch()
already does for text, without needing an <iframe>/<embed> to navigate
to the real file URL directly (which would respect that header and
force a download) -- and without the backend allowlist endpoint this
issue's original scoping assumed would be necessary.
MIME type is forced to application/pdf explicitly rather than trusted
from the upload, since getPreviewKind gates on the .pdf extension alone
(matching its existing behavior for .md/.txt), so a mislabeled file
still renders instead of downloading or erroring. Object URLs are
revoked on unmount/file-change to avoid leaking memory.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds a 5th "Custom" option to the theme swatch grid alongside the
existing 4 presets, opening a picker for all ~12 CSS custom properties
(backgrounds, borders, text, three accent tiers, highlight, danger) plus
a light/dark toggle for native control rendering.
Persisted as a new users.custom_theme_colors JSONB column, validated
server-side against exactly what a native <input type="color"> can ever
produce. Colors survive switching to a preset and back, since there's no
reason picking a preset for a moment should force redoing every color
pick. Applied at runtime as inline custom properties on :root (presets
stay static CSS) via a shared applyTheme() helper, which is also
responsible for clearing those inline overrides when switching away --
otherwise they'd silently keep winning over whatever preset's own
stylesheet values should apply next.
Live preview on every color change; persists only on explicit "Save
colors" (not per keystroke, since a color input fires continuously while
dragging), and closing the modal without saving reverts the preview back
to whatever's actually persisted.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Shows a dot on rooms with unread messages in the sidebar, updated live
over WebSocket. Reuses the same offline-member audience computation
already used for push notifications: a member gets the real-time signal
whenever they aren't currently connected to that room's channel, which
correctly covers both "room not open" and "room open but tab
backgrounded" (the client leaves a room's channel while hidden).
Persisted server-side via a new room_memberships.last_read_at column so
state survives reload and stays consistent across devices, advanced by
an explicit mark-read call the frontend makes on room-open and on each
live message received while the room is genuinely visible -- gated on a
live visibility check, not a cached ref, so a backgrounded-but-open room
keeps accumulating unread instead of auto-marking-read the instant a
message arrives somewhere it can't be seen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
logout() cleared the session but never called unsubscribeFromPush(),
so a browser's push subscription (and its server-side row) outlived the
session indefinitely -- the logged-out account kept silently receiving
pushes for as long as that browser stayed open. Runs before the session
cookie is cleared since the unsubscribe call is authenticated, and is
best-effort so a failure there can't block logout itself.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Lists files and images actually attached to sent messages in a room,
newest first, with click-through to a lightbox, preview modal, or direct
download depending on type. Queries through messages.image_id/file_id
so an upload that was never sent doesn't show up as a phantom entry.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Shows up to 8 most-recently-picked emoji, pinned above the regular
categories, whenever the picker isn't in search mode -- shared by both
the composer's insert-emoji button and message reactions, since both
go through the same EmojiPicker component. Stored in localStorage
(frontend/src/lib/recentEmoji.ts), per-browser rather than synced
across devices, matching this app's existing local-only preferences
(e.g. the resizable-panel widths).
Verified in-browser: no section when empty, a pick is recorded and
shows up on reopen, order is most-recent-first, re-picking an already-
recent emoji moves it to the front without duplicating, and the list
caps at 8 by dropping the oldest entry.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Root cause of "still not getting push notifications while backgrounded"
despite #31: joinRoom() was made to send unconditionally on the theory
that opening a room always implies genuine visibility (a real click
can't happen on a truly hidden tab). That's wrong for one real case --
mobile Chrome can silently discard and later reload a long-backgrounded
tab from memory, which re-mounts the room and calls joinRoom() again
with nobody actually looking at the screen. Each such reload re-joined
the room's presence with no matching "leave" (a discard skips normal
unmount cleanup), so a room could accumulate a stuck presence entry
that permanently suppressed push notifications for it -- confirmed
live via a user's server logs (repeated silent WS reconnects, and
their account still showing present in the room's Redis presence hash
while genuinely backgrounded).
joinRoom() and the reconnect replay now check document.visibilityState
live instead of trusting a cached ref or sending unconditionally: a
still-hidden reload correctly stays "left" (the room stays in
desiredRoomsRef, so the next genuine foreground transition still joins
it, just deferred instead of wrongly immediate), while a real
user-driven open still joins immediately as before.
Verified both directions in the browser: mounting a room while
genuinely hidden leaves the room's presence hash empty; a subsequent
real visibility transition to visible correctly triggers the deferred
join.
Note: this prevents new stuck entries but doesn't retroactively clear
any that already exist -- an affected user needs one real close
(not just backgrounding) to send a clean disconnect and reset the
stuck refcount.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The WebSocket connection lived entirely inside ChatShellPage, so
navigating to /admin (which never opens its own connection) unmounted
it -- the server correctly marked the user offline since the
connection genuinely closed, even though they were still logged in
and using the app. New ChatSocketContext.tsx hoists the connection to
App.tsx, shared across every authenticated route via a single
provider (keyed by user id, so a logout/login as a different account
gets a clean reconnect rather than an old connection lingering under
a new identity) instead of living inside whichever page happens to be
mounted.
Verifying that fix surfaced a second, independent bug: #31's
visibility handling had gated the *explicit* joinRoom/leaveRoom calls
(fired when a room actually mounts/unmounts in the UI) on the same
isVisibleRef check meant for automatic background/foreground
transitions. That's wrong -- a room can only be opened by a real user
interaction, which can't happen on a genuinely backgrounded tab, so
gating it too meant a stale or momentarily-wrong visibility reading
at mount time could silently skip the join with nothing to ever retry
it. joinRoom/leaveRoom now always send immediately; only the
automatic hide/show transitions and the reconnect replay stay gated
on visibility, which is what #31 actually needed.
Verified both end-to-end in the browser: navigating to /admin via
real in-app navigation (not a reload) keeps the presence dot online,
confirmed via direct Redis inspection and the /api/users/online
endpoint; opening a room and sending a message works immediately
afterward.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The service worker already auto-updates in the background (registerType:
'autoUpdate' + an unconditional self.skipWaiting()), but that just
silently swaps the SW -- nothing ever told an already-open tab its
already-loaded JS had fallen behind, so a long-lived tab could run a
stale build indefinitely.
Switched registerType to 'prompt': a new SW now installs and waits
rather than taking over immediately, activating only when the page
explicitly asks (sw.ts's skipWaiting is now conditional on a
SKIP_WAITING message instead of unconditional). UpdateBanner.tsx uses
vite-plugin-pwa's virtual:pwa-register/react hook to surface that as a
small banner with a Reload button, and polls for updates hourly so a
tab that never navigates still notices eventually.
Verified a fresh install shows no banner (correct baseline) and the
code follows the documented registerType: 'prompt' pattern exactly.
Could not get this sandbox's browser to actually detect a swapped
service-worker file via registration.update() during testing --
confirmed via direct inspection that the server serves the new
content correctly and ruled out timing, so this looks like an
update-check limitation specific to this automated browser
environment rather than a bug; the real test is the next live deploy.
Also adds a "frontend-preview" launch.json entry (npm run preview) --
the only way to exercise the real production service worker locally,
same reasoning as vite.config.ts's existing `preview.proxy` section.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Root cause (found earlier): the server only pushes to users it
believes are "connected" to a room, but that was a raw WebSocket-
connection check with no concept of whether the tab was actually
foregrounded -- a backgrounded-but-still-connected tab looked exactly
like someone actively watching, so the push got suppressed even
though nothing could surface on a hidden page.
No backend change needed: the server's presence tracking (and the
push-suppression logic built on it) was already correct for "not
joined to this room's channel" -- the gap was purely that the client
never told it about backgrounding. useChatSocket.ts now tracks
document.visibilityState and sends "leave" for every desired room
when hidden (without forgetting the app still wants them joined), and
"join" again when visible -- reusing the exact join/leave path a real
room switch already goes through, no new WS message type or backend
logic required.
Rejoining also triggers a message-history refetch in ChatPane (keyed
off the server's existing "joined" ack), so anything sent while
backgrounded gets backfilled instead of silently missing -- as a side
effect, this also fixes reconnect-after-a-dropped-connection never
backfilling either, which had the same gap.
Verified end-to-end: simulated backgrounding in the browser and
confirmed via direct Redis inspection that the room's presence hash
(what push-suppression actually reads) goes empty on hide and
repopulates with a message resync on show.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Every avatar in the app (chat messages, room member list, your own
avatar in the top bar/profile, the admin user list, the room-invite
search) now shows a green/red presence dot. Also adds a global
"Appear offline" toggle in the account menu, letting a user lurk in a
room undetected -- it overrides the real connection state everywhere,
not per-room.
Backend: new GlobalPresence (backend/app/ws/global_presence.py), a
cross-instance Redis-backed connection tracker parallel to the
existing per-room Presence, incremented/decremented on WS connect/
disconnect. A new users.appear_offline column (migration
f0f6e494454a) always wins over actual connection state when computing
displayed status. RoomMemberRead gained a computed `status` field;
add_member/change_member_role/list_room_members all compute it via a
shared _member_status() helper. Connect/disconnect and profile
updates (display_name, avatar, appear_offline) all broadcast
member_updated to every room the user belongs to, reusing the
broadcast infrastructure from the earlier avatar-staleness fix, so
chat surfaces update live with no new WS envelope type needed. A new
GET /api/users/online gives the admin list and user-search a snapshot
(deliberately not live -- see backend/app/routers/users.py) for
surfaces where "accurate as of page load" is good enough.
Frontend: UserAvatar renders an optional status dot; every call site
threads status/appear_offline through from whichever data source it
already has (room members, the current user, or the new online-ids
snapshot for admin/search).
4 new backend tests (backend/tests/test_presence.py); existing
broadcast-adjacent WS tests updated to tolerate the new member_updated
noise on connect. Verified end-to-end in the browser with two real
users: presence dot flips live on connect/disconnect via the existing
room-broadcast channel, and the lurk toggle correctly forces offline
while still connected.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The service worker cached /api/rooms/mine, /api/rooms, .../messages,
.../members, and /api/invites/mine with StaleWhileRevalidate: serve
the previous cached response immediately, refresh the cache in the
background for next time. That means every repeat visit showed
content one visit behind -- reopening a room after someone messaged
it, or checking a second device, both showed stale data until a
manual reload (which finally picked up the now-revalidated cache).
Only registers in a production build (vite dev never activates it),
which is why this didn't surface during in-browser testing this
session for #26/#27/#34.
Switched all five routes to NetworkFirst: always prefer a live
response, fall back to cache only when the network request itself
fails or times out (genuinely offline), keeping the "readable while
offline" behavior without the staleness.
Verified against a real production build (`vite preview`, the only
way the SW actually registers): sent a message from a second session
against an already-cached room, and the very next fetch showed it
immediately with no staleness.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Browsers already spellcheck a plain <textarea> by default (confirmed
in-browser: spellcheck read true on the composer with nothing
disabling it), but that's an implicit default rather than a guarantee
across every browser/PWA context. Set spellCheck explicitly on both
the composer and the message-edit textarea so it can't silently be
off somewhere it wasn't verified.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Another user's new display name or avatar didn't show up until you
reloaded -- update_profile/upload_avatar/remove_avatar never told
anyone. Same root cause and fix shape as #26 (room_added): the
frontend's already-fetched member list had no way to hear about a
change, since nothing ever pushed one.
Reuses the existing per-room broadcast channel (not the per-user one
#26 added, since this only matters for rooms the affected user shares
with someone currently looking at them) -- publishes member_updated to
every room the user belongs to; ChatShellPage refetches members when
it arrives for the currently open room.
Verified end-to-end in the browser: one user's room-info member list
updated live when another user changed their display name from a
separate session, no reload.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Reacting to a message near the bottom of the scrolled list opened a
picker that ran off-screen and couldn't be used -- placement was
hardcoded to "below" regardless of the trigger's actual position.
Now computed per-click from the trigger's bounding rect against
available viewport space, matching the composer's own picker (which
was already positioned dynamically, just always "above" since it's
pinned to the bottom of the screen).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Typing a complete 😂/😉/etc. shortcode now renders as the emoji,
matching Slack/GitHub/Discord. Render-time only, alongside the existing
preserveLineBreaks preprocessing step -- stored/sent content keeps the
raw :name: text, same as markdown itself is never converted until
display. Fenced code blocks and inline code spans are skipped so
pasted code (a Ruby symbol, a dict key) isn't silently mangled.
frontend/src/lib/emojiShortcodes.ts is generated once from
emojibase-data's GitHub shortcode set (same one-time-generator approach
as #19's emojiNames.ts, never a runtime dependency) -- 928 of the
app's 936 emoji matched, 956 aliases, no collisions.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Previously GET /api/rooms/mine was only ever fetched once at app mount,
so a room added mid-session stayed invisible until a full page reload
-- add_member had no way to reach an already-open client at all.
Backend: ConnectionManager and Broadcaster (renamed from RoomBroadcaster)
now support per-user channels alongside the existing per-room ones, so a
signal can reach a user's socket even for a room they haven't joined
(and by definition can't have, until this fires). add_member publishes
a room_added event on the target user's channel.
Frontend: the WebSocket connection is no longer scoped to whichever
room is open -- ChatShellPage now owns one persistent connection for
the whole session (including while no room is open, which is exactly
when this bug showed), and ChatPane joins/leaves rooms on top of it.
A room_added event triggers a room-list refetch with no reload needed.
Verified end-to-end in the browser: a user sitting on the empty room
list saw a newly-added room appear live, then chatted in it normally.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The composer's message textarea lacked min-width: 0, so on browsers
that compute a larger default intrinsic width for flex-child form
controls (observed on Firefox for Android), the row could overflow
and push the fixed-width send button past the viewport edge instead
of shrinking the textarea to fit.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
RoomInfoPanel was hard-gated behind !isMobile in ChatShellPage.tsx, but
its trigger button ("Room details" in ChatPane.tsx) still rendered and
toggled state unconditionally -- tapping it on mobile did nothing
visible, with no way to reach room info/members/settings at all. Fixed
by removing the gate and making the panel itself responsive: it renders
as a full-screen fixed overlay below the mobile breakpoint instead of
the desktop resizable aside (which stays exactly as before -- verified
in-browser at both viewport sizes).
Also found and fixed a second real bug during the mobile audit: the
emoji picker's fixed 320px width overflows a 375px-wide viewport by 5px
depending on trigger position (e.g. the composer's emoji button, near
the left edge). Shrunk it to 280px with a proportionally reduced column
count below 480px, rather than attempting dynamic position-aware sizing
for a 5px overflow.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
A search box in EmojiPicker filters the flat emoji list by name/keyword
instead of only browsing by category, shared by both the composer's
emoji trigger and the message reaction picker.
Names/keywords didn't exist anywhere in this codebase before (emoji.ts is
just raw unicode characters). Rather than hand-typing entries for all 928
unique emoji -- a lot of manual work, and unlike the codepoints themselves
a wrong name only means a bad search result, not a broken emoji, so the
accuracy argument for hand-typing didn't apply here -- generated
emojiNames.ts once from emojibase-data (MIT licensed), matched against
emoji.ts by codepoint (normalizing variation-selector differences between
the two sources). emojibase-data itself was never added to package.json;
it was only ever a one-time generation tool, so this ships with zero new
runtime dependency.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The NOPASSWD rule from 3f only covered the bare `systemctl status
ds-chat` with no arguments, but deploy/upgrade.sh actually calls it with
`--no-pager -l`. Sudoers matches commands on the exact argument string
unless a wildcard is present, so the extra flags fell through to a
password prompt on every upgrade run -- one that can never actually be
satisfied, since ds-chat correctly has no password at all (a nologin
system account). Added a wildcarded pattern alongside the exact one so
upgrade.sh's real invocation matches.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
cfg.use_tls was passed straight through as aiosmtplib's use_tls kwarg,
which means implicit TLS -- encrypted from the first byte, port 465's
convention. Port 587, what most providers (including the one that
surfaced this: DreamHost) document as their primary submission port,
needs STARTTLS instead -- a plaintext connection that upgrades in-band.
Forcing implicit TLS against a STARTTLS-only port breaks the handshake
outright: [SSL: WRONG_VERSION_NUMBER], a client TLS ClientHello sent to a
server still expecting a plaintext SMTP greeting.
The "Use TLS" checkbox still means "encrypt this connection" -- the fix
infers which of the two negotiation modes to use from the port (465 ->
implicit, everything else -> STARTTLS), matching the convention every
mail client uses. start_tls is passed as an explicit requirement rather
than left to aiosmtplib's opportunistic default, so a server that turns
out not to support STARTTLS fails loudly instead of silently sending in
plaintext despite the admin asking for encryption.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Three real, reproducible bugs in DEPLOYMENT.md's app-server setup steps,
each found by actually following the guide on a real box rather than
static review:
- useradd --system --create-home is unreliable on Debian in both
directions: sometimes it silently skips creating the home directory,
sometimes it creates it AND populates it from /etc/skel
(.bashrc/.profile/.bash_logout). Either way it broke a later step --
the skel files make git clone refuse to clone into a non-empty
directory. Fixed by dropping --create-home and creating the directory
ourselves, deferring anything else that goes in it (uploads/) until
after the clone.
- Documented a personal/deployment-user access token as a first-class
alternative to the SSH deploy key for cloning, alongside its plaintext-
in-.git/config tradeoff.
- The create-user command nested a user-chosen password inside two layers
of shell quoting (an outer bash -c '...' plus inner double quotes) --
fragile for any password with a space or a literal '. Replaced with
dropping into an authenticated interactive shell first, so there's only
one layer of quoting to get right at an actual prompt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
DEPLOYMENT.md: two spots (§7 backups, §9 known gaps) said "images" when
they should say "images and file attachments" -- generic file attachments
(#13) share the exact same no-backup-coverage and orphaned-upload gaps as
images, but the wording was never updated when that feature shipped.
ARCHITECTURE.md §9.2 and the tech-stack table described a materially
different, outdated architecture: nginx running on the app server,
reverse-proxying to gunicorn over a Unix socket. The actual setup (which
DEPLOYMENT.md already correctly documents) has no nginx on the app server
at all -- gunicorn binds a TCP port directly, and TLS/reverse-proxying is
handled by an external, pre-existing Nginx Proxy Manager instance. Rewrote
both to match reality.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Four preset color themes, switchable from Profile settings with instant
preview and server-side persistence (User.theme, applied via a data-theme
attribute the CSS custom-property overrides in themes.css key off). Dark
stays the existing DarkSingularity palette and default. Light is a genuine
new light-mode design; Midnight is a higher-contrast OLED-friendly dark
variant; Sunset swaps in a warm amber/coral accent family.
Custom theme building (pick-your-own-colors) is out of scope for this
pass -- presets only.
Also: fixed the PATCH /api/auth/me handler to only apply fields actually
present in the request body. It previously always overwrote display_name
unconditionally, which happened to be harmless when it was the only
field on ProfileUpdate but would have silently cleared it on any
theme-only update. And switched two hardcoded hex colors
(.btn-primary:hover, .role-badge-admin) to token-derived color-mix()
values so they adapt across themes instead of staying fixed to the
original cyan/violet palette.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Clicking a .md/.txt attachment now opens a modal instead of downloading,
with an explicit download button still available inside it. Markdown
renders through the same XSS-safe renderer used for chat messages;
plain text renders as literal escaped content via <pre>.
No backend change needed: the preview content is read via fetch(), which
is unaffected by the Content-Disposition: attachment header the file-serve
endpoint always sends (that header only steers the browser's own
navigation/embed rendering, not a script-initiated body read) -- so the
existing download-forcing security behavior from #13 stays intact.
Non-previewable types (PDF, etc.) are unchanged.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Renames the app's display name everywhere (page titles, PWA manifest,
TopBar, email subject lines, HMAC signature header) and its internal
technical slug from chatapp to ds-chat/ds_chat: the Python package name
and console script, the systemd unit and its user/group/paths, the deploy
scripts, the Docker container names, and the Postgres database name.
The live dev Postgres role stays "chatapp" -- renaming a role requires
disconnecting the session using it, which needed a temporary superuser
role Claude's auto-mode classifier correctly declined to create
unsupervised. Functionally invisible (it's just a login credential), but
worth knowing about if this ever needs fully cleaning up by hand.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The 8MB image/file/avatar cap is now a site setting (UploadSettings,
single-row table like SmtpSettings) editable from the Admin Settings tab,
instead of a hardcoded constant. All three upload endpoints read the live
value and interpolate it into their 413 messages. A new GET
/api/uploads/limit endpoint (open to any authenticated user, unlike the
admin-only settings endpoints) lets the composer reject an oversized file
client-side before it ever hits the network, though the server still
enforces the same cap independently.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Messages can now carry an arbitrary file (MessageFile), parallel to the
existing MessageImage feature rather than a refactor of it. Files serve
with Content-Disposition: attachment to force a download and prevent an
uploaded HTML/SVG from executing same-origin. No content-type allowlist,
same 8MB cap as images for now (a separate size-limit redesign is tracked
as its own issue).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Renders message content with markdown-to-jsx: bold/italic/strikethrough,
inline code, fenced code blocks, blockquotes, lists (incl. nested and
task lists), tables, footnotes, headings, and highlight (==text==).
Raw HTML in message content is parsed to escaped literal text rather
than rendered (disableParsingRawHTML), which is the XSS mitigation for
this being user-generated content -- verified against both <img
onerror> and <script> probes. Markdown image embeds degrade to a link
instead of an <img>, since the app already has a first-class image
upload and a second silent remote-image-embed path would duplicate it
and leak the viewer's IP to arbitrary URLs.
The inline message-edit control is upgraded from a single-line <input>
to a <textarea> so multi-line markdown can actually be edited without
losing newlines, mirroring the Composer's Enter-sends/Shift+Enter-
newlines convention.
Since CommonMark treats a single newline as a soft break (collapses to
a space) rather than a visible line break, added a small code-fence-
aware preprocessor that converts single newlines to hard breaks --
without it, existing multi-line messages sent via the Composer's
Shift+Enter would silently collapse onto one line.
Also fixes heading levels rendering at an identical capped size
(should still step down by level, just capped lower than default), and
adds CSS for markdown constructs the library already parsed but hadn't
been styled for the dark theme: table borders, highlight/mark color,
task-list checkbox accent, and footnote divider.
The old list was a small hand-picked subset that was missing common
ones (party popper, facepalm, shrug, etc.). Reorganized into ten
categories (Smileys, People & Gestures, Hearts, Animals & Nature,
Food & Drink, Travel & Places, Activities & Sports, Objects, Symbols,
Flags) with much broader coverage in each. Widened the picker panel
and bumped the grid to 9 columns to fit the larger set comfortably.
Users can change their own password from the profile modal, and a
"forgot password" link sends a 15-minute expiring reset link (same
hashed-token pattern as site invites). The forgot-password response is
always generic so it never reveals which emails are registered.
Also fixes two admin-page display bugs found while testing: table row
divider lines that didn't line up across a row (the actions column had
`display: flex` on the <td> itself, breaking it out of normal table-cell
layout -- moved to a child <div>), and the pending-invites list floating
with no visual grouping (now boxed with a label and per-status badges).
Generalizes useResizableWidth with a left/right anchor option and wires
it into the sidebar the same way the room info panel already uses it,
so both sides of the chat shell can be dragged to a comfortable width.
Room info panel is now user-resizable (fixing a layout clip at narrow
widths), and every user-selection spot (room membership, admin ownership
transfer) uses a new searchable UserPicker instead of raw text input or
prompt(). Member rows fold role + actions into a single inline dropdown
instead of a row of buttons, so the member list stays usable as rooms grow.
Room invites (the accept/decline flow) are replaced by adding a user to a
room directly -- an admin/owner picks someone and they're a member
immediately, with a "you've been added" notification email instead of an
invite email. Drops the now-unused room_invites table.
Site admins can invite a brand-new person by email from the Admin portal
Users tab -- a signup-link email lets them set their own username/password
and lands them in the app already logged in. Existing users invited to a
room now also get an email. Closes the "invited but never notified" gap
from both directions.
SMTP is configured through the Admin Settings tab at runtime (not the env
file), persisted in a new smtp_settings table with the password encrypted
at rest via a Fernet key derived from SESSION_SECRET -- the first
reversible secret this app stores in the database. A "send test email"
button surfaces real delivery errors; the invite/notification paths
themselves never fail loudly, since an SMTP outage shouldn't block an
action that already succeeded in the database.
New site_invites table mirrors RoomInvite's shape but targets an email
address with no room context; the raw signup token is hashed the same way
API tokens are, and only ever exists in the email link. POST /api/signup
is the first genuinely public, unauthenticated account-creation endpoint
in this app, reusing the existing register_user path for identical
validation.
Saving a display name previously gave no feedback and left the modal
open, and an open room's message list/member panel kept showing the
pre-edit profile until reload -- both fetch that data from a member list
ChatShellPage only fetched once per room. Now the save closes the modal
(clear confirmation it worked) and ChatShellPage re-fetches room members
whenever the logged-in user's own display_name/avatar_filename changes,
so the update appears immediately everywhere without a reload.
Users can set a display name (shown instead of username in the message
list, room member list, TopBar, and admin Users tab) and upload a real
avatar, replacing the generated color-initial avatars everywhere a user
appears. Avatars are square-cropped and downscaled to 512px, reusing
app/storage.py's upload primitives from image uploads with a new square
option.
Two deliberate divergences from message-image handling, documented in
backend/README.md: the previous avatar file is deleted on replace/remove
(safe since it's strictly one file per user), and avatar serving is not
room-gated and uses a short cache (identity-addressed and mutable, unlike
a message image's permanent content-addressed URL).
Frontend: new ProfileModal reachable from the TopBar account menu;
AuthContext gains updateUser() so a profile change reflects instantly
everywhere without a refetch.
Composer gains an emoji picker (static curated unicode list, insert at
cursor position) and messages gain Slack/Mattermost-style reactions:
react with any emoji, toggle off by reacting again, see who reacted via
a tooltip on each pill.
Backend: MessageReaction model (unique on message_id+user_id+emoji backs
toggle semantics), WS "reaction" envelope broadcasts the full recomputed
reaction list per message (same approach as message edits), REST message
list embeds reactions so a reload doesn't lose state that only arrived
over WS.
Frontend: shared EmojiPicker component (anchored popover, Escape/outside-
click dismiss via new useEscapeKey hook) used by both the composer and a
new hover-revealed reaction trigger on each message row.
Images live on the app server's local disk (uploads/), served through an
authenticated, room-membership-gated endpoint since rooms can be private.
Uploads are streamed with a byte-count cap, validated as genuine decodable
images with Pillow (not just a spoofed Content-Type), and downscaled to
2000px on the longer side (except GIF, to preserve animation).
Backend: MessageImage model + nullable Message.content/image_id with a
content-or-image CheckConstraint, upload/serve endpoints in rooms.py, WS
message envelope gains image_id, push notification body says "sent an
image" for image-only messages.
Frontend: Composer gets an attach button with upload progress and a
thumbnail chip; MessageList renders images inline with a click-to-zoom
ImageLightbox.
Replaced the Slack/iMessage-style layout (your own messages right-aligned
in an accent-colored bubble, no name shown since you obviously know you
sent it) with a flat, uniformly left-aligned chat log matching Mattermost:
every message shows its sender's avatar and name, dropped only for
consecutive messages from the same sender in a row (grouping logic already
existed for other people's messages; now applies uniformly regardless of
who sent it). No more per-message "mine" background color, since real
Mattermost doesn't have one either -- messages are distinguished only by
the username label, with a hover-revealed row highlight and the existing
edit affordance (still author-only) taking the place of the old bubble.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
React StrictMode double-invokes the effect that opens the chat WebSocket in
dev (mount -> cleanup -> mount again, on purpose, to catch exactly this
class of bug). The first socket gets abandoned in cleanup, but its onclose
still fires asynchronously afterward -- and unconditionally ran
`socketRef.current = null`, even after the second (real) socket had already
taken over. That silently orphaned a perfectly live connection: still open
and receiving broadcasts fine, but nothing left holding a reference to send
on, so outgoing messages/edits went nowhere with no visible error.
Found via manual testing: messages sent through the UI weren't appearing,
but a raw WebSocket opened by hand (bypassing React entirely) joined and
sent a message successfully, isolating the bug to the reconnect logic
rather than the backend.
Fix: each socket's onopen/onclose now checks it's still the one referenced
by socketRef before mutating shared state, so a stale/superseded socket's
events are inert instead of clobbering whatever socket is actually current.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Deployment artifacts for the two-server architecture from ARCHITECTURE.md
§9, grounded in verified Debian 13 (trixie) package facts (Python 3.13,
PostgreSQL 17, Node.js 20, redis-server 8.0, certbot 4.0, ufw --
confirmed rather than guessed) rather than a generic "modern Linux" guide:
deploy/systemd/chatapp.service, deploy/chatapp.env.example,
deploy/backup-postgres.sh, deploy/upgrade.sh, and DEPLOYMENT.md as the
actual numbered runbook.
Revised mid-implementation once the user clarified the app sits behind an
existing, separate Nginx Proxy Manager rather than local Nginx+certbot:
dropped the local Nginx config entirely, gunicorn now binds a TCP port
instead of a Unix socket, and app/main.py gained a static-file mount + SPA
fallback route so gunicorn alone serves the built frontend, /api, and /ws
on one port -- what lets NPM's simple one-upstream-per-domain mode work
with zero custom path routing. Path-traversal-guarded (full_path comes
straight from the URL) and cache-header-differentiated (far-future
immutable on Vite's content-hashed assets, no-cache on index.html/sw.js/
manifest so a deploy actually propagates instead of leaving clients on a
stale service worker) -- verified locally against a real gunicorn process
serving a real frontend build, not just eyeballed.
Two real gaps found and fixed alongside the docs, not just noted: gunicorn
wasn't a dependency anywhere despite being the whole app-server design, and
there was no WebSocket reconnect logic on the client -- a reverse proxy's
idle-connection timeout (NPM's or otherwise) would have silently killed a
quiet chat connection with nothing to recover it. Added exponential-backoff
reconnect to useChatSocket.ts, verified by hand (killed and restarted the
local dev backend mid-session, confirmed auto-reconnect and that a message
sends successfully afterward with no page reload).
Every command in DEPLOYMENT.md that could be verified locally, was: the
exact systemd ExecStart line run against local dev Postgres/Redis with
clean SIGTERM shutdown, the static-file serving behavior against a real
build, both shell scripts syntax-checked. What couldn't be verified from
this sandbox (actual Debian 13 hardware, Nginx Proxy Manager itself) is
flagged explicitly in the plan rather than claimed.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bot accounts (User rows with is_bot=True), scoped API tokens (read:messages,
write:messages, manage:rooms) authenticated via Authorization: Bearer on both
REST and the WS handshake, live bot WebSocket access on the same /ws/chat
endpoint humans use, message editing (WS "edit" envelope -> message_update
broadcast, fans out cross-instance for free via the existing broadcaster),
incoming webhooks (room-scoped, no auth beyond the URL token), and outgoing
webhooks/event subscriptions (HMAC-SHA256 signed, backgrounded delivery,
creation-time SSRF validation against private/loopback/link-local targets).
Token auth is additive, not a parallel system: a bearer-token-authenticated
bot goes through the exact same room-membership/role checks a session-
authenticated human does everywhere; only read:messages/write:messages are
separately scope-gated (the two message endpoints). manage:rooms scope
enforcement, full per-delivery SSRF re-validation, and bot API rate limiting
were explicitly scoped out (confirmed with the repo owner) as disproportionate
to this phase -- documented as known gaps in backend/README.md rather than
silently skipped.
Admin portal gains a Bots tab (create bots, issue/revoke scoped tokens,
cross-room webhook visibility); RoomInfoPanel gains room-scoped webhook/
subscription management, mirroring how invites already work there. The chat
UI also gets a minimal "edit your own message" affordance -- not asked for
by the issue, but the only practical way to exercise the edit pipeline by
hand instead of only via a scripted bot client.
Along the way: fixed a real bug caught while writing the incoming-webhook
test -- offline-push notification relied on the sender being "connected" to
exclude themselves, true for WS-originated messages but not for the new
webhook path, which has no WS connection for the attributed sender at all.
Now explicitly excluded. Also discovered the REST-only test fixture never
triggered ASGI lifespan, so app.state.broadcaster/presence didn't exist for
it; moved their construction out of the lifespan into create_app() itself
(Redis client construction is synchronous/lazy) so both the WS and
REST-only paths always have them.
New tests/test_bots.py, test_message_edit.py, test_webhooks.py (full suite
now 78/78, stable across repeated runs) plus a scripted end-to-end smoke
test (bot WS join/post/edit, incoming webhook, SSRF rejection, outgoing
delivery) and a full browser walkthrough of the new admin/room UI.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds is_site_admin-gated site administration: user management (list,
deactivate/reactivate, reset password, promote/demote), room management
(list all rooms including private ones, archive/unarchive, force-transfer
ownership), and an audit log of every admin action.
Backend: User.is_active (deactivation) and Room.is_archived (archive) are
new columns; AdminAuditLog is a new table matching ARCHITECTURE.md's
admin_audit_log design, written to in the same transaction as every
mutating admin action. require_site_admin (dependencies.py) gates all
/api/admin/* routes. get_current_user now rechecks is_active on every
request, so deactivating a user kills their already-open session
immediately, not just future logins. An admin can't deactivate or demote
their own account (the one self-lockout guard included). Archived rooms
drop out of the open-room browse list but stay readable for existing
members.
Frontend: new /admin route (AdminRoute guard, redirects non-admins to
/rooms) with a tabbed Users / Rooms / Audit log / Settings page, plus an
"Admin" link in the account menu for site admins.
Bot/integration management and system settings -- both listed in the
original issue -- are intentionally not here: bot management has nothing
to manage until Phase 7 builds the actual bot data model, and there's no
settings storage or concrete setting to configure yet. Settings has an
empty placeholder tab; bot management is deferred entirely to Phase 7.
Confirmed this scope cut with the repo owner before implementing.
New tests/test_admin.py (14 tests, full suite now 58/58) covers every
admin endpoint's permission gate, the self-action guards, deactivation's
immediate effect on an already-open session, and that every mutating
action produces exactly one audit log row.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Splits the WebSocket layer into three pieces so one app instance and many
behave identically: ConnectionManager stays a purely local socket registry;
RoomBroadcaster publishes chat messages to a per-room Redis channel and
every instance (including the publisher) forwards received messages to its
own local sockets via a single psubscribe("room:*") listener started in
main.py's lifespan; Presence is a Redis-backed refcounted hash per room
tracking who's connected across all instances.
Presence replaces the old process-local connected_user_ids check that
Phase 4's offline-push logic used -- without it, a user connected on a
different instance would look offline and get a redundant push. Fixing
this was scoped in beyond the issue's literal ask (message fan-out only)
since it's a real correctness gap in a phase specifically about running
more than one instance; a known limitation (no heartbeat/TTL, so a hard
crash leaks a presence increment) is documented in the README instead of
solved here.
New tests/test_broadcast.py spins up two independent app instances sharing
one Postgres + Redis to prove delivery and presence both actually cross
the Redis boundary, not just work in-process. Manually verified the same
thing against two real uvicorn processes on different ports.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Backend: PushSubscription model/migration, VAPID config + `cli.py
generate-vapid-keys`, push_service.send_push_to_user (upsert-by-endpoint
subscribe/unsubscribe, auto-cleanup of expired 404/410 subscriptions),
/api/push/* router, and ConnectionManager now tracks connected user IDs
per room so chat.py can push only to offline members after broadcasting
to online ones.
Two test-infra bugs found and fixed along the way: send_push_to_user
takes the caller's AsyncSession and is awaited inline rather than fired
via asyncio.create_task with its own session (background tasks were
outliving the test event loop); and the ws_client fixture now uses
NullPool to eliminate a connection-pool checkout race that was failing
WS tests intermittently.
Frontend: service worker rebuilt with vite-plugin-pwa's injectManifest
strategy (custom src/sw.ts) so it can add push/notificationclick
handlers alongside the existing precaching and StaleWhileRevalidate
routes ported over from generateSW. New subscribe/unsubscribe flow
(lib/push.ts, api/push.ts) with a toggle in the account menu.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds a real Workbox runtime-caching strategy on top of the Phase 1 app-shell
precache: StaleWhileRevalidate (cache-and-refresh) for the five read
endpoints (rooms/mine, open rooms, room messages, room members, invites/mine)
with a bounded/expiring cache per endpoint, while /api/auth/* and all
mutations stay network-only. An OfflineBanner (navigator.onLine-driven) and
a clearer Composer status line ("Connecting..." vs "You're offline") surface
what's actually happening; api/client.ts gains a NetworkError distinct from
ApiError so a genuine cache-miss-while-offline shows a quiet empty state
instead of a red error.
Manual offline testing (backend stopped, `vite preview` against the real
production service worker) surfaced a real gap the plan hadn't accounted
for: GET /api/auth/me is intentionally NetworkOnly, but that meant
ProtectedRoute could never confirm a session while offline and always
bounced to /login -- none of the newly-cached room/message data was ever
reachable. Fixed by caching a minimal, non-sensitive "last known user" in
localStorage (lib/lastUser.ts) and having AuthContext fall back to it for
any *unconfirmed* auth check (network failure, or a down backend answering
through a live reverse proxy with its own 502/503/504 -- both happen in
real deployments, not just literal airplane-mode). Only a server-confirmed
401 still clears it and signs the user out; every real action still
re-checks the actual session cookie server-side, so this can't grant
anything -- it only keeps cached UI reachable.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Replaces the Phase 1 placeholder UI with a single persistent app shell (top
bar + sidebar + chat pane, 860px responsive breakpoint) matching the
"PWA chat system UI" design handoff: message bubbles with consecutive-run
avatar/name grouping, auto-growing composer, room search, and the real
DarkSingularity logo (also used to regenerate the PWA icons).
The handoff didn't cover Phase 2 (private rooms, roles, invites) or
browsing/joining open rooms, so those are added using the same visual
language: a room info panel with role badges, invite-by-username with a
pending-invites list, member management (remove/promote/demote/transfer
ownership), room settings (rename/describe/delete), and separate
browse-rooms/invites-inbox modals. Unread badges, last-message preview, and
the typing indicator are deliberately deferred -- both need new backend
features (read-tracking, a WS typing event) that weren't in scope this pass.
Two small backend additions round out data the new UI needs but the API
didn't expose: MessageRead.username (historic messages had no sender name)
and InviteRead.target_username / MyInviteRead.room_name+invited_by_username
(a recipient's invite list can't otherwise resolve a room they're not in).
Both are additive; 35 backend tests still pass.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds room_invites table + migration, owner/admin/member role enforcement
(require_room_role), and endpoints for private room creation, room
management (update/delete/leave/transfer-ownership/change-role/remove-member),
and the invite lifecycle (create/list/accept/decline/revoke). Registration
stays invite-only via the CLI from Phase 1 — this is a separate, room-level
invite system for adding existing users to private rooms.
Frontend is untouched: the UI redesign is happening separately, so this phase
is backend + tests only (35 passing). Verified no regressions in the Phase 1
open-room/WebSocket flow via manual smoke test.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Invite-only FastAPI + SQLAlchemy(async) + Postgres backend (session-cookie
auth via CLI-provisioned accounts, open-room CRUD, single-instance /ws/chat)
and a React + Vite PWA frontend (login, room list, chat view). Backend tests
pass against a local Postgres DB. See README.md and backend/README.md for
setup, and ARCHITECTURE.md for the full phased design.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ksmithandClaude Sonnet 5
