DEV Community: Frank Milvus

Video thumbnails without downloading the video

Frank Milvus — Sun, 18 Oct 2026 10:54:59 +0000

A video tile that only knew how to say "video"

Open the shared-media view
in GwinG and you get three tabs: Media, Files, Links. Images have
always had thumbnails there. Videos had a play triangle on
a flat background and nothing else — the same tile for a five-second hello and a
ten-minute walk-through. The only way to tell two clips apart was to open one and
wait for it to start downloading.

That is the small annoyance we fixed this week. Every video sent from now on
carries a poster: a single JPEG of its first frame, extracted on the sender's
device and stored next to the message. The media grid shows that frame under a
small play badge, so you can recognise a clip before a single byte of video
crosses the network.

The rest of this post is about the choice behind it: where the frame comes from,
why we did not ask a server to make it, and the one desktop platform that needed
a different recipe.

Two ways to get a still frame

There are exactly two honest options for a video poster, and they differ in who
does the work.

Extract on the server

The classic approach. When a video finishes uploading, a worker runs a video tool
over it, grabs frame zero, stores the result, and attaches the URL. It is robust.
It works for every video in the database, including the ones sent years before
the feature existed, because a backfill job can walk the library and generate the
missing posters.

The bill is real, though. It puts a video decoder in the API image, spends server
CPU on every upload, and requires a schema and API change anyway. For a small
team, "add a media pipeline" is a project, not a line item.

Extract on the sender's device

The alternative: the phone that is about to send the clip already has the file
and, in most cases, already has a decoded frame. Grab that frame before the
upload, encode it as a JPEG, and upload it as an ordinary image. The message then
points at both files — video and poster.

This is the familiar messenger pattern, and it has a pleasant property: the
expensive part happens once, on hardware that is already awake and already
holding the video.

Why the sender's device won

Three reasons, in the order they mattered to us.

The server could have done it, but it did not need to. Shared media is
plaintext, and encrypted chats block media entirely, so a server-side extractor
would not have run into encrypted blobs. That removed the strongest argument
for server extraction. When both paths are technically possible, the cheaper
one wins.

The code already existed. The client has extracted first frames for
pending-upload placeholders for a while — the little preview that appears in a
bubble while a video is still in flight. Reusing that path meant the new feature
was mostly plumbing: take the frame we already know how to take, upload it, and
remember the URL.

The send path already knows how to be resilient. Uploads can fail, apps can
be killed, and a retry can happen hours later. A poster produced at send time
fits the outbox model instead of fighting it.

The trade-off is stated plainly: a poster ships with the send. Videos that were
already in the database when this landed do not have one, so their tiles keep the
old play-icon placeholder. That is not a bug in the renderer; it is the shape of
the decision. The follow-up list has a server-side backfill for exactly this
reason.

How a poster travels from send to screen

Extract, convert, upload

After the video upload finishes, and before the message is delivered, the upload
pipeline extracts frame zero, copies it into a .jpg so the server's
allowed-extension check is happy, and sends it through the normal image path. The
resulting URL is written onto the outbox record for that message.

The whole step is best-effort. If extraction fails, or the poster upload fails,
the message still goes out — just without a thumbnail. A missing poster is a
cosmetic loss; a blocked message is not. That is the right failure mode for chat.

Survive a restart

The outbox is durable, and so is the poster URL. A restored send re-delivers the
same poster instead of extracting and uploading it a second time. On a retry, the
pipeline checks whether a prior attempt already produced one and skips the work.

This matters more than it sounds. Retries are the normal case on a bad
connection, not an edge case, and re-uploading a thumbnail on every attempt would
turn a cheap feature into a small denial-of-service against our own upload
endpoint.

Render the tile

In the shared-media grid, each video tile draws the poster with a scrimmed play
badge over it. The list already knows how to lay out media tiles, including the
grouped tiles used by photo albums.
No poster means the old placeholder — same layout, same tap target, no special
case in the list. The badge is the only thing that says "this
is a video"; everything else is just an image.

Because the poster is a normal image, it inherits all the boring guarantees. It
counts against upload quota, it ages out under the same TTL, and the orphan sweep
protects it like any other upload. Forwarding a video copies the poster with it,
so the tile looks right in the destination conversation too. When a group is
dissolved, the poster is deleted along with the rest of that group's media.

While we were in that view we also centered the Media / Files / Links
selector. It had been hugging the left edge on wide screens; now it centers when
it fits and still scrolls when the width is tight.

The desktop plot twist: Linux needed its own extractor

The mobile path relies on two Flutter plugins that register Android and iOS only.
On desktop they throw an "unimplemented" error, the client catches it, and the
send quietly proceeds without a poster. That catch is why the feature looked fine
on phones and simply never appeared on a Linux desktop — and why the
pending-upload placeholder and the in-bubble preview were missing there too.

The fix branches the extraction helper on the platform. On Linux it opens the
file with a media_kit player, waits for the first decoded frame, and captures
that frame as a muted JPEG screenshot. No separate video-decoding stack, no
second player implementation — just a short-lived player used as a camera.

One subtlety: this capture deliberately does not take the serialization gate
that the chat and full-screen players use. Those players call the extraction
helper while they already hold that gate, so acquiring it again would stall the
exact thing we were trying to preview. The helper reads a frame; it does not
coordinate playback state.

The pleasant side effect is that the branch lives in the shared thumbnail helper,
not in the media grid. The pending placeholder and both video players get desktop
previews at the same time, from the same change.

Old videos, Windows and macOS

Nothing changes for a video that has no poster. The renderer falls back to the
play icon, which is what those messages showed before. The honest fix for the
back catalogue is a server-side job that generates posters for existing rows, and
that is on the follow-up list, not in this release.

Windows and macOS also still show the icon. The desktop app ships media_kit
libraries for Linux only — desktop video is a Linux feature today — and neither
platform has a frame extractor wired up. Getting posters there means adding the
platform libraries and a capture path, and we would rather do that deliberately
than ship a half-tested branch.

Tests and what comes next

The change is covered on both sides of the wire. On the backend, four tests
exercise a REST send round-trip, the nullable case, the WebSocket message
payload, and a forwarded copy that must keep its poster. On the client, six tests
cover JSON round-trips for messages and outbox records, both when a poster is
present and when it is absent. The absent case is the one that protects old
messages.

The follow-ups are small but worth naming:

a server-side backfill for videos sent before this change;
Windows and macOS posters, once those platforms have the video stack to match;
using the poster in the chat bubble's loading state and in the full-screen player before the video downloads — the data is already there;
a low-quality placeholder, so the tile paints something instantly while the real poster loads.

None of these change the shape of the feature. They fill it in.

FAQ

Does every video now upload two files?

Yes — the video and a small JPEG. The poster is a normal image upload, subject to
the same quota and TTL rules as any other image. If it fails, the video is still
sent.

Why not extract frames on the server and avoid the extra upload?

We could have: the media is plaintext, so nothing blocked it. But that adds a
video decoder to the API image, spends server CPU on every upload, and still
needs schema and API changes. The client already knew how to capture a frame, so
the expensive work stays on the device that owns the video.

Why do some older videos still show a play icon?

Because posters ship with the send. A video that was uploaded before this change
has no poster stored, and the renderer deliberately falls back to the placeholder
rather than showing an empty tile. A backfill job is on the list.

— the GwinG team

Get GwinG — a language-exchange messenger with live translation.

Android: Google Play
Windows: .zip or installer
Linux: .deb or portable tarball

Search every chat and every message from the chats list

Frank Milvus — Sun, 18 Oct 2026 10:54:23 +0000

Two questions, one search box

A search box in a messenger is usually asked two different things. The first is "which chat is this?" — you half-remember a name, a nickname, or the last thing that was said. The second is harder: "where did we talk about this?" — you remember the topic, not the conversation, and the line you want is months old.

Most search boxes answer one and fake the other. In GwinG, we wanted both from the same place: the chats list. The list now has a search button at the top. Tap it and a query box slides in above the chats, replacing the brand header. The menu collapses, the floating action buttons hide, and the whole page becomes one field. The back arrow, Esc, or the system back button puts it away again.

That sounds like a small UI change. The work was in making the two questions share one result list without lying about either. If you are new to GwinG, the overview post covers the app; this piece is about the search path, and it follows the chat-surface work in the emoji, pins and grouped-bubbles write-up.

Instant filtering, then a slower second opinion

The "which chat" half is answered entirely on the device, on every keystroke. The list rows already carry what we need: a friend's name, surname, nickname and display name; a group's name; the last message preview; the draft you never sent. Pending requests match on identity fields too. None of this needs a round trip, so the list narrows as you type.

The "where did we talk about this" half cannot work that way. The message you want may be far outside the handful of rows the list has loaded, so the app also asks a server-side message search endpoint. That call is debounced by 300 ms, so a fast typist does not fire one request per letter. A sequence guard drops stale responses: if an older query resolves after a newer one, its results are ignored instead of briefly overwriting the correct list.

The two layers merge into one view. While the server is still thinking, local matches stay on screen and a spinner sits where remote results will land. When there is nothing at all, the page shows a single "No chats found" state rather than two competing empty messages.

What the server actually searches

The message search is deliberately narrow, because "search everything" is the wrong default when part of the history is encrypted.

It only looks at conversations the caller belongs to.
It skips conversations marked encrypted, and skips deleted messages.
It matches the query as a case-insensitive substring of message content.
It returns newest first, with a default cap of 50 hits.

Each hit arrives with enough context to render a row without another request: the conversation it belongs to, its title, the sender's identity, and the timestamp. A group sender is included for a practical reason — the client cannot resolve a member's display name from a message payload alone, so the server resolves it while it already has the row.

The hit payload reuses the same serializer as an ordinary message. That is a quiet but important decision: a search result carries the same reaction, reply and link-preview fields as the message does in the conversation, so the row can show what the message actually is instead of a stripped-down copy that drifts from the real thing.

Messages above chats

Results are grouped into two sections, and the order is intentional: Messages first, then Chats.

A message row shows the chat title, sender: snippet, a group badge when relevant, and the date. It is a direct answer to "where did we talk about this", so it gets the top of the page.

The Chats section is the union of two matches. A row stays when its name, nickname, last-message preview or draft matches or when any server hit belongs to that conversation. That second clause is what makes the two layers feel like one feature. A chat whose most recent message is "see you tomorrow" still appears when your query matches something from three months ago — the preview would never have surfaced it.

Opening a hit exactly where it happened

Tapping a message result does not just open the conversation. It opens it at that message.

The hit carries an initial message id into the chat screen. After the controller finishes its normal initialization, the view tries to scroll to that id. If the message is not in the first page the chat loaded, it fetches a context window around it first, then scrolls and highlights it. Most chats open pinned to the newest message; this is the one path that deliberately opens in the middle of history, and it has to work when the target is far from the bottom.

The point is not the animation but the position: you land with the matching line in view and the surrounding messages above and below, which is usually what you need to remember why you were looking.

One search box, one visible tab

The chats list has tabs, and each tab keeps its own membership. Search respects that. Both the local rows and the message hits are scoped to the tab you are looking at.

That is a deliberate constraint rather than an oversight. Merging every tab into one result list would produce hits you cannot act on without first guessing which tab owns them. Scoping keeps the mental model simple: search narrows the list in front of you. If the conversation lives in another tab, switch tabs and search there.

The same scoping rule keeps a message hit from resurrecting a chat that the current tab would otherwise hide. A hit can keep its own chat row visible, but only when that row belongs to the visible tab in the first place. The new interface strings ship in all six supported locales, so the two sections and the empty state read the same way everywhere the app does.

