From 0458c91f0476541dee34362eda38922cab4f12fc Mon Sep 17 00:00:00 2001 From: Joost de Valk Date: Wed, 23 Sep 2026 08:15:23 +0200 Subject: [PATCH 1/2] add(considered): /.well-known/funding-manifest-urls is one funder's application form MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The daily standards scan found `funding-manifest-urls` in the IANA Well-Known URIs registry (provisional since 2025-04-02) with no page here. It records a domain-control proof for `funding.json` manifests. Turned down as `too-narrow`: sound mechanism, real publishers, but a single consumer — the FLOSS/fund directory, crawling for one annual grant pool. Revisit when a second independent system reads the format. Co-Authored-By: Claude Opus 5 (1M context) --- .../considered/funding-manifest-urls.md | 25 +++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 src/content/considered/funding-manifest-urls.md diff --git a/src/content/considered/funding-manifest-urls.md b/src/content/considered/funding-manifest-urls.md new file mode 100644 index 00000000..ef95d3ea --- /dev/null +++ b/src/content/considered/funding-manifest-urls.md @@ -0,0 +1,25 @@ +--- +title: "/.well-known/funding-manifest-urls" +date: "2026-09-23" +reason: too-narrow +revisit: "A second independent consumer reading funding.json — a package registry, a forge, or another funder — rather than one directory crawling for one grant programme. At that point the topic stops being 'how to be found by FLOSS/fund' and becomes 'how a project declares its funding needs machine-readably', which would be worth a page." +sources: + - title: "Well-Known URIs registry" + url: "https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml" + publisher: "IANA" + - title: "Well-Known Uniform Resource Identifiers (URIs)" + url: "https://www.rfc-editor.org/rfc/rfc8615.html" + publisher: "IETF" + - title: "funding.json — an open manifest schema for open source projects" + url: "https://fundingjson.org/" + publisher: "FLOSS/fund" + - title: "FLOSS/fund directory" + url: "https://dir.floss.fund/" + publisher: "FLOSS/fund" +--- + +`funding-manifest-urls` has been a **provisional** entry in the IANA Well-Known URIs registry since 2 April 2025, with `info@floss.fund` as change controller and `fundingjson.org` as its reference. It is not the funding manifest itself. The manifest — `funding.json`, a JSON document describing who maintains a project, what it needs money for, and how to send it — lives at an ordinary URL of the publisher's choosing. The well-known file is the proof of control that sits underneath it: a plain-text list, one URL per line, saying "these manifests are allowed to speak for this domain". A manifest hosted on `example.com` that claims a project at `project.net` is unverified until `project.net/.well-known/funding-manifest-urls` names it back. + +The mechanism is sound and the scope test is close to passing: it is a file a content origin serves, it is checkable from outside, and cross-origin claims genuinely do need something like it. What it is not is a property of websites in general. It answers one question — how an open-source project proves a funding claim — for one audience, and it is read, in practice, by one crawler: the FLOSS/fund directory, built to distribute a single annual grant pool. Real projects have published manifests, F-Droid and MetaBrainz among them, so this is not a standard nobody uses. It is a standard used by everybody who wants that grant and nobody who does not. + +That makes it narrow rather than early, and the distinction matters for what would change our mind. Waiting longer will not help; more publishers joining the same directory would only make the same programme bigger. What would help is a second reader — a package registry, a forge, another funder — parsing `funding.json` for its own purposes. Domain-verified funding metadata that several independent systems consume is a website outcome. A manifest that one grant programme crawls is an application form with a URL. From c02584ec782b28a4a14b5ab976a19edf3061078b Mon Sep 17 00:00:00 2001 From: Joost de Valk Date: Wed, 23 Sep 2026 10:00:57 +0200 Subject: [PATCH 2/2] Base funding manifest assessment on documented adoption --- src/content/considered/funding-manifest-urls.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/content/considered/funding-manifest-urls.md b/src/content/considered/funding-manifest-urls.md index ef95d3ea..734d6eb1 100644 --- a/src/content/considered/funding-manifest-urls.md +++ b/src/content/considered/funding-manifest-urls.md @@ -1,8 +1,8 @@ --- title: "/.well-known/funding-manifest-urls" date: "2026-09-23" -reason: too-narrow -revisit: "A second independent consumer reading funding.json — a package registry, a forge, or another funder — rather than one directory crawling for one grant programme. At that point the topic stops being 'how to be found by FLOSS/fund' and becomes 'how a project declares its funding needs machine-readably', which would be worth a page." +reason: too-early +revisit: "Documented use by independent consumers, such as another funder, a package registry or a forge, showing that domain-verified funding metadata provides a useful website convention beyond the currently documented FLOSS/fund tooling." sources: - title: "Well-Known URIs registry" url: "https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml" @@ -20,6 +20,6 @@ sources: `funding-manifest-urls` has been a **provisional** entry in the IANA Well-Known URIs registry since 2 April 2025, with `info@floss.fund` as change controller and `fundingjson.org` as its reference. It is not the funding manifest itself. The manifest — `funding.json`, a JSON document describing who maintains a project, what it needs money for, and how to send it — lives at an ordinary URL of the publisher's choosing. The well-known file is the proof of control that sits underneath it: a plain-text list, one URL per line, saying "these manifests are allowed to speak for this domain". A manifest hosted on `example.com` that claims a project at `project.net` is unverified until `project.net/.well-known/funding-manifest-urls` names it back. -The mechanism is sound and the scope test is close to passing: it is a file a content origin serves, it is checkable from outside, and cross-origin claims genuinely do need something like it. What it is not is a property of websites in general. It answers one question — how an open-source project proves a funding claim — for one audience, and it is read, in practice, by one crawler: the FLOSS/fund directory, built to distribute a single annual grant pool. Real projects have published manifests, F-Droid and MetaBrainz among them, so this is not a standard nobody uses. It is a standard used by everybody who wants that grant and nobody who does not. +This is a general funding metadata format for open-source projects. It can describe funding needs, payment channels and provenance independently of a particular grant application. The specification lists real publishers, including F-Droid, Python and OpenStreetMap, and links to the FLOSS/fund directory and validator as consumers. Those examples establish publisher adoption and a working use of the format. They do not establish that only grant applicants publish it, or that other funders cannot use it. -That makes it narrow rather than early, and the distinction matters for what would change our mind. Waiting longer will not help; more publishers joining the same directory would only make the same programme bigger. What would help is a second reader — a package registry, a forge, another funder — parsing `funding.json` for its own purposes. Domain-verified funding metadata that several independent systems consume is a website outcome. A manifest that one grant programme crawls is an application form with a URL. +For this specification, the remaining question is whether the convention has enough independent consumer adoption to recommend it to websites seeking funding. The sources reviewed document FLOSS/fund's tooling but do not establish broader consumption; that is an evidence limit, not proof that no other reader exists. We therefore record it as **too early** for a standalone recommendation. Documented use by another funder, a forge or a package registry would make the case stronger. Any future page would apply to project funding sites, rather than requiring every website to publish a manifest.