Internet-Draft: Informative I-D for Well-Known button.json

Hello everyone,

https://datatracker.ietf.org/doc/draft-filmroellchen-lunar-well-known-button/ 
is an Informative RFC for a /.well-known/button.json file on webservers. 
This file provides information about so-called “buttons”, 88x31 images 
that “advertise” the website owner. Quoting from the introduction:

 > Buttons originate from the early days of the Web as a form of banners,
 > originally representing the site or technology used to host a particular
 > home page. The 88x31 format, also named “Micro Button”, originated with
 > the free hosting provider GeoCities.com and their mandatory advertising
 > banner. [...] Buttons have
 > seen a renewed surge in popularity in the 2020s with certain
 > subcultures.

 > The goal of this specification is to provide a clearly defined standard
 > for web site authors who wish to share web site buttons with other web
 > site authors and end users, and lay out a format for a common endpoint
 > that can be used to fetch and/or embed the buttons. [...]

The standard originated with Arch Retriever in May 2024: 
<https://floofy.tech/@arch/112461865365597998>. This was quickly 
followed by a period of activity and spec development by multiple 
beings. I (kleines Filmröllchen) discovered the specification in March 
2026 and started an effort to integrate requested features as well as to 
prepare the Internet Draft you are reading now.

Among the modern-day users of “buttons” (mainly in the tech-focused 
transgender/queer/furry online communities), the specification has seen 
some adoption, and tools exist to utilize its automation capabilities, 
such as <https://git.gay/green/smol-tiny-spider> (a spider crawling 
button.json implementors). This demonstrates the need for this 
specification, even if only in a limited community. Nevertheless, the 
specification is general enough to allow any website owner to utilize it 
if they find it useful. The aforementioned 88x31 format is not 
mandatory, for instance.

As mentioned, several beings contributed to the development of this 
specification over the past two years, and this Internet Draft would 
have not been possible without them. The Contributors section contains a 
near-exhaustive list of direct contributions to the specification. 
Nevertheless, as editor I will be the main contact point for the 
development of the Internet Draft.

Feedback is greatly appreciated, especially on the following matters:

  * The SHA256 file hash has been introduced in the second 2024 draft
    and kept here for backwards-compatibility with the 2024-06 spec, but
    I myself take issue with it, especially in regards to the possible
    security concerns of the hashing algorithm, the availability of HTTP
    caching for button images, and the substandard compactness of the
    hex representation in comparison to Base64. If this is a desired
    feature, I will keep it, but otherwise, I am not against removing
    it. As it stands, the JSON Schema and the standard itself are open
    to nonstandard extensions, which this would then become.
  * The JSON Schema Internet-Draft expired in 2022, though the standard
    is well-established, in widespread use, and has a supporting
    independent body. According to a quick skim through the mail
    archives, it appears to me that using JSON Schemas normatively in
    other RFCs is acceptable
    (<https://mailarchive.ietf.org/arch/msg/regext/_bKRP4-rE3dA594vHtBuFpV24JA/>).
    If this is not the case, I’m happy to either point the Normative
    Reference for JSON Schema to the one at json-schema.org, and/or
    degrade the JSON Schema in this draft to RECOMMENDED.
  * Similarly, the spec normatively references several outside standards
    bodies: AOM, SPDX (Linux Foundation), WHATWG, W3C, and Unicode. The
    first two I haven’t yet observed in any IETF standard, but I hope
    they are OK.
  * I would appreciate if you raise any existing issues with the
    registration of this well-known URI with IANA. From my reading of
    the relevant RFC, there are no obstacles.
  * The four recommended image formats are somewhat opinionated, but
    reflect current practice. Most implementors use PNG or GIF, some
    insist on or default to GIF for its historical dominance in 88x31
    buttons, and BMP and others have been seen in the wild:
    <https://sdomi.pl/img/button.bmp>.
  * The recommended licenses may likewise be considered opinionated, and
    this section can be removed or altered to represent IETF consensus
    better. I think it is useful to provide informative guidance to
    implementors, referencing widespread art licenses like the Creative
    Commons family.
  * An Implementation Considerations section is missing and could
    definitely be added, topic suggestions welcome.
  * The migration guide is supposed to support existing users of the
    non-IETF spec. It can be removed if it is not appropriate.
  * Intended status is Informational, as I believe there is too much
    burden with normative references around a Standards-Track RFC, so I
    won’t bother with that unless convinced otherwise.

PS: I was not able to find a more specific mailing list for this topic, 
so I am posting to the general one. Please inform me if an appropriate 
WG or other mailing list exists.

Best Regards,

kleines Filmröllchen, Author and Editor, on behalf of Lunar Eclipse and 
all contributors