Escape the wildcards

The message search uses a LIKE-style substring match, and that syntax has two characters with special meaning: % matches any run of characters, and _ matches any single one. Left alone, a query like 100% or snake_case stops being a literal search and starts behaving like a pattern.

We added a small escaping step before the query reaches the database, and declared the escape character on the pattern itself:

content ILIKE :pattern ESCAPE '\'

The query's %, _ and the escape character are escaped first, so the only wildcards in the final pattern are the ones the server adds around the search term. We applied the same treatment to the existing per-conversation message search, which had the same flaw. It is a small fix with a visible payoff: searching for a literal percent sign finds the message that contains one.

What this does not do yet

Two limits are worth stating plainly.

Encrypted chats are not message-searchable. The server only ever sees ciphertext there, so it cannot match content it cannot read. Those conversations still match on identity and on their last-message preview, but they will never contribute a Messages hit. Searching the decrypted cache on the device is the eventual path; it is not in this version.

Results are capped and ranked by recency. The default cap is 50, and ordering is newest first. This is a substring search, not a tokenized full-text index, so it does not rank by relevance or understand word stems. For the common case — "I know roughly what was said, show me the recent candidates" — recency is the right default and the cheapest thing to reason about.

FAQ

Does search find messages older than the preview in the chats list?
Yes. The preview only reflects the newest message. The Messages section comes from a server search over message history, so an old line can surface a conversation whose preview says nothing about your query.

Why do encrypted chats never appear in the Messages section?
Because the server stores and serves ciphertext for those conversations. It can match the chat's identity and its encrypted preview locally, but it has no readable content to search. That is a property of the encryption model, not a missing index.

Is the search case-sensitive, and can I search for a literal %?
It is case-insensitive. % and _ are escaped before the query runs, so they are treated as ordinary characters rather than wildcards.

— the GwinG team

Get GwinG — a language-exchange messenger with live translation.

Android: Google Play
Windows: .zip or installer
Linux: .deb or portable tarball

Pin flights, a real find hotkey, and colored More tiles

Frank Milvus — Sun, 18 Oct 2026 10:53:41 +0000

Small changes you feel before you name them

Most of the work in a messenger is invisible: delivery state, encryption, reconnects, the thing that happens when the network drops halfway through a photo. Every now and then a batch of much smaller changes lands, and the app simply feels different. This is one of those batches.

Three things changed in GwinG this week. Pinning a chat or a message now has a short flight instead of a snap. The browser-standard find chord works on every search surface. And the three navigation tiles on the More tab picked up an accent color from the active theme.

None of them adds a feature you can point at in a changelog title. All of them remove a tiny moment of doubt.

A pin should move, not teleport

When you pin a chat, the list reorders immediately. That is the correct data behaviour, but it used to be a hard cut: the row you were looking at vanished from one place and appeared in another, and your eye had to find it again.

The new pin flight keeps the row legible. Before the model reorders the list, the UI snapshots the selected row's rectangle. One frame later — after the reordered list has laid out — a ghost tile flies from the old rectangle to the row's new position in 320 ms. The real row is hidden at its destination while the ghost is in the air, so there is never a double image. The ghost's avatar hero is disabled so it cannot collide with the real row's hero.

The details are where the edge cases live:

The destination may be off-screen. If the pinned section scrolled out of view, the ghost lands at the list edge — top for a pin, bottom for an unpin — and fades out. The pin still applies.
A second pin may arrive mid-flight. The old ghost is cancelled before a new one starts.
The optimistic model update may not reach the expected state. In that case the flight is skipped; the list simply reorders as before.
The same chat can be mounted in several kept-alive tab pages. The row keys are namespaced per tab, so the flight finds the exact mounted row rather than a lookalike in another tab.

Pinned messages get the same treatment in the other direction. The message bubble measures a compact source rectangle, and the pinned bar is measured one frame after it mounts. A ghost — pin icon plus the same preview text — flies from the bubble to the bar in 340 ms and fades over its last fifth, revealing the real bar underneath. A missing source rectangle or a squeezed bar (the keyboard can do that) skips the flight; the pin still applies. Unpinning deliberately does not animate.

The whole thing is behind a new Settings → Motion → Pin animation toggle. It is on by default and follows the same rule as the other motion work: it only plays at the Full motion level. Reduced or Off means the old instant reorder, which is still perfectly usable.

The entrance bug hiding in the same pass

While adding the flights we fixed a bug that had been making list entrances look wrong. The staggered entrance used a SlideTransition with an offset of 18. SlideTransition treats that number as a fraction of the child's size, not a pixel count. Rows were starting roughly eighteen times their own height below their final position. The fix was to use a Transform.translate in logical pixels, so the rows now move 18 px.

The second half of the fix was about replays. Rows are disposed when they scroll far out of view, so a keyed entrance could replay when they came back. Each row now animates only on its first build for the lifetime of the Friends view. Rows revealed by keyboard navigation still skip the entrance on purpose.

The find chord should mean find

main+F is the browser-standard find chord. On GwinG it is Alt+F by default, or Ctrl+F if you choose the alternative in Settings → Shortcuts. Until now it only worked in some places, which made it feel unreliable: a shortcut that works sometimes is worse than no shortcut, because you stop trusting it.

It now focuses the search field on every search surface:

Surface	What happens
Friends chats list	Opens the in-place search box and focuses it. Pressing F again re-focuses the field and selects the current query. Escape still closes the box.
In-chat message search	Opens the search panel and focuses its field. While the panel is open, its own handler owns F so the query can be re-focused and selected.
Search tab	Alias of the existing focus chord, and F additionally selects the current query.
Contacts	Focuses the friend filter above the list.
Create Group → Members	Focuses the friend picker; inert on the other steps.
Group info → Add members	Re-focuses the friend picker in the add-members sheet.

Two implementation details made the difference. On the chats list, the F check runs before the "the search field already has focus" early return, so the chord also works while you are typing. In the chat page, the search panel registers its own keyboard handler while it is mounted, because the chat page's shortcut scope is inactive when the panel is on top.

No new localization keys were needed. The help rows reuse the existing strings for "Search chats", "Search in chat", and "Focus the search box", so the cheat sheet stays consistent without translating the same idea twice.

Color as a signpost

The More tab has three navigation tiles: Settings, My Space, and Switch account. They were all the same default icon color. Now Settings uses the secondary color, My Space uses tertiary, and Switch account uses primary.

The palette is resolved once from the active theme, so the tiles follow light/dark mode and the user's accent preset. There is no behaviour change, no new copy, and no server sync. It is a small piece of wayfinding: three destinations, three visual anchors, one less moment of reading the labels.

FAQ

Does pinning still work if motion is disabled?

Yes. The data change is independent of the animation. With motion off, the row or message simply moves to its new place without the ghost flight.

Does `Alt+F` work while I am typing in the search box?

Yes. On the chats list the chord is checked before the focus check, and it selects the current query so you can replace it immediately.

Do the More tile colors change with the theme?

Yes. They are resolved from the active theme palette, so they follow the light/dark mode and accent preset rather than being fixed colors.

Why this batch matters

A language-exchange app is a place where people already have to work a little: find the right person, switch languages, read a translation, check a pronunciation. The interface should not add its own small uncertainties on top of that.

A pin that flies is not a feature. A find chord that works everywhere is not a feature. A colored tile is not a feature. But together they make the app feel like it is paying attention — and that is the point of polish work.

If you want the implementation-level companion to this piece, the shared media gallery and photo albums write-ups cover the same "small detail, real feel" territory.

Get GwinG — a language-exchange messenger with live translation.

Android: Google Play
Windows: .zip or installer
Linux: .deb or portable tarball

Why we renamed tonGues to GwinG — and what stayed the same

Frank Milvus — Sun, 18 Oct 2026 10:53:40 +0000

Why this post exists

GwinG is the new name of tonGues — the same language-exchange messenger, with the same accounts, conversations and encryption. The change you will notice is on the surface: the name, the wordmark, the tagline, the splash screen and the desktop builds. The change you should not notice is underneath: your sign-in, your history, your keys and the links you have already shared stay where they are.

If you are new to the project, the overview of GwinG is the right place to start. This post is about the rename itself: why the old name had to go, how we chose a new one, and the line we drew between the visible brand and the things that must never move.

The old name was already taken

The short reason for the rename is that there was already a language app using the same name. Not a similar name, not a name in the same category — the same word.

That is not a scandal, and it is not unusual for a small project. It is a practical dead end. A name is how people find you in a store search, how they recommend you in a sentence, and how they tell a friend which app to install. When two products answer to the same word, every one of those moments turns into a clarification: the right app, by the right developer, not the other one. For a project built around conversation, spending the first minute of every conversation explaining your name is a bad trade.

There was a second problem, smaller but persistent. The old tagline was a pun — “set tonGues wagging” — and a pun only works when the name is already familiar. It also depended on a spelling that is easy to fumble in a search box. Once the name had to stand on its own, the wordplay was carrying more weight than the word.

What a name has to do when it is also a handle

For an app, a name has four jobs:

Be found. Someone types it into a store search and sees the right result.
Be said. Someone recommends it out loud without spelling it.
Be typed. Someone enters it into a message without autocorrect fighting back.
Be owned. A search for it points at this project, not at a dictionary entry or a different product.

The old name was decent at being said and typed. It failed the first and fourth jobs, and those are the ones that compound. Every new user who cannot find you is a user you never hear from.

Choosing a name we could own

We wanted a coined name rather than a borrowed one. GwinG is not a dictionary word. It is five letters with a capital at each end, and that shape is the whole design: two bookends around a short, plain middle.

A coined name does something a common noun cannot — it makes the search result unambiguous. It also gives the wordmark a natural structure. The two Gs are the edges, so they can carry the strongest colour, while the middle can recede.

We kept the name short enough to sit in an app bar without shrinking, and distinct enough to be a handle. That last point mattered more than elegance. A name you have to qualify is a name that never quite becomes yours.

The wordmark: red at the edges, amber at the centre

The wordmark was rebuilt around that shape. Both Gs are accented, and every letter is coloured by its distance to the nearest accent. The two Gs sit at the ends, so they take the red end of the palette. The win between them blends through orange and lands on amber at the centre.

That is the rule in one sentence: red at the accented edges, amber at the centre. It reads as one word rather than two initials, and it uses the palette the app already had — the same red and amber, not a new set of colours bolted on for the occasion.

The change is deliberately local to the wordmark widget. Strings with a single capital still render the way they did before, so the same component keeps working on screens that are not the login page. In practice you see it on the login screen, the friends header, the More tab and the in-app splash — the places where the app says its own name.

The tagline: where languages meet

The old tagline had to go with the old name, because the joke lived inside the word. The new one is where languages meet.

It is shorter, it does not depend on a pun, and it describes the product without naming a language or a direction. Two people can meet in the middle; neither has to switch to the other's language to start. That is the idea the app is built around, and the tagline now says it in four words.

It is localized alongside the rest of the interface — German, Spanish, French, Korean and Russian, with English as the source — so the line is not an English-only slogan pasted onto a translated app.

A new splash with the same flame

The splash image was redrawn with the new wordmark, keeping the flame, the palette and the bold monospace styling. The native splash assets were regenerated for Android, iOS and web, so the first frame of the app matches the in-app splash instead of showing the old name for a beat.

