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>
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>
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>
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>
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>
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>
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>
@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>
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>
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>
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>
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.
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 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>
ksmithandClaude Sonnet 5
