I propose that we add a supported_mime_types list to the .configuration.statuses object in /api/v1/instance and /api/v2/instance, alongside max_characters, analogous to the existing .configuration.media_attachments.supported_mime_types list. Third-party clients would be able to look at this field and get a list of MIME types that they can author posts in.
Glitch supports text/plain, text/markdown, and text/html, and is not admin-configurable, so the values can be hardcoded as in example PR #2090.
If the field is missing (which it will not be in future Glitch versions, but will be in mainline Mastodon), and there is no out-of-band list of supported content types (like the one hardcoded into the Glitch web GUI), clients should not send a content_type parameter when creating a status, which is what they mostly do today anyway.
Motivation
This would benefit third-party native and web clients that want to support rich text post authoring using the content_type parameter to /api/v1/statuses. Right now, a client can use the instance API to discover the post length limit and supported image formats, but not supported post formats, or even that a given instance supports rich text through the content_type parameter.
I would directly benefit from this since I'm working on a community fork of Metatext and want to add rich text support without having to guess at it based on the version string of the instance server.
Alternatives
Pleroma and its forks use Pleroma-specific extensions to /api/v1/instance (a MIME type list in .pleroma.metadata.post_formats) to deliver the same information, so there may be clients looking for that, but it'd be weird to split status info (logically part of the .configuration.statuses) across the existing object and a Pleroma extension.
Ecosystem
mainline Mastodon: IIRC, Eugen still doesn't want rich text… but .configuration.statuses.max_characters is standard now, so maybe someday?
Hometown: the example PR should be usable on Hometown as well
Pleroma/Akkoma/etc.: see above, but could be patched to deliver the same MIME type list in the new location as well without breaking compatibility
GotoSocial: GtS doesn't quite handle rich text the same way that Glitch does; I've filed a suggestion to make them compatible in the future superseriousbusiness/gotosocial#1363
VyrCossont
commented
1 year ago
Pitch
I propose that we add a
supported_mime_typeslist to the.configuration.statusesobject in/api/v1/instanceand/api/v2/instance, alongsidemax_characters, analogous to the existing.configuration.media_attachments.supported_mime_typeslist. Third-party clients would be able to look at this field and get a list of MIME types that they can author posts in.Glitch supports
text/plain,text/markdown, andtext/html, and is not admin-configurable, so the values can be hardcoded as in example PR #2090.If the field is missing (which it will not be in future Glitch versions, but will be in mainline Mastodon), and there is no out-of-band list of supported content types (like the one hardcoded into the Glitch web GUI), clients should not send a
content_typeparameter when creating a status, which is what they mostly do today anyway.Motivation
This would benefit third-party native and web clients that want to support rich text post authoring using the
content_typeparameter to/api/v1/statuses. Right now, a client can use the instance API to discover the post length limit and supported image formats, but not supported post formats, or even that a given instance supports rich text through thecontent_typeparameter.I would directly benefit from this since I'm working on a community fork of Metatext and want to add rich text support without having to guess at it based on the version string of the instance server.
Alternatives
Pleroma and its forks use Pleroma-specific extensions to
/api/v1/instance(a MIME type list in.pleroma.metadata.post_formats) to deliver the same information, so there may be clients looking for that, but it'd be weird to split status info (logically part of the.configuration.statuses) across the existing object and a Pleroma extension.Ecosystem
.configuration.statuses.max_charactersis standard now, so maybe someday?