The launcher icon is intentionally unchanged. It is a textless flame, and it never depended on the name. A new icon is a separate design decision, not something to smuggle into a rename at the last minute. The tool that generates the splash was also updated, so regenerating the assets reproduces the new wordmark instead of quietly restoring the old one.

Desktop builds get a new name

The desktop builds were renamed from tongues to gwing. The binary, the packaged artifacts, the window title and the installer display name now say GwinG. In day-to-day use that means a gwing binary, gwing packages, and a GwinG entry in the launcher instead of the old one.

Upgrades were the part that needed care. The installers clean up the old executable and shortcuts, and the Linux package declares that it replaces the old one instead of sitting beside it. The previous tongues-* downloads remain available for one release cycle, so nobody is stranded mid-upgrade.

The important detail is invisible: the desktop storage identity was left exactly as it was. The executable changed; the data it opens did not. That is what keeps preferences, the secure store and the encryption identity intact across an upgrade.

What did not change

This is the list we wrote down before touching anything:

Accounts and sessions. Your account is the same account. There is no sign-out, no re-link and no migration step. If you use saved accounts, they are still saved — the account-switching write-up explains how that isolation works.
Package identity. The installed app and the store listing are the same product. Updates arrive as updates, not as a second app with a new identity.
Encrypted chats. Encryption was not touched. The encryption identity and keys stay the same, so existing encrypted history remains readable.
Deep links. The tongue:// scheme is unchanged, so links already shared in chats, notes or bookmarks keep resolving.
Notification channels. The identifiers are unchanged; only the display names now say GwinG. Per-channel sound, vibration and mute settings survive.
Local data. Theme choice, saved accounts, cached media and local history keep their storage keys, so an upgrade does not orphan them.
Article URLs. Existing posts keep their slugs and canonical addresses. Bookmarks and inbound links do not break.
Historical records. Old changelogs and plans still say tonGues. They are records of what was true then, and rewriting them would make the history less accurate, not more.

The pattern is simple: the name is allowed to change; the identity is not. A rebrand that quietly changes identity is not a rebrand. It is a new app wearing an old name, and users pay for it with a sign-in screen and a missing history.

FAQ

Is GwinG a different app from tonGues?
No. It is the same app under a new visible name. Your account, friends, conversations and media are the ones you already had.

Will I have to sign in again or lose my encrypted history?
No. The rename does not touch accounts, credentials or the encryption identity. On desktop, the storage identity was kept specifically so an upgrade finds the same preferences, secure store and keys.

Do old links and notification settings still work?
Yes. The deep-link scheme is unchanged, so previously shared links keep resolving. Notification channel identifiers are unchanged too, so per-channel settings survive; only the display names now say GwinG.

The test we cared about

A rename is easy to make loud and hard to make safe. The visible parts — the wordmark, the tagline, the splash, the desktop artifacts — are the parts people will notice. The invisible parts are the ones that decide whether the change feels like an update or like a reset.

Our test was simple: if you had a saved account, a shared link, a muted channel and an encrypted conversation from before the rename, all four should still be there afterwards. The name changed. Everything that makes the app yours did not.

— the GwinG team

Get GwinG — a language-exchange messenger with live translation.

Android: Google Play
Windows: .zip or installer
Linux: .deb or portable tarball

Fast account switching in Flutter without a sign-in round trip

Frank Milvus — Sat, 17 Oct 2026 13:45:51 +0000

Most messenger accounts are single-account by design: you sign in, the session
lives in one token slot, and every local cache is global. That works until a
real user needs two accounts on the same device — a personal profile and a
work one, or two language-learning identities.

In GwinG, a Flutter language-exchange messenger, we added saved
accounts: the app remembers up to five accounts and switches between them in
one tap, without a browser or a Google round trip. The interesting part was not
the picker. It was making "switch account" safe — the new session has to start
clean, and none of the previous account's data may leak into it.

This post covers the UX we landed on, the session lifecycle, and the isolation
patterns that made fast switching reliable.

What the user sees

Saved accounts are listed on the login screen above the sign-in button, and in
an account switcher reachable from three places:

long-press the profile avatar in the navbar (right-click on desktop);
Alt+0 (Ctrl+0 if the user chose Ctrl as the main modifier);
More → Switch account, next to Log out.

The switcher can switch to a saved account, add another one, remove a single
account, or sign out of everything. After a successful switch the app opens a
fresh home shell. That detail matters: the tab pages live in an IndexedStack,
so reusing the shell would keep the previous account's friends, chats and
search results mounted — and visible for a frame. Rebuilding the shell disposes
them instead.

Up to five accounts are remembered, most-recently-used first. Adding a sixth
evicts the least recently used account that is not the one being activated, and
removes its local data.

Validate before you tear down

The tempting implementation is: read the target's token, drop the current
session, then validate. It is also the one that hurts users. A dropped Wi-Fi
connection at the wrong moment leaves them signed out of both accounts.

The rule we use is the reverse: validate the target completely, then teardown,
then publish.

saved account tapped
        │
        ├─ access token still valid? ──no──► refresh the session
        │                                      │
        │                                      └─ rejected? → remove entry, show error
        ▼
  confirm the identity with the backend
        │
        ├─ network failure → keep the current session untouched
        └─ valid            → tear down → publish → reconnect

A network failure leaves the user exactly where they were. Only a definitive
rejection removes the saved entry and asks for a fresh sign-in.

The teardown itself is deliberately boring: end any active call, stop presence
polling, dispose the WebSocket, cancel background prefetchers, reset cached
encryption identity state, then clear in-memory tokens and notifiers. The
target's persisted data is not deleted by a switch.

One session at a time

Two switches interleaving is a surprisingly easy bug to ship. We learned the
hard way that a "switch in progress" flag must be claimed before the first
network await, not after validation. Validation can take several round trips;
a second tap during that window otherwise passes the guard too.

We also stamp each session with an epoch. Late async work compares its captured
epoch with the current one and drops the result if the session moved on. That
covers the usual suspects — a profile fetch that finishes after a switch, a
token refresh that belongs to the previous account, a background cache refresh
that was already in flight.

There is a second half to the token-refresh case: the rotated token still
belongs to the account that requested it. We read the account id from the
refresh token itself and persist the result in that account's slot, never in
"whichever account is active now." A request that started under account A may
finish under account B, but it must not write into B.

Scoping on-device data by account

This is where most of the work lives. A messenger accumulates a lot of local
state: messages, translations, pinned messages, chat tabs, drafts, encryption
keys, the upload outbox, friends. If any of it is keyed globally, the second
account sees the first account's data.

Every store now includes the account id in its key or path:

Store	Scoped form
Message cache	one database per account
Translations / transcriptions	key suffix per account
Pinned messages	account + conversation
Conversation freshness markers	account + conversation
Chat tabs	account
Encryption keys	account prefix
Drafts and upload outbox	already per account

The fallback segment is _shared, used only before a session exists. In normal
use there is always an account.

Encryption keys are the critical case. Sharing an identity between accounts
would present the same encryption identity to peers for two different users and
corrupt ratchet state on both sides. The cached identity is dropped on a switch,
and the next key operation reloads the target account's keys.

Keeping async work on its account

Keying the stores by account is necessary but not sufficient. The subtle bug is
when the account is resolved. A cache write often happens after network
awaits:

final account = AccountScope.segment;
final fetched = await api.fetchMessages(conversationId);
if (AccountScope.segment != account) return; // the session moved on
await MessageCacheService.save(conversationId, fetched, segment: account);

Three details make this reliable:

The account is captured once, before the first await.
The result is dropped if the active account changed in the meantime.
The cache API accepts the captured segment instead of re-reading the global state at write time.

For encryption operations we go one step further and freeze the account for the
whole operation, across every nested await. Dart zones are a neat fit: the
operation runs in a child zone that carries the account, and key-store reads and
writes resolve that captured value instead of the live session.

static Future<T> capture<T>(Future<T> Function() body) {
  final captured = segment;
  return runZoned(body, zoneValues: {_operation: captured});
}

static String get segment =>
    (Zone.current[_operation] as String?) ?? _userId ?? '_shared';

This is the difference between "the key store is usually scoped" and "an
encrypt that started before a switch can never write into the next account."

Migrating the single-account past

Existing installs had exactly one session: un-prefixed tokens, one message
database, one encryption identity, one tab layout. Updating must not log those
users out or orphan their encrypted history.

The migration runs only when the app has proven which user the legacy session
belongs to. It copies the tokens into that user's scoped slots, moves the
encryption keys and message cache into the same namespace, and then deletes the
legacy copies.

The important safety rule: a legacy layout is never claimed by "whichever
account loads first." If the old session cannot be restored at launch and the
user signs in manually, the app still migrates the legacy data to its real
owner and clears the old token slots — so a later launch can never silently
restore the wrong identity.

Three bugs a review pass caught

The tests were green and the analyzer was clean, but a behavioural review still
found three isolation defects worth sharing:

A partial secure-store read looked like a complete session. One token key was present and the other was not, so the read path skipped the fallback and returned a session with no refresh token. Fix: complete only the missing half from the fallback, and add a test for the mixed state.
Cache writes resolved the account at completion time. A prefetch that started under account A could finish after a switch and write into account B's database. Fix: capture the account at the start and pass it through.
A legacy layout was claimed by the first account to load. That exposed the previous user's tab names and chosen contacts. Fix: migrate legacy data only on the proven legacy path.

None of these are compiler errors. They are the class of bug that only shows up
when a real user switches accounts at an awkward moment.

Lessons

Validate the destination before ending the current session. Users forgive a slow switch; they do not forgive being signed out of both accounts.
Capture ambient state at the start of async work. "Current account" is ambient state, and it can change under you.
Make the account an explicit parameter at the storage boundary. It turns a silent cross-account write into a compile-time argument.
Treat legacy data as owned by a proven user. Never let a random first load claim it.
Test the mixed and interrupted states, not just the happy path: partial storage, a switch mid-fetch, a switch while a key operation is running.

FAQ

Does this work on desktop?
Yes. Long-press or right-click the avatar, or press Alt+0. The same switcher
is available from the More tab.

Do inactive accounts receive notifications?
No. Push notifications follow the active account on that device. Switching back
restores its session and its pending sends.

What happens to local data when I log out?
A plain log-out removes the current account's tokens and its entry from the
picker, but keeps its namespaced local data so signing back in later restores the
encrypted history. Removing an account, or signing out of all accounts, deletes
that account's local data as well.

How long does a saved account stay usable?
As long as its refresh session is valid. If it expires, the picker asks you to
sign in again for that account instead of failing silently.

Why only five accounts?
It covers the realistic shared-device and personal/work cases while keeping the
picker and the local storage footprint small. The limit is a constant, not a
backend restriction.

Get GwinG — a language-exchange messenger with live translation.

Android: Google Play
Windows: .zip or installer
Linux: .deb or portable tarball

Inline emoji shortcodes, private pins, and grouped bubbles

Frank Milvus — Fri, 16 Oct 2026 13:16:09 +0000

This week in GwinG, a Flutter chat app for language exchange backed by a
FastAPI + PostgreSQL server, we shipped a batch of chat work: an inline
:shortcode emoji autocomplete in the composer, a per-user "pin for me"
that sits alongside the existing conversation-wide pin, and sender grouping
for message bubbles so a burst of messages from one person reads as a block.

We also ran a behavioural review pass over the whole batch before shipping it.
That pass is the interesting part: the tests were green and the analyzer was
clean, yet it caught three defects that would have shipped silently. I'll show
those at the end, because they're the reason we do the pass at all.

Inline emoji shortcodes: `:joy` → 😂

