Fast, native clients and plugins for Jellyfin
Nothing waits visibly.
Most Jellyfin clients today are web views in a native shell. They work, and they feel like it. A poster wall that stutters as you scroll, a focus change that lands a beat after the key, a spinner sitting inside a tile where the artwork should be. On a phone it is annoying. On a television, ten feet away with a remote in your hand, it is the whole experience.
Flowfin is an attempt at the other thing. One genuinely native client per platform, sharing a core rather than a codebase, plus the server plugins the clients need.
Flowfin is not affiliated with the Jellyfin project.
Speed is not a feature here, it is the product. So it is written as numbers a build can miss rather than as an intention:
| Focus change | under 80 ms |
| Scrolling 200 tiles | no dropped frames at 60 fps |
| First usable tile, cold start | under 1.2 s |
| Press play to first frame | under 2 s |
A build that misses one of these is a failed build, not a slow one.
Two smaller rules follow from the same idea. Nothing shows a spinner inside a tile, and no image arriving late is allowed to shift the layout. And missing artwork is treated as a design case rather than an error case, because a personal library has whatever the metadata provider happened to hold, and a wall with three grey holes in it looks worse than a list.
The interface is neutral. Content is the only colour, and one accent marks one thing: what has focus.
That accent is configurable, with a preset for each deficiency rather than a single accessible mode. Which hue works depends on which cone type is missing, and the hue that serves the two common forms best is the wrong one for the rare third. Removing colour entirely is right only for achromatopsia; for everyone else it throws away a signal their eyes could have read. No state anywhere depends on hue alone, whatever the preset.
The full system is at flowfin.dev.
Early, and the table says so rather than letting you find out after installing. One plugin ships today. The rest are in build-up, some of them still a shell.
| Plugin | What it does | State |
|---|---|---|
| sso | Sign in through OpenID Connect or SAML 2.0 identity providers | Ships |
| share-links | Share one library item with invited guests, through a link that expires and can be revoked | In build-up |
| watchlist | A private per-user watchlist kept on the server, shown by clients that were never changed | In build-up |
| stats | Playback statistics, kept private to the user they are about | In build-up |
| whisper-subtitles | Transcribes library items that have no subtitle, using Whisper | In build-up |
| server-pairing | Pairs one server with a second, so plugins on both sides can work across the pair | In build-up |
| watch-sync | Moves watch history between paired servers | In build-up |
| metadata-sync | Moves chosen metadata fields between paired servers | In build-up |
| smart-collections | Collections described once as a rule, then filled from the library as it changes | Shell only |
| requests | A user asks the server for a title, an administrator answers it in a queue | Shell only |
| invites | Invitation links that let somebody set up their own account | Shell only |
| discover | Browse titles a server does not have | Shell only |
Ships means there are releases you can install. In build-up means the work is real but there is no release yet. Shell only means it installs and does nothing.
The plugin catalogue URL will be published once there is more than one release behind it. A manifest address is permanent, because every server that adds it keeps fetching it forever, so it is worth waiting until it lists something.
Open an issue on the repository it belongs to. Bug reports are welcome even when they are only half understood; what a thing did and what you expected is enough to start.
For a security problem, use the private reporting link under Security on the repository rather than an issue. It is enabled everywhere here, and it keeps the report between you and the maintainer until there is a fix.