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

[Bcc'ed to the IETF main list to close the loop there and moved to the 
DISPATCH list.]

Kleines,

The best place for this discussion is likely on the list for the 
DISPATCH working group:

https://datatracker.ietf.org/wg/dispatch/about/

This seems like something that could conceivably go on the agenda for 
the 15 April online interim meeting.

<https://datatracker.ietf.org/wg/dispatch/meetings/>

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

On 28 Mar 2026, at 18:58, kleines Filmröllchen wrote:

> 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