People type :joy, :thumbsup, :tada — the aliases that grew up around chat
apps — not the formal Unicode names. So the composer now watches the token under
the caret and offers matching emoji in a horizontal strip just above the input.
Tap a cell, or press Enter, and the token is replaced with the glyph.

The table is GitHub's gemoji set — 1,913 aliases — bundled as a JSON asset
so matching works offline. That's deliberate: the familiar shorthand (joy,
thumbsup, tada) simply isn't in Unicode's own names, so a pure CLDR-prefix
lookup would miss exactly the shortcodes people reach for.

A token scanner that stays out of the way

The hard part of inline autocomplete is not the lookup — it's deciding when
there is a token at all. A scanner that fires too eagerly pops the strip while
you type a URL or a clock time. The rule set we settled on is deliberately
conservative:

the caret must be collapsed — a range selection has no single token;
the token is : followed by at least one shortcode character before the caret, so a bare : or a trailing space ends it;
the : must start the text or follow whitespace, which is what keeps https://… and 10:30 from ever triggering;
the run stops at the first non-shortcode character (a–z, 0–9, _, +, -), so :+1, :-1 and :t-rex all survive.

Scanning backwards from the caret over ASCII-only characters has a nice side
effect: the scan can never land in the middle of a surrogate pair, so multi-unit
emoji in the text around the caret can't produce a bad slice.

Ranking so `:joy` beats `:joy_cat`

A plain "everything that starts with the query" list buries the obvious answer.
Ranking runs in three tiers, and each later tier only fills space the earlier
ones left:

// 1. exact shortcode first  →  :joy gives 😂 before anything else
final exact = shortcodes[query];
if (exact != null) add(exact);

// 2. then shortcode prefixes, shortest first
//    :smi → :smile before :smiley_cat
prefixes.sort((a, b) {
  final byLength = a.length.compareTo(b.length);
  return byLength != 0 ? byLength : a.compareTo(b);
});

// 3. finally gemoji tags, purely to widen recall
//    :happy, :workout — never ahead of a real shortcode

That third tier is what makes :happy find 😀 even though happy isn't an
alias — tags are discovery-only and never outrank a real shortcode. Emoji are
de-duplicated across all three tiers, and a query longer than 32 characters is
dropped so a runaway :-run costs nothing.

Accepting a suggestion replaces exactly the typed range with the glyph plus a
trailing space, and puts the caret after it — the same manual-insert path the
emoji picker uses, which is why setting the text can't re-trigger the strip and
loop.

Private pins, next to conversation-wide pins

GwinG already had one pin per conversation — the banner at the top of the
chat that everyone sees. The new twist is a second, private pin that only
you see, synced across your own devices. The two coexist on the same message.

The data model

Both live in one join table, distinguished by a nullable user_id:

Column	Meaning
`conversation_id`, `message_id`	which message is pinned
`pinned_by`	who cast the pin
`user_id`	`NULL` = pin "for all"; a user id = that user's private pin

Two partial unique indexes keep it honest — one "for all" pin per message,
and one private pin per user per message:

-- one shared pin, and one private pin per user, for a given message
UNIQUE (conversation_id, message_id) WHERE user_id IS NULL;
UNIQUE (conversation_id, message_id, user_id) WHERE user_id IS NOT NULL;

One service, three delivery paths

Pins can arrive over the WebSocket, over REST, or be torn down when the message
itself is deleted. Rather than let three code paths re-implement the rules —
membership, who may pin for everyone, whether the message is deleted — they all
delegate to a single pin_message / unpin_message service. The rules themselves
are small but they matter:

"For all" in a group is admin/owner only, and announces itself with a system row ("X pinned a message"). In a 1:1 chat both members may do it.
"For me" is open to any member — even a non-admin in a group — and it never emits a system row or notifies anyone. The event is echoed only to the actor's own devices.
Unpinning one scope leaves the other intact, so the client tracks the two flags separately (pinnedForAll / pinnedForMe) and OR-merges them on every update instead of clobbering.

The scope field defaults to "all", so a client that predates the feature
keeps working unchanged.

Grouped bubbles: one burst, one block

When the same person sends several messages in a row, they shouldn't look like
several separate conversations. Sender grouping squares the corners that touch a
neighbour and keeps the outer corners rounded, so a run reads as a single block.

The subtlety is that we compute two different things and they must not be
conflated:

a gap/name group — tight spacing and no repeated sender label;
a corner run — which corners get squared.

// The rectangle's sender-side corners follow the group position:
// first keeps its top, last keeps its bottom, a middle bubble squares both.
final radius = groupedMessageBubbleRadius(
  base,
  isMe: isMe,
  isFirstInGroup: !glueAbove,
  isLastInGroup: !glueBelow,
);

A corner run breaks on a sender change, a day rollover, a system chip, or a
photo-album grid — the grid always keeps its own fully-rounded shape and
never joins a run. Keeping the two notions separate is what lets a shortcode
strip, a date separator and an album all sit in the run without producing
mismatched seams.

The defects a green build didn't catch

Before shipping the batch we run a behavioural review: read the diff end to end,
trace each event and field across the client/server boundary, and hand-verify
every candidate. The compiler and the unit tests were already happy, and it
still found three real bugs.

1. A pinned encrypted message previewed as ciphertext. The message_pinned
broadcast was hand-built in two places — the WebSocket handler and the REST
route — and both forgot the is_encrypted field that the canonical serializer
emits and the client reads. In an encrypted chat that meant the pin banner
showed the raw ciphertext instead of "🔒 Encrypted message". The fix wasn't to
add the field twice; it was to delete the duplication and build the payload in
one shared function so the two paths can't drift again.

2. A half-glued bubble seam. The grouping code decided "is this neighbour an
album?" from albumId != null, but an album is only rendered as a grid when
its run is longer than one message. A lone album row — its siblings outside the
loaded window — painted as an ordinary bubble while the glue logic still refused
to join it, so one side squared a corner and the neighbour stayed rounded: a
visible notch. The fix makes the glue consult the rendered album, not the raw
field, with a test that fails against the old behaviour.

3. A floating button covering the last row. The list reserved bottom padding
for its FAB stack sized against a 40dp mini button. But a mini floating
action button lays out at 48dp on mobile — the 40dp circle sits inside
Material's 48dp minimum tap target. On an admin account the extra 24dp pushed the
topmost button over the last row's timestamp. The fix derives the clearance from
the real box.

None of these threw an exception. All three built, ran, passed CI, and did the
wrong thing. That's the whole argument for reviewing behaviour, not just results.

Why write it up

Each of these is small on its own. Together they're the difference between a chat
app that works and one that feels considered — the shortcode that completes
before you finish typing, the pin that's yours alone, the burst of messages that
reads as one thought. We write them up as we ship them so the polish gets its
share of the credit.

FAQ

Does emoji shortcode autocomplete work offline?
Yes. The shortcode table ships as a bundled asset and is loaded once, so matching
never needs the network. If the asset ever fails to load, autocomplete simply
stays inert rather than breaking the composer.

Can one message be pinned both privately and for everyone?
Yes. They're independent records in the same table, and the client keeps two
flags per message so unpinning one leaves the other in place.

Who can pin a message for the whole group?
Admins and the owner. Any member — admin or not — can always pin privately for
themselves.

How is offset handling safe with emoji in the text?
The token scanner only walks back over ASCII shortcode characters, so it stops at
the first non-ASCII unit and can never split a surrogate pair. Caret offsets and
String.length are both in UTF-16 units in Flutter, so the replacement range is
always valid.

— the GwinG team

Get GwinG — a language-exchange messenger with live translation.

Android: Google Play
Windows: .zip or installer
Linux: .deb or portable tarball

Building photo albums in Flutter

Frank Milvus — Tue, 13 Oct 2026 13:58:55 +0000

Multi-select a handful of photos in GwinG and they land as a single grid
bubble — one caption, one timestamp, one tick, one notification — instead of a
full-size bubble per image. That's the album bubble, and it's the feature we
shipped this week on top of a messenger that, until now, was built entirely around
one image per message.

The interesting part was never the grid. It was doing this without tearing up
the invariant the whole codebase leans on: one message row = one media item. The
rest of this post is how we layered Flutter photo albums on top of that rule
instead of around it.

GwinG is a language-exchange messenger — chat, calls and live translation,
Flutter on the client, FastAPI and PostgreSQL behind it. If you're new here, start
with the overview of GwinG.
This post is one of a few we're writing today, alongside the
shared media gallery
and the Linux desktop video work.

One row per media item — the rule we refused to break

Here's the constraint, stated plainly. Our messages table is one row per piece
of media. That single fact is load-bearing across the app:

Delivery reconcile is URL-based. When the upload pipeline finishes, the client matches the optimistic bubble to the real row by the uploaded file's URL — one file, one row, one match.
Read receipts and reactions are per row. A thumb, a "read" tick, a count — all column-level facts on a message.
The offline outbox is one durable record per file. Every attachment gets its own record with its own progress and retry, so a killed app can resume each file independently.
Orphan cleanup scans image_url per row. A row that never got its URL is an orphan; the sweep already knows how to find it.

A naive album feature — "add an attachments table" or "stuff a JSON array of
URLs into one message" — breaks all four at once. Every read path (history,
search, pins, previews) would need rewriting, and the URL-based reconcile would
stop matching because one row would now carry N URLs.

So we didn't do that. We kept one row per media item and layered a group key on
top of it.

Why Flutter photo albums need a group key

Three nullable columns on messages turn N independent rows into one logical
album:

ALTER TABLE messages ADD COLUMN album_id    TEXT    NULL;
ALTER TABLE messages ADD COLUMN album_index INTEGER NULL;
ALTER TABLE messages ADD COLUMN album_size  INTEGER NULL;
CREATE INDEX ix_messages_album_id ON messages (album_id);

The additive-column
shape matters: it's three plain columns and an index, not a new entity.

album_id (indexed TEXT) is the shared group key. The client generates it at send time — a UUID-ish token — so an offline or still-uploading album is already grouped before any server round-trip. Its length is bounded on the server so a client can't stuff the indexed column with unbounded text.
album_index (INTEGER, 0-based) is the only ordering authority inside a group. This one matters more than it sounds. Sibling rows upload concurrently, so their created_at timestamps can arrive out of order. If any code ever sorted a group by time, the grid would shuffle. It doesn't — it sorts by album_index, full stop.
album_size (INTEGER) is the total tile count, duplicated onto every sibling on purpose. Denormalizing it means the +N overlay and the notification label render before the last sibling has uploaded, without a COUNT(*) on the hot path.

Because the columns are nullable and additive, the migration is safe to deploy
ahead of the client — and the part we care about most is that album_id IS NULL
renders exactly like before. Old rows, old clients, no regressions.

The anchor row

An album needs somewhere to hang the things that only make sense once per group.
We call that row the anchor, and it's simply the sibling with the lowest index
(album_index == 0):

it carries the caption (every other sibling stores an empty content);
it carries the reply target, and therefore the quote preview and the "forwarded" flag;
it owns the footer surface — time, ticks, read count — and the reaction surface;
it's the row that fires the notification.

Siblings are collapsed: no caption, no reply, no footer, no separate push. The
server enforces the shape on send — album_size within range,
0 <= album_index < album_size, media present, and album_id rejected on a row
with no image — so a client can't post a half-formed group.

Grouping Flutter photo albums on the client

Grouping happens on the reader's device, in the same pass that builds the message
list's display items. The rule is deliberately narrow: consecutive rows that
share an album_id, from the same sender, with no date separator or system
chip between them, collapse into one album item. Break the run — a different
sender replies, a day boundary lands — and you get two albums, which is correct.

