Five things this plan runs into that a maintainer has to settle. Nothing here is
decided and nothing here is a recommendation. Each entry states the options and
what each one costs. Where a planned issue is blocked on one of these, it says so
and points here rather than opening a second question somewhere else.
1. The license of this repository
There is none today.
gh api repos/Flowfin/hub --jq '.license'
null
Run 2026-08-07.
This is first because everything else lands on top of it. The license decides
what an operator, a packager and a contributor may do with every file in the
tree, and it decides it retroactively for whatever is already here.
The answer is not automatic because this repository holds three different kinds
of thing. A generator, which is code. A published site, which is code and prose.
And a design system, which is prose plus a set of numbers that other projects
are being asked to adopt.
Options and costs.
MIT or BSD-2-Clause. Shortest, most widely understood, imposes almost nothing.
Anyone may take the generator and the design system into a closed product
without saying so. The cost is that there is no reciprocity at all.
Apache-2.0. The same permissions plus an explicit patent grant and a requirement
to state changes. The patent grant is the usual reason an organisation prefers
it over MIT. The cost is incompatibility with GPL-2.0-only consumers, which
matters only if something here is ever vendored into one.
GPL-3.0 or AGPL-3.0. Reciprocal, so a derivative generator or site has to stay
open. The cost is real here: several plugin ecosystems and distribution
packagers avoid copyleft by policy, and the design system is prose that other
people are being invited to follow, so copyleft over it reads more like a
restriction on adoption than a protection of it.
Split the tree. Code under one license, the site text and the design system
under CC-BY-4.0 or CC0. The cost is that two licenses in one tree is something
every consumer has to read carefully, and getting the boundary wrong is the
normal outcome rather than the unusual one.
Worth settling in the same sitting: whether the plugin repositories the
catalogue lists should carry the same license. A catalogue under one license
listing plugins under another is a question people will ask, and the answer is
easier to give before the catalogue is public.
2. The domain the manifest is served from
The published page already prints an install address.
grep -o 'https://flowfin.dev/manifest.json' docs/index.html
https://flowfin.dev/manifest.json
The name does not resolve.
curl -sS -o /dev/null https://flowfin.dev/manifest.json ; echo "exit=$?"
curl: (6) Could not resolve host: flowfin.dev
exit=6
Both run 2026-08-07.
This address is the most permanent thing the project will ever publish. Once an
operator pastes it into a Jellyfin server, changing it raises no error anywhere.
The server keeps polling the old address, the plugins stop updating, and nobody
finds out until someone asks why a version is old.
Options and costs.
Register flowfin.dev and serve from it. The cost is a registration fee and
renewals for as long as anyone has it configured, and a lapsed renewal is a
silent outage for every installation. The .dev top level is on the HSTS preload
list, so it is HTTPS-only by construction, which is the property this use wants.
Register a different name. Same costs, plus the published page has to change.
Do not use a custom domain, and serve from the github.io address. Free and
available today. The cost is that the permanent promise then contains an account
name and a repository name, and renaming either one breaks every installation
that ever used it.
Publish no address yet. The cost is that nothing is installable, which is also
the current state.
Who registers it, at which registrar, and under which contact details, is part
of the answer rather than a detail after it.
3. What language the published site is written in
The site and the design system are German today. The tracker, the source and the
documents an operator reads are being planned in English.
Options and costs.
German only. The cost is that a Jellyfin plugin catalogue is read mostly by
people who will arrive in English.
English only. The cost is rewriting pages that are good as they are.
Both, with one of them named as the source the other follows. The cost is that
two versions drift, and drift on a page that states a speed budget is worse than
either language alone.
4. Whose name the catalogue carries
Every entry in the manifest has an owner field, and a Jellyfin server shows it to
the person installing the plugin. The plugins are released under the account
iderex. The catalogue is published under the organisation Flowfin.
Options and costs.
The releasing account. Honest about where the artifact actually comes from. The
cost is that the catalogue looks like it belongs to someone other than the site
that serves it.
The publishing organisation. Consistent with the site and the domain. The cost
is that it names an organisation that did not sign the release.
Both, written as one string. The cost is a long value in a narrow column on
every server that renders it.
This is a naming and attribution question rather than a technical one, which is
why it is here and not in a decision issue.
5. Whether a test channel is offered to the public
The generator can produce one list or two. Two lets a willing operator opt into
pre-release builds. One keeps the promise short.
Options and costs.
One address, stable builds only. The cost is that nothing gets tested by anyone
outside before it reaches everyone at once.
Two addresses. The cost is a second permanent promise, with everything entry 2
says about permanence applying to it as well, and every support conversation
starting with which of the two was pasted.
One address that carries pre-releases too. The cost is that nobody can opt out
of them.
Five things this plan runs into that a maintainer has to settle. Nothing here is
decided and nothing here is a recommendation. Each entry states the options and
what each one costs. Where a planned issue is blocked on one of these, it says so
and points here rather than opening a second question somewhere else.
1. The license of this repository
There is none today.
Run 2026-08-07.
This is first because everything else lands on top of it. The license decides
what an operator, a packager and a contributor may do with every file in the
tree, and it decides it retroactively for whatever is already here.
The answer is not automatic because this repository holds three different kinds
of thing. A generator, which is code. A published site, which is code and prose.
And a design system, which is prose plus a set of numbers that other projects
are being asked to adopt.
Options and costs.
MIT or BSD-2-Clause. Shortest, most widely understood, imposes almost nothing.
Anyone may take the generator and the design system into a closed product
without saying so. The cost is that there is no reciprocity at all.
Apache-2.0. The same permissions plus an explicit patent grant and a requirement
to state changes. The patent grant is the usual reason an organisation prefers
it over MIT. The cost is incompatibility with GPL-2.0-only consumers, which
matters only if something here is ever vendored into one.
GPL-3.0 or AGPL-3.0. Reciprocal, so a derivative generator or site has to stay
open. The cost is real here: several plugin ecosystems and distribution
packagers avoid copyleft by policy, and the design system is prose that other
people are being invited to follow, so copyleft over it reads more like a
restriction on adoption than a protection of it.
Split the tree. Code under one license, the site text and the design system
under CC-BY-4.0 or CC0. The cost is that two licenses in one tree is something
every consumer has to read carefully, and getting the boundary wrong is the
normal outcome rather than the unusual one.
Worth settling in the same sitting: whether the plugin repositories the
catalogue lists should carry the same license. A catalogue under one license
listing plugins under another is a question people will ask, and the answer is
easier to give before the catalogue is public.
2. The domain the manifest is served from
The published page already prints an install address.
The name does not resolve.
Both run 2026-08-07.
This address is the most permanent thing the project will ever publish. Once an
operator pastes it into a Jellyfin server, changing it raises no error anywhere.
The server keeps polling the old address, the plugins stop updating, and nobody
finds out until someone asks why a version is old.
Options and costs.
Register flowfin.dev and serve from it. The cost is a registration fee and
renewals for as long as anyone has it configured, and a lapsed renewal is a
silent outage for every installation. The .dev top level is on the HSTS preload
list, so it is HTTPS-only by construction, which is the property this use wants.
Register a different name. Same costs, plus the published page has to change.
Do not use a custom domain, and serve from the github.io address. Free and
available today. The cost is that the permanent promise then contains an account
name and a repository name, and renaming either one breaks every installation
that ever used it.
Publish no address yet. The cost is that nothing is installable, which is also
the current state.
Who registers it, at which registrar, and under which contact details, is part
of the answer rather than a detail after it.
3. What language the published site is written in
The site and the design system are German today. The tracker, the source and the
documents an operator reads are being planned in English.
Options and costs.
German only. The cost is that a Jellyfin plugin catalogue is read mostly by
people who will arrive in English.
English only. The cost is rewriting pages that are good as they are.
Both, with one of them named as the source the other follows. The cost is that
two versions drift, and drift on a page that states a speed budget is worse than
either language alone.
4. Whose name the catalogue carries
Every entry in the manifest has an owner field, and a Jellyfin server shows it to
the person installing the plugin. The plugins are released under the account
iderex. The catalogue is published under the organisationFlowfin.Options and costs.
The releasing account. Honest about where the artifact actually comes from. The
cost is that the catalogue looks like it belongs to someone other than the site
that serves it.
The publishing organisation. Consistent with the site and the domain. The cost
is that it names an organisation that did not sign the release.
Both, written as one string. The cost is a long value in a narrow column on
every server that renders it.
This is a naming and attribution question rather than a technical one, which is
why it is here and not in a decision issue.
5. Whether a test channel is offered to the public
The generator can produce one list or two. Two lets a willing operator opt into
pre-release builds. One keeps the promise short.
Options and costs.
One address, stable builds only. The cost is that nothing gets tested by anyone
outside before it reaches everyone at once.
Two addresses. The cost is a second permanent promise, with everything entry 2
says about permanence applying to it as well, and every support conversation
starting with which of the two was pasted.
One address that carries pre-releases too. The cost is that nobody can opt out
of them.