Inside the item, the tiles are ordered by album_index and never by time:

siblings
  ..sort((a, b) => (a.albumIndex ?? 0).compareTo(b.albumIndex ?? 0));

That's the whole trick. There's no album table, no join, no second read path. The
list already built display groups for date separators and sender-name bands; an
album is just one more kind of group, and it counts as a single visual unit
for the gap logic between messages.

A grid that's sized on the first frame

The premium feel of an album lives or dies on one thing: the grid must be
exactly the right size before the images load. Get that wrong and the whole
conversation jumps as tiles pop in.

We avoid the jump by sizing from data we already store. Every image row keeps its
image_width and image_height from the moment of upload, and the album block's
aspect ratio comes from the anchor's own dimensions (clamped so an extreme
panorama can't produce a degenerate grid). Each tile uses BoxFit.cover, so it
fills its cell whatever its native ratio — the same
layout model Flutter applies everywhere
else. Sender and recipient both get the final layout on frame one; the images
just fill in.

The layout is nothing more than a lookup from tile count:

Count	Layout
1	single full bubble — the existing path, unchanged
2	two equal columns
3	one large tile left, two stacked right
4	2×2
5	two on top, three on the bottom
6	3×2
7–9	three columns; the last row is left-aligned
10+	capped at ten, with a frosted `+N` pill over the last tile

Two small details make it feel finished. Tiles cascade in with a short
per-index fade-and-slide — and that stagger is gated on the app's motion setting,
so it's simply zero when the user has reduced motion on. And the whole grid sits
inside one shared media border, so only the outer corners are rounded and
accent-bordered; the interior seams are a hairline 2 px.

Open one tile and you land in the swipe-through gallery at exactly that photo.
That gallery is its own story — we wrote it up in the
shared media gallery post
— and albums just hand it an entry point and a starting tile.

One notification, one preview, one progress bar

An album is one logical message, so it should behave like one to the person
receiving it — and this is where the fan-out bugs live.

Notifications. Exactly one push per album, fired from the anchor. A ten-photo
album must not buzz ten times. The broadcast layer treats a sibling (any row with
album_index > 0) as suppressed: it still emits the message event so the tile
renders and gets its delivered tick, but it skips the push and the
conversation-list preview entirely. The body is the same everywhere — 📷 N photos
— whether it's the push, the in-app notification list, or the friend-list preview.

Uploading. The send path is still per-file, which is what gives us per-tile
progress, retry and cancel for free. For an album we generate one album_id, then
loop the staged files, putting the caption and reply on the anchor only:

final albumId = newAlbumId();
final albumSize = staged.length;
for (var i = 0; i < albumSize; i++) {
  final isAnchor = i == 0;
  beginPendingUpload(
    filePath: staged[i].path,
    kind: UploadKind.image,
    content: isAnchor ? text : '',        // caption lives on the anchor
    replyToId: isAnchor ? replyId : null, // so does the reply
    albumId: albumId,
    albumIndex: i,
    albumSize: albumSize,
  );
}

On screen that becomes one thin aggregate bar across the bottom of the grid,
plus a small spinner on each tile still in flight. A tile whose upload fails gets
its own retry badge instead of spinning forever. Each tile is its own durable
outbox record — the same "this must survive a session ending" instinct behind our
Linux keyring session work
— so killing the app mid-send restores the album, grouped, and resumes the tiles
that hadn't landed.

Forward keeps the group; delete takes it apart

Two actions are worth calling out because albums change their meaning.

Forward copies album_id, album_index and album_size onto every copy, so
the album re-groups in the destination. Forward ten photos and the other
conversation gets an album, not ten loose images.

Delete on an album removes all siblings. And there's a tidy edge case on
the other side: if an album ever drops to a single surviving row — siblings
deleted one by one, say — that row clears its album_id and degrades back to a
plain single image. The group key is optional, so the model simply falls back to
the behaviour it had before albums existed.

What we'd do next

This phase is deliberately images-only. The model doesn't need to change to
add video tiles — album_index is media-agnostic — so mixed photo-and-video
albums are a clean later step: a per-tile player, a play badge, and the chunked
upload path video already has. The
Linux desktop video pipeline
is a good look at the machinery that would slot in. Encrypted chats stay as they
are: media is already blocked there, so albums inherit the same guard and the same
friendly message.

The takeaway, if there is one: a big feature doesn't have to mean a big schema. We
added three nullable columns, one convention (the anchor), and a client-side
grouping rule — and kept the invariants that make delivery, receipts, reactions
and cleanup work. The grid is the visible part. The three columns are the whole
trick.

FAQ

Do albums need a separate API endpoint?
No. An album is just a normal send with album_id, album_index and album_size
attached to each row. The same REST and WebSocket send paths handle it, and the
same broadcast fans it out. There's nothing album-specific to route.

How are album tiles ordered if the uploads finish out of order?
By album_index, always. Sibling rows upload concurrently and can land with
timestamps in any order, which is exactly why we forbid created_at from ordering
a group. The index is the only authority.

What happens if an album loses a sibling?
The group stays a group while any sibling remains — a failed tile shows a retry
badge rather than a hole. If the album drops all the way to one row, that row
clears its album_id and renders as a normal single image.

Does this work in encrypted chats?
Not yet. Media is already disabled in encrypted chats, so albums inherit the same
restriction and the same user-facing message. When photo and video sending arrives
there, albums will come along for free.

— the GwinG team

Get GwinG — a language-exchange messenger with live translation.

Android: Google Play
Windows: .zip or installer
Linux: .deb or portable tarball

Staying signed in on Linux when the keyring doesn't survive a reboot

Frank Milvus — Tue, 13 Oct 2026 13:45:43 +0000

We keep people signed in on desktop the same way we do on mobile: the session is
an access/refresh token pair, and we would much rather store it in the operating
system's secure store than in a plaintext file. On Linux that secure store is the
keyring — libsecret talking to the Secret Service that gnome-keyring
implements. Getting Flutter Linux secure storage to behave on every machine
turned out to be harder than the plugin's tidy write/read API suggests. The
last bug we fixed was the most interesting one: a keyring that kept its promise
for exactly as long as the machine stayed switched on.

This is the story of that bug, why the "obvious" proofs that a keyring works were
all wrong, and the small piece of Linux kernel state that finally made the check
honest.

The setup: Flutter Linux secure storage and a proof-gated fallback

On desktop, GwinG persists the session through flutter_secure_storage. On
Android and iOS that is the OS keystore, which is always present. On desktop it
is the OS keyring — libsecret / gnome-keyring on Linux, Credential Manager on
Windows — and a keyring is a much less certain thing. It can be missing, locked,
or reachable only from inside a graphical session.

The plugin makes this worse in a quiet way:
flutter_secure_storage can
accept a write and keep nothing. No exception, no error — the call returns
normally and the value is simply not there later. A store backed by a transient
collection returns the value immediately and drops it when the process exits.

So we do two things:

We write the tokens to the secure store.
Until that store proves it is durable, we also keep a plaintext copy in SharedPreferences, so the session is always restorable.

The moment the store is proved durable, we delete the plaintext copy, and the
keyring becomes the only place the session lives. That "proved durable" step is
the whole game, and it is where both of this year's desktop session bugs came
from.

The fallback is proof-gated, not permanent

A plaintext fallback that never goes away would be the simplest, safest thing for
the session — and we rejected it. It would leave a refresh token unencrypted on
every machine, including the many whose keyring works perfectly. That is the
wrong default.

Instead the fallback is proof-gated. We trust the secure store only after we
have evidence that it actually keeps values across launches, and until then we
keep the encrypted copy alongside the plaintext one. The evidence is deliberately
not a same-process write→read round-trip, which as we said can succeed against
a store that never persists. The proof is a value written on one launch and read
back on the next one:

// A value written now and compared on the next launch is the only proof that
// outlives the process that wrote it. A same-process round-trip proves nothing:
// a transient collection passes it and loses the value anyway.
final proofMatches = expected != null && seen == expected;

If the value we wrote last launch is still there this launch, the store kept
something across a restart, and we can trust it. That was the design after our
first desktop bug, and it fixed the "login screen on every launch" report. Then
came Linux.

The bug: a keyring that only lives for the running session

A user on niri/Arch had gnome-keyring installed and running — it owns
org.freedesktop.secrets, via
D-Bus activation
— but its default collection was never unlocked at login, because niri starts the
daemon outside any PAM unlock.

The daemon accepted a write and returned it on the next read within the same
session. So our one-launch proof matched. The store looked durable. We deleted
the plaintext fallback.

But the value only ever lived inside the running daemon. After a reboot it was
gone — and so was the session, because we had already thrown away the only copy
that would have survived. The fallback had protected the user right up until the
keyring "passed the test", and then stopped.

The diagnostics on that machine told the story plainly: the app's keyring entry
held an empty secret, the real tokens sat in the plaintext file with the
marker recording that the last durable save went to prefs, and the proof value
in prefs matched the proof value in the keyring. Everything agreed that the store
was fine. The machine simply disagreed at the next boot.

Why the one-launch proof was wrong

Our proof answered the question "did this value survive the process that wrote
it?" That is the right question for a store that can drop data when an app exits.
It is the wrong question on Linux, where a keyring can drop data when the
session exits — a different, later, more destructive event.

An app restart and a reboot are not the same boundary. On a machine whose keyring
caches writes in memory, an app restart inside one boot proves nothing about the
reboot that follows it.

The fix: make the proof cross a boot

The fix is small and, in hindsight, obvious: the proof record now carries the
kernel boot id.

Linux exposes a fresh, random identifier for the running boot at
/proc/sys/kernel/random/boot_id. It changes on every boot. So we write the proof
as "<bootId>:<nonce>" — the boot the value was written in, plus a nonce that
makes it unique — and we trust the store only when a proof written in one boot is
read back in a later boot:

final bootId = await _linuxBootId();          // null off Linux, or unreadable
final proofMatches = expected != null && seen == expected;

// `expected` is "<bootId>:<nonce>". A record with no separator is a legacy
// value, which can never prove a reboot was survived.
final expectedBootId = _proofBootId(expected);
final crossedBoot =
    bootId != null && expectedBootId != null && expectedBootId != bootId;

_keystoreTrusted = proofMatches && (!isLinuxDesktop || crossedBoot);

A keyring that merely caches for the running session can never satisfy
crossedBoot: the proof it holds was written in the current boot, so the store
never reaches the durable state. The plaintext fallback stays, and the session
survives the reboot. A keyring that genuinely persists reaches durable exactly
one reboot after sign-in, then becomes the sole copy, as designed.

Two details matter here:

Legacy records can never pass. A proof written by the old build has no : separator, so _proofBootId returns null and crossedBoot is false. An upgrade cannot falsely trust a store; the next launch simply replaces the record with the boot-id format.
The check is scoped to Linux. Off Linux the platform keystore (Android/iOS Keystore, Windows Credential Manager) is reliable, so the boot-id requirement is disabled and a matching proof is enough — unchanged behaviour. We added isLinuxDesktop to platform_support.dart precisely to keep this to the one flaky platform, with isDesktop still covering Windows and macOS.

Failing safe: an unreadable boot id keeps you signed in

_linuxBootId() returns null if it cannot read the file, and a null boot id can
never satisfy crossedBoot. That means a read failure is treated as "not
durable" — the conservative direction, the one that keeps the user signed in
rather than out. We would rather leave a fallback in place than risk trusting a
store we could not assess.

The same principle runs through the whole check: every uncertain outcome resolves
to keeping the session, and only positive, cross-boot evidence moves the app to
keystore-only.

Why the obvious alternatives don't work

We considered the two shortcuts and rejected both:

Never drop the plaintext fallback on desktop. Simplest, and it would have avoided this bug — but it leaves the refresh token unencrypted on every healthy machine, forever. We rejected it once before and kept it rejected; it trades a real, permanent weakening of secret storage for a bug that has a precise fix.
Require N consecutive launches. More launches do not help. A daemon that keeps the value in memory passes any number of same-boot restarts; it only fails at the boundary a reboot represents. N consecutive launches only ever prove same-boot survival.

The boot boundary is the honest version of "durable across a restart": it is
precise, it keeps the keystore-only path for healthy machines, and it costs those
machines exactly one extra launch carrying a plaintext copy.

What actually changes for users

Not much, which is the point:

On a machine whose keyring never proves durable, the fallback stays and the session survives reboots. The user stays signed in, at the cost of an unencrypted local copy — which they can remove by unlocking the keyring's default collection at login.
On a healthy keyring, the plaintext copy is kept for one launch cycle after sign-in, then dropped; after that the keyring is the only copy, as before.

The change is covered by a test that launches the app twice inside one boot (the
fallback is kept) and once in a later boot (the store is trusted and the fallback
dropped). The rest of the storage suite still passes, so the Linux path stayed
additive.

If you want the surrounding work, we shipped a
photo album flow,
a shared media gallery
and the Linux desktop video and media kit
the same day, and there's a
full overview of GwinG
if you're new here.

FAQ

Does this log me out on a healthy Linux keyring?
No. It keeps the plaintext copy for one launch cycle after you sign in, then drops
it once a proof crosses a reboot. After that the keyring is the only copy, exactly
as before.

Why not just always keep the plaintext fallback on Linux?
Because it would leave the refresh token unencrypted on every Linux machine,
including the ones whose keyring is perfectly fine. Staying signed in matters, but
not at the permanent cost of plaintext secrets everywhere.

What if the app can't read the boot id?
It treats the store as not durable and keeps the fallback. That is the safe
direction — we would rather keep you signed in than trust a store we could not
assess.

Does this affect Android, iOS, Windows or macOS?
No. Off Linux the boot-id requirement is disabled and a proof that survives a
restart is enough, because the platform keystore there is reliable. Legacy proof
records behave the same way.

Is the boot id sensitive?
No. It is a random per-boot identifier whose only use here is answering "is this a
different boot?" It is not tied to a user or a machine, and it carries no data
beyond the boot boundary itself.

— the GwinG team

Get GwinG — a language-exchange messenger with live translation.

Android: Google Play
Windows: .zip or installer
Linux: .deb or portable tarball

Playing video on Flutter Linux desktop with media_kit

Frank Milvus — Tue, 13 Oct 2026 13:45:00 +0000

Video is the one media type in GwinG that cannot fail quietly. A photo that
won't load falls back to an icon tile and most people never notice; a video that
won't play looks like the whole app is broken. So when every video bubble on our
Linux desktop build started showing "Video expired" — the label we reserve for
a file the server no longer has — we knew something was off. Flutter Linux desktop
video simply had no player behind it: video_player ships no Linux implementation,
and media_kit was not wired up yet. This is the story of finding that out, and
moving playback behind one abstraction so the chat widgets never have to know which
player is underneath.

It turned out to be less about adding a library and more about being honest with the
UI: the app wasn't failing to find the video, it was failing to play it, and the
error path told the user the wrong story.

The symptom: every video bubble said "Video expired"

The report was suspiciously uniform. Not "some videos fail", not "big videos fail"
— every video, in every chat, on the Linux desktop build. That uniformity is
usually the clue you want: a codec problem, a corrupt file or a flaky network all
produce a mess of mixed results. An all-or-nothing failure means the problem is
above the file, in the layer that is supposed to decode it.

The other half of the clue was that the download was fine. Files downloaded
completely, landed in the cache, were playable by any other tool on the machine —
and the bubble still said Video expired. The label was a lie the app told itself.

Why Flutter Linux desktop video had no backend at all

Here is the root cause, and it is almost embarrassingly simple.

The video_player plugin ships platform implementations for Android, iOS, macOS
and web — that is video_player_android, video_player_avfoundation and
video_player_web. There is no video_player_linux. On Linux, calling
VideoPlayerController.initialize() does not fail because the file is missing or
malformed; it throws UnimplementedError, because the method channel has nobody on
the other end.

Our video widget's control flow made that throw look like an expiry:

The auto-download step runs first. It is pure Dart (http), so it succeeds on Linux exactly as it does everywhere else. The file is on disk.
initialize() is then called on that local file and throws UnimplementedError.
The streaming fallback runs, and throws for the same reason.
The outer catch sets _errored = true, and the error branch renders our fallback tile — the one labelled "Video expired".

Nothing expired. The file was there. The player did not exist. We had a UI that
described a server-side problem while the real problem was that we had never given
Linux a decoder.

One interface, two players

We could have fixed this by special-casing Linux all over the widget. We didn't
want that, and we didn't want the reverse either — dragging media_kit into
Android, iOS, macOS and web where video_player already works perfectly. The two
chat widgets (video_player.dart and its fullscreen sibling) were written against
VideoPlayerController, and we wanted that to stay true.

So we put a seam between "the widget" and "the player": a single
VideoPlaybackController that both backends implement. It extends ValueNotifier
and mirrors the video_player API the call sites already used, which is what made
the migration mechanical rather than a rewrite:

/// A video surface and its transport, behind a single API.
///
/// Extends [ValueNotifier] so it is listened to and read exactly like a
/// `VideoPlayerController` — the call sites were written against that type.
abstract class VideoPlaybackController
    extends ValueNotifier<VideoPlaybackValue> {
  Future<void> initialize();

  Future<void> play();
  Future<void> pause();
  Future<void> seekTo(Duration position);
  Future<void> setPlaybackSpeed(double speed);

  /// The video surface to place in the widget tree.
  Widget buildView();
}

The pick between implementations is a one-line, platform-checked function, so
nothing downstream branches on the platform at all:

/// Whether video playback on this platform runs through `media_kit` (libmpv)
/// instead of the `video_player` plugin.
bool get videoUsesMediaKit => isLinuxDesktop;

VideoPlaybackController createVideoPlaybackController({
  Uri? networkUrl,
  String? filePath,
}) {
  return videoUsesMediaKit
      ? MediaKitVideoController.create(
          networkUrl: networkUrl,
          filePath: filePath,
        )
      : PluginVideoController.create(
          networkUrl: networkUrl,
          filePath: filePath,
        );
}

Two thin wrappers sit behind it. PluginVideoController is a pass-through to the
video_player plugin and is used on Android, iOS, macOS and web — unchanged.
MediaKitVideoController owns a media_kit Player plus a VideoController, and
maps player.stream.* (playing, position, duration, video params) onto our small
VideoPlaybackValue snapshot. It renders the surface with
Video(controls: NoVideoControls) because the app draws its own controls; letting
media_kit draw a second set would have produced two overlapping transports.

The widgets now call createVideoPlaybackController(...), render
controller.buildView() instead of VideoPlayer(...), and are otherwise identical
to before. MediaKit.ensureInitialized() runs once at startup, and only on the
platform that needs it.

media_kit, without dragging every platform along

The obvious way to add media_kit is its aggregate package,
media_kit_libs_video, which bundles the native libraries for all supported
platforms. That is exactly wrong for us: it would pull native video libs into the
Android, iOS, macOS and web builds that already use video_player and are already
working. We chose the platform-scoped media_kit_libs_linux instead, so only Linux
gets the extra native payload.

One honest caveat we noted in the changelog: media_kit_video itself declares
native plugins for every platform, so it is still compiled into the non-Linux
builds even though only Linux uses it. That is a small size cost we accepted for
the convenience of a single pubspec dependency. If it ever matters, the clean fix
is to move the media_kit implementation behind a conditional import; for now the
cost is not worth the extra moving part.

If you're looking for the package, the media_kit on pub.dev
docs are unusually good, and Flutter's desktop support page
is worth a read before you assume a plugin works on every target.

The packaging reality: libmpv and libepoxy

Adding a player is not just a Dart dependency — on Linux, media_kit renders
through the system libmpv and OpenGL via libepoxy. That makes them hard
runtime requirements of the shipped app, and there are two ways to ship on Linux:
a .deb and a portable tarball. Both had to learn about the new libraries.

The .deb declares its runtime dependencies in Depends, and a missing entry does
not fail the build — it makes the installed app die at startup with a cryptic
"error while loading shared libraries". So the dependency list now includes the mpv
and epoxy packages, derived the same way as every other entry: by reading what the
binary actually links against. The CI workflow installs the -dev packages to build
and then verifies the mpv and epoxy pkg-config modules are present, so a build
machine that can't satisfy them fails early instead of shipping a bundle that can't
start.

The portable install path can't rely on a package manager to resolve anything, so
when its post-install ldd check finds an unresolved library it prints a
distribution-specific hint naming the mpv/libepoxy packages per distro. That is the
same fail-soft posture the rest of our desktop support takes, and it's covered
alongside Google sign-in and session persistence in our desktop support notes if you
want the wider picture.

What we could verify, and what we couldn't

We are careful to say what is proven and what is assumed. On the Linux side we
verified: the release build succeeds; media_kit_video and media_kit_libs_linux
show up in the generated plugin registrant; the binary links libmpv and
libepoxy; the bundle launches, prints the Linux libs as registered, restores a
session and connects; and flutter analyze is clean on the changed files.

What we could not verify in CI is the thing users actually care about — decoding
a real video on Linux, because that needs a real video message and a live session on
a real desktop. The build, the linking, the plugin registration and the startup path
are verified; the decode path is not, in automation. We say that plainly rather than
claiming a fix we haven't watched play.

The existing tests stayed green, which is a small reassurance that the abstraction
didn't change behaviour on the platforms it wasn't meant to touch: on the test
platform videoUsesMediaKit is false, so the fullscreen widget's close test still
exercises the stubbed video_player path — which throws, exactly as it did before.

The limits we are keeping on purpose

Two honest gaps, because a post that only lists wins is not useful:

Windows still routes through video_player. There is no Windows implementation either, so videos there are broken in the same way — and untested, because Windows has never been run on real hardware. The follow-up is to drop Windows into the same media_kit branch (plus its Windows libs) once we can actually test it. We deliberately didn't bolt it on blind.
Thumbnails and clip compression have no Linux backend. The video_thumbnail and v_video_compressor plugins don't cover Linux, so first-frame extraction and pre-upload compression stay best-effort and fail soft: the bubble simply keeps its icon tile. That's the correct degradation, and it's unchanged by this work.

FAQ

Why did the video bubble say "Video expired" when the file was fine?
Because the auto-download succeeded and the player was missing. initialize()
threw UnimplementedError on Linux, the widget's outer catch treated any
initialization failure as "unavailable", and its error branch is the tile labelled
"Video expired" — a label written for a server-side expiry, reused for a client-side
gap. The fix in the UI is that Linux now has a real player; the lesson is that error
copy should describe what actually failed.

Why media_kit and not a video_player Linux package?
There isn't one to install — video_player is implemented for Android, iOS, macOS
and web only, and the plugin's contract is that unsupported platforms throw. media_kit
is the pragmatic Linux backend because it renders through libmpv, which the distros
already package.

Do the chat widgets know they're on Linux now?
No, and that's the point. They call createVideoPlaybackController(...) and render
controller.buildView(). The only place that branches on the platform is
videoUsesMediaKit, and the only place that initializes the backend is a single
startup call.

Does adding media_kit bloat the mobile builds?
A little. We avoided the aggregate libs package so the native video libraries land
only on Linux, but media_kit_video still compiles its plugin scaffolding into the
other platforms. It's a small, accepted cost; a conditional import is the escape
hatch if it ever grows.

Will Windows work now too?
Not yet. Windows has no video_player implementation and has never been tested on
real hardware, so we left it on the broken-but-known path and listed moving it onto
media_kit as the follow-up rather than shipping an untested change.

If you want the shape of the desktop effort around this, we wrote up
shared media and albums
and
photo albums
the same day — and the other half of running a desktop app is keeping people signed
in, which is its own story in
making the Linux session survive a reboot.
If you're new here, start with
what GwinG is.

— the GwinG team

Get GwinG — a language-exchange messenger with live translation.

Android: Google Play
Windows: .zip or installer
Linux: .deb or portable tarball

A shared media gallery for chats and profiles

Frank Milvus — Tue, 13 Oct 2026 13:44:13 +0000

Open a friend's profile — or a group's info screen — and you can now browse every
photo, video, document and link the two participants have exchanged. We call it the
shared media gallery, a familiar idea from other messengers, scoped tightly to
the conversation between you.

The important word there is conversation-scoped. The gallery is not a cross-chat
index of everything a user ever sent; it's the media belonging to one thread. On a
profile that thread is the 1:1 chat between you and the person; in group info it's
the group. One read serves both shapes, and the profile reaches it through a
read-only peer resolver that never creates a conversation as a side effect. It
shipped as Phase 1, and this post walks through the parts that were worth getting
right: the single conversation-scoped read, its kind slices, cursor pagination, the
resolver, a small FastAPI routing gotcha, and why encrypted chats are deliberately
left out.

Why scope the gallery to a conversation

The obvious alternative is a user-scoped media index: "everything this person has
ever shared, across all their chats." We didn't want that, for two reasons.

First, the feature's meaning is always conversational. When you open someone's
profile and tap Media, you're asking "what have the two of us shared?" When you
open group info, you're asking "what has this group shared?" Both questions are
about a single conversation, and answering them with a per-user index would force us
to reconstruct the conversation boundary in the query anyway.

Second, access control falls out for free. A conversation already has a
membership check on every read, so the gallery inherits it: if you're not a member,
you can't page through the media. No new sharing model, no new leak surface.

So the primitive is simple: given a conversation and a caller, return the messages
in that conversation that carry media.

One read serves 1:1 and groups

The backend exposes a single service method, fetch_shared_media, and both entry
points delegate to it:

@staticmethod
async def fetch_shared_media(
    db: AsyncSession,
    conversation_id: int,
    user_id: int,
    kind: str = "media",
    limit: int = 50,
    before: int | None = None,
):
    """Messages carrying media in a conversation (the "Shared Media"
    gallery shown on a profile and in group info)."""

It verifies the caller's access to the conversation, refuses encrypted threads (more
on that below), filters by kind, and returns newest-first. The same call powers a
1:1 profile tab and a group screen; there is no "group variant" and no "profile
variant" on the read path.

The kind slices

A gallery isn't one list — it's three, and the frontend shows them as segments. The
kind argument selects the slice:

image — messages with an image attached.
video — messages with a video attached.
media (the default) — images and videos, which is the photos grid.
file — documents, i.e. messages carrying a file attachment.
link — messages the backend attached a link preview to.

The filters are plain column checks, which keeps the slice logic in one place and
easy to read:

if kind == "image":
    kind_filter = Message.image_url.is_not(None)
elif kind == "video":
    kind_filter = Message.video_url.is_not(None)
elif kind == "file":
    kind_filter = Message.file_url.is_not(None)
elif kind == "link":
    kind_filter = Message.link_preview_url.is_not(None)
else:  # "media" (default): images and videos
    kind_filter = or_(
        Message.image_url.is_not(None),
        Message.video_url.is_not(None),
    )

link is worth a note: it doesn't mean "message text contains a URL." It means the
backend unfurled the URL and stored a preview, which is exactly what the link list
renders.

Deleted messages, ordering, and the cursor

Two invariants keep the list honest. Deleted messages are excluded outright —
deleted_at IS NULL is part of the WHERE, so a removed photo doesn't linger in
the grid. And results are ordered Message.id.desc(), newest first, matching how
every other list in the app reads.

Pagination is a keyset cursor, not an offset: pass before, the id of the oldest
message you've already seen, and the query adds Message.id < before. That stays
correct while new messages arrive — an offset would shift rows out from under the
reader as the conversation grows. The route takes the same three knobs, so the
client can fetch the first page and then ask for older media on demand.

There's one subtle, very real backend detail here. The response serializes the
reply sender's name, so reply_to.sender is eager-loaded on the query. A lazy
load inside an async session raises MissingGreenlet at serialization time — the
same bug family we hit on search. It's the kind of thing that only shows up when a
gallery item happens to be a reply to an image, which makes it exactly the kind of
thing to pin down in a query rather than discover in production.

A read-only peer resolver that never creates a conversation

The profile screen knows a user id, not a conversation id. Normally "start a chat"
means get-or-create: look for the conversation, and if it isn't there, make one.
That's the wrong contract for a profile tab. Opening someone's profile is a read,
and it shouldn't quietly create an empty conversation just because they glanced at a
Media tab.

So the peer path is a dedicated resolver, fetch_shared_media_with_user, and it
resolves without ever writing:

low, high = (user_id, peer_id) if user_id <= peer_id else (peer_id, user_id)
stmt = (
    select(Conversation.id)
    .where(
        Conversation.type == "private",
        Conversation.is_encrypted.is_(False),
        Conversation.user_low == low,
        Conversation.user_high == high,
    )
    .order_by(Conversation.id.asc())
    .limit(1)
)
conversation_id = (await db.execute(stmt)).scalars().first()
if conversation_id is None:
    return []
return await ChatService.fetch_shared_media(db, conversation_id, user_id, ...)

The pair is normalized to an ordered (low, high) so both directions of the same
1:1 point at one row. The lookup is restricted to a plaintext private conversation
and returns an empty list when there isn't one — never a new row. From there it
delegates to the same fetch_shared_media, so the resolver only ever has to know how
to find a conversation, not how to read its media.

That "returns empty when none exists" behaviour is what makes the read idempotent:
call it once or a hundred times, the state of the database is identical.

Two routes, and the literal-first ordering gotcha

The API exposes two endpoints:

GET /chat/with/{user_id}/media?kind=&limit=&before=
GET /chat/{conversation_id}/media?kind=&limit=&before=

The first is for profiles (peer id), the second for groups and chat info
(conversation id). Both map onto the service methods above.

Here's the gotcha, and it's a genuine one. The second route's path segment is
{conversation_id}, a placeholder that will happily match any single segment —
including the literal string with. If it were declared first, a request to
/chat/with/123/media would match that placeholder, FastAPI would then try to
validate with as an integer, and the client would get a 422 rather than the
profile gallery. FastAPI resolves routes in declaration order and validates the path
parameter's type after a route matches, so a later literal route is simply never
reached. The rule that follows is boring and effective: declare the literal,
more-specific route first. We do, and the with segment can never be mistaken for
a conversation id. The FastAPI docs on path parameters and their
order are worth a read if you
haven't been bitten by this yet.

Encrypted chats are deliberately excluded

We ship opt-in end-to-end encrypted chats. Their media is encrypted on the client
before it ever reaches the server, which means the server is holding ciphertext — and
ciphertext can't be filtered or listed. There is no "is this an image?" column to
query, because the image is inside a blob the server can't read.

So the feature is honest about it in two different places:

The conversation-scoped read checks whether the conversation is encrypted and returns 403 if it is — "Shared media is not available in encrypted chats." An explicit refusal beats a silently empty list that looks like a bug.
The peer resolver only ever looks at the plaintext private conversation, so a profile Media tab for someone you only share an encrypted chat with simply returns nothing. It doesn't 403, because from the resolver's point of view the two of you have no plaintext conversation — which is true.

Making this work later means decrypting from the local cache on the client, a
separate effort we've noted rather than bolted on. Some things are worth doing once,
properly.

The frontend: Media / Files / Links

The Flutter side is a single reusable widget, SharedMediaView. It takes exactly
one of userId (profile path) or conversationId (group path), asserted at
construction, and stores three lazy segment caches so switching tabs doesn't re-fetch
what you've already seen.

The segments are Media, Files and Links, switched with Material's
SegmentedButton,
and the Media segment renders a 3-up grid that reuses the pieces the rest of the app
already has: CachedNetworkImage backed
by the shared AppMediaCacheManager for cached thumbnails, and the existing
fullscreen gallery for the tap-through, so the gallery you get here behaves exactly
like the one in a chat. Videos render a play-button placeholder in the grid and open
in the same viewer.

Files and links are lists. A file row shows the file name and a human-readable size
and opens in the browser on tap. A link row leads with the unfurled thumbnail, then
the preview title, with the site name underneath — the same data the link-preview
message bubble uses, which is why the link slice keys off the stored preview rather
than parsing text.

For entry points that aren't already a tab — pushing the gallery from group info — a
thin SharedMediaScreen hosts the widget full-screen. The profile reuses its tab
framework, adding an optional Media tab scoped by userId.

If you like the media plumbing behind this, two sibling posts go deeper: photo
albums in
Flutter
covers the multi-image layout, and the Flutter Linux desktop video and media
kit
covers playback. The session durability work with the Linux
keyring
is the other half of getting desktop right, and there's a full overview of
GwinG
if you're new here.

FAQ

Does opening someone's profile create a chat?
No. The profile path goes through the read-only peer resolver, which returns an empty
list when the two of you have no plaintext conversation. It never writes a row.

What happens on an encrypted chat?
The conversation-scoped endpoint returns 403 — an explicit "not available here."
The profile path returns an empty list, because the resolver only consults the
plaintext 1:1 conversation.

Can the gallery show media from a group and a 1:1 the same way?
Yes. Both are the same conversation-scoped read; the only difference is whether the
client passes a conversationId or resolves one from a userId.

Do deleted messages still show up?
No. Deleted messages are excluded at the query level, so a removed photo disappears
from the grid on the next load.

Can I page further back through old media?
The API is cursor-paginated by message id via before, newest-first. The Phase 1 UI
loads the first page; wiring the grid's scroll to pull older pages is a small
follow-up on the same cursor.

— the GwinG team

Get GwinG — a language-exchange messenger with live translation.

Android: Google Play
Windows: .zip or installer
Linux: .deb or portable tarball

Replacing a Flutter app bar with a FAB action stack

Frank Milvus — Tue, 13 Oct 2026 11:27:04 +0000

The GwinG notification center is a short screen: reactions, profile views
and group events, most recent first. It opened from the Friends header's overflow
menu and carried a perfectly ordinary AppBar — a "Notifications" title on the
left, a mark all read and a clear all icon button on the right.

It worked. It also looked like every other screen, and it put the three things
you actually do on that screen — leave it, mark it read, clear it — into small
icon buttons at the very top of the phone, the hardest place to reach.

So we deleted the app bar. In this post I'll walk through what replaced it: a
vertical floating action button stack, why a Scaffold with no AppBar loses
its managed status bar (and the zero-height trick that gets it back), and the two
gotchas that bite the moment you put more than one FAB on a route.

Why take the app bar out

Three reasons, in order of how much they actually mattered:

Reachability. On a phone, top-right icon buttons are a stretch. The bottom third of the screen is where a thumb lives, and that is FAB territory.
Consistency. The app already had a house style for floating buttons — an outlined circle in the brand colour — used across the Friends page, the profile screen and the full-screen map. The notification center was one of the few screens still speaking a different language.
Less chrome. The title just said "Notifications" on the screen that the notification icon opened. It was a label telling you what you already knew, in the one row where vertical space is scarcest.

The plan was simple to state: drop the toolbar, and render back,
mark all read and clear all as the same floating buttons used everywhere
else.

The catch: no AppBar means no managed status bar

Here is the part that surprises people. A Scaffold with an AppBar doesn't just
draw a toolbar — it also lets Flutter manage the status bar for you: the
system bar behind the clock and battery gets the page's colour and the right
icon brightness, consistently across every screen.

Take the AppBar away and that management goes with it. On Android especially,
you can end up with a status bar whose colour no longer matches the page, or
whose icons are dark-on-dark. It's the kind of thing that looks like a bug in the
OS rather than in your layout.

The fix is not to fight it — it's to keep a toolbar that draws nothing:

Scaffold(
  // A managed status bar without a toolbar. This still reserves the
  // status-bar inset and lets Flutter colour the bar and pick the icon
  // brightness, exactly as a normal AppBar would.
  appBar: AppBar(
    toolbarHeight: 0,
    elevation: 0,
    scrolledUnderElevation: 0,
    shape: const RoundedRectangleBorder(),
  ),
  body: ...,
);

A zero-height AppBar keeps everything you want from the bar — the status-bar
inset and the managed system chrome — and draws none of it. We already lean on
this same trick on the Friends page (which draws its own custom header below) and
on the full-screen map, so the notification center was a natural fit.

One slot, a whole stack of buttons

A Scaffold gives you a single floatingActionButton. You are not limited to one
button, though — the slot takes any widget, so you stack them in a Column that
grows upward from the bottom-right corner:

floatingActionButton: Column(
  mainAxisSize: MainAxisSize.min,
  crossAxisAlignment: CrossAxisAlignment.end,
  children: [
    AppFab(
      heroTag: 'notif_clear_all',
      onPressed: _items.isNotEmpty ? _confirmClearAll : null,
      tooltip: l10n.clearAll,
      icon: const Icon(Icons.delete_sweep_outlined),
    ),
    AppFab(
      heroTag: 'notif_mark_all_read',
      onPressed: _items.any((n) => !n.isRead) ? _markAllRead : null,
      tooltip: l10n.markAllRead,
      icon: const Icon(Icons.done_all),
    ),
    AppFab(
      heroTag: 'notif_back',
      onPressed: () => Navigator.of(context).pop(),
      tooltip: MaterialLocalizations.of(context).backButtonTooltip,
      icon: const Icon(Icons.arrow_back),
    ),
  ],
),

Two deliberate choices there:

Nothing moves. All three buttons are always mounted, so the stack's layout is fixed. When an action has nothing to act on — clear all on an empty list, mark all read when everything is already read — it stays put and greys out instead of vanishing. A button that comes and goes makes the one below it jump, and that motion is exactly what makes a UI feel unstable.
The list gets out of the way. The FAB stack floats over the content, so the list carries bottom padding equal to roughly its height. Without it, the last notification sits under the buttons.

AppFab is our shared wrapper around FloatingActionButton — a circular outline
in the brand colour over the surface, with a brand-coloured icon. Routing every
FAB through it is what keeps the app from drifting into a mix of Material's tonal
default (which reads as a rounded square in a different colour) and the house
style.

Passing null for onPressed is the idiomatic way to disable a Material button,
and it does make the FAB non-tappable — but it does not grey it out.
FloatingActionButton only falls back to its disabled colours when you leave
backgroundColor and foregroundColor unset; set both explicitly, as the house
style does, and a disabled FAB keeps the full brand colour — looking enabled while
doing nothing. So AppFab reads onPressed == null itself and swaps to muted
surface-variant greys for the outline and the icon:

final enabled = onPressed != null;
final accent = enabled ? colors.primary : colors.onSurfaceVariant;
final border = enabled ? colors.primary : colors.outlineVariant;

Gotcha #1: two FABs on a route trip the hero-tag check

This one is not obvious until it breaks.

Every FloatingActionButton participates in Flutter's Hero
machinery for route transitions. When you don't give a FAB a heroTag, it gets a
single shared default tag — the same constant for every untagged FAB in the
app. With one FAB per screen that's fine. Put three on one route, and you have
three heroes claiming the same tag: Flutter throws a duplicate-tag assertion, and
even when it doesn't, route transitions animate the wrong button across the
screen.

The rule we landed on is boring and effective: every FAB gets an explicit,
unique heroTag. Note that "unique" has to hold beyond this route, too — the
Friends page's own FABs are still mounted underneath while the notification center
pushes on top of them, so the tags must not collide across both screens.

Gotcha #2: making an icon-only button say what it is

An icon-only FloatingActionButton has no text for a screen reader and no label
for a long-press tooltip, so it should always carry one. For the two app actions
we had localized strings already. For back, we didn't — and it turns out we
never needed to add one:

tooltip: MaterialLocalizations.of(context).backButtonTooltip,

MaterialLocalizations ships a translated backButtonTooltip for every locale
Flutter supports, which is exactly the string a real AppBar back button would
use. Borrowing it keeps one source of truth for "Back" across the whole app
instead of a fifth translation that can drift.

The result

The notification center is now a clean list with three outlined circles parked in
thumb range — back, mark all read, and above it clear all — that grey
out whenever there is nothing for them to do. The status bar stays the page's
colour, back works from the bottom-right the way it does on the full-screen map,
and the screen finally looks like it belongs to the same app as everything around
it.

It's a small change. But "the app bar can just be, well, not there" is one of
those realisations that quietly raises the floor on every screen you touch
afterwards.

If you want the surrounding context, the Friendship flow and the
connection status work
we shipped just before this are both written up on the blog, and there's a
full overview of GwinG
if you're new here.

FAQ

Does removing the app bar break the system back button?
No. The system back gesture and button are handled by the route, not the AppBar.
Removing the toolbar only removes the on-screen affordance — which is exactly
why we added the back FAB. Both work, and Android's predictive back is unaffected.

Why not just use a BottomAppBar or PersistentFooterButtons?
Either works. We chose a FAB stack because the app already has an established FAB
style on the Friends page, and reusing it made the notification center match
without introducing a fourth bottom-bar pattern to keep consistent.

Can you have more than one FloatingActionButton?
Yes — the Scaffold takes one floatingActionButton widget, but that widget can
be a Column, a Row or any layout containing several buttons. Just give each a
unique heroTag.

Does the zero-height AppBar still push the body down?
It reserves the status-bar inset (so content doesn't slide under the clock) but no
toolbar height, so the body starts right below the system status bar. We still
wrap the body in SafeArea(top: true) for the remaining insets.

— the GwinG team

Get GwinG — a language-exchange messenger with live translation.

Android: Google Play
Windows: .zip or installer
Linux: .deb or portable tarball

Small polish, better feel — a smoother connection status and a clear way out of a call

Frank Milvus — Mon, 12 Oct 2026 13:57:59 +0000

Today's changes in GwinG were small on purpose. Neither is a headline
feature — but they're the kind of thing you notice the moment it's right: the app
feels calmer and gets out of your way.

A connection status that fades, not pops

Next to the Friends wordmark we show a live connection label — Connecting…,
Syncing…, or No connection. It used to appear and disappear in a single
frame, which read as a hard blink every time the network changed its mind.

It now fades and slides in and out instead of popping, and because it's a
visibility change rather than an entrance, we made it something you control:
there's a new Connection status toggle under Settings → Motion, joining
the existing motion categories (nine now). When motion is switched off, the label
simply updates instantly — no special-casing needed.

A couple of details we cared about:

The label only cross-fades when it appears or disappears. Switching between two live states updates in place, so you don't get a distracting flicker between similar words.
The wordmark never shifts. The slot is always laid out, so the header stays put and the text keeps sitting exactly on the wordmark's baseline.

A clear way out of a call

When a call ends, GwinG shows a short end card — who it was with, how it
ended, how long it lasted, and a Call again button. The card returns you to
the app on its own after a few seconds (a little longer when there's a reason to
read), and tapping anywhere dismisses it early.

The catch: "tap anywhere" is not the same as an obvious way out. So we added a
Back button right next to Call again. Now leaving the end card is a named,
one-tap action instead of a hidden gesture or a short wait.

Why we bother with the small stuff

A messenger is mostly made of these moments — a label that blinks, a screen you
can't quite leave. Big features get the attention, but the small ones are what
make an app feel considered. We write them up as we ship them, so the polish
gets its share of the credit too.

— the GwinG team

Get GwinG — a language-exchange messenger with live translation.

Android: Google Play
Windows: .zip or installer
Linux: .deb or portable tarball

DEV Community: Frank Milvus

Video thumbnails without downloading the video

A video tile that only knew how to say "video"

Two ways to get a still frame

Extract on the server

Extract on the sender's device

Why the sender's device won

How a poster travels from send to screen

Extract, convert, upload

Survive a restart

Render the tile

The desktop plot twist: Linux needed its own extractor

Old videos, Windows and macOS

Tests and what comes next

FAQ

Search every chat and every message from the chats list

Two questions, one search box

Instant filtering, then a slower second opinion

What the server actually searches

Messages above chats

Opening a hit exactly where it happened

One search box, one visible tab

Escape the wildcards

What this does not do yet

FAQ

Pin flights, a real find hotkey, and colored More tiles

Small changes you feel before you name them

A pin should move, not teleport

The entrance bug hiding in the same pass

The find chord should mean find

Color as a signpost

FAQ

Does pinning still work if motion is disabled?

Does Alt+F work while I am typing in the search box?

Do the More tile colors change with the theme?

Why this batch matters

Why we renamed tonGues to GwinG — and what stayed the same

Why this post exists

The old name was already taken

What a name has to do when it is also a handle

Choosing a name we could own

The wordmark: red at the edges, amber at the centre

The tagline: where languages meet

A new splash with the same flame

Desktop builds get a new name

What did not change

FAQ

The test we cared about

Fast account switching in Flutter without a sign-in round trip

What the user sees

Validate before you tear down

One session at a time

Scoping on-device data by account

Keeping async work on its account

Migrating the single-account past

Three bugs a review pass caught

Lessons

FAQ

Inline emoji shortcodes, private pins, and grouped bubbles

Inline emoji shortcodes: :joy → 😂

A token scanner that stays out of the way

Ranking so :joy beats :joy_cat

Private pins, next to conversation-wide pins

The data model

One service, three delivery paths

Grouped bubbles: one burst, one block

The defects a green build didn't catch

Why write it up

FAQ

Building photo albums in Flutter

One row per media item — the rule we refused to break

Why Flutter photo albums need a group key

The anchor row

Grouping Flutter photo albums on the client

A grid that's sized on the first frame

One notification, one preview, one progress bar

Forward keeps the group; delete takes it apart

What we'd do next

FAQ

Staying signed in on Linux when the keyring doesn't survive a reboot

Does `Alt+F` work while I am typing in the search box?

Inline emoji shortcodes: `:joy` → 😂

Ranking so `:joy` beats `:joy_cat`