Edit history

when a link to the Fediverse is rendered by Fluxer, and that post has custom emoji, it just shows as the :emojiname: markdown. this is despite both platforms supporting inline pictograms in general, and despite both using nearly identical syntax for it. take, for example, this post and how i observed it rendering in Fluxer. Screenshot_20261021-131818.png compared to how it is supposed to look Screenshot_20261021-131931.png and how Fluxer already renders the same underlying markdown natively, when it doesn't go through the link embedder Screenshot_20261021-134430.png

I'd love for Fluxer to be able to properly fetch these posts and render them somewhat consistently, and in particular support the inline custom emoji, as those are the main formatting that is nontrivial to faithfully embed, yet still entirely possible without extending Fluxer markdown

getting rich information is somewhat nontrivial because you need to fetch over ActivityPub, which i believe in general requires being an ActivityPub server due to some servers requiring "authorized fetch". maybe on such posts Fluxer could just fall back to the existing behaviour or give up; or maybe there could be a way to configure a "fedi proxy" for link previews (e.g. in my case where my server is already on ActivityPub; so i don't see why i shouldn't let Fluxer piggyback off that if it makes link embeds render better) also i'm not requesting generalized fedi formatting or faithful embedding. there are SO MANY IMPLEMENTATION QUIRKS and the Misskey family of software can express very esoteric formatting options that are not at all convertible to Fluxer's content model. i entirely expect that any "mfm crimes" post (or CSS crimes from Wafrn/Tumblr/Cohost(rest in peace) ) will look broken in a Fluxer embed, just as they already look broken for half the users on fedi itself. but the custom emojis are fairly standardized across fedi and work very consistently between all major implementations. and they correspond nearly 1:1 to Fluxer's content model. they're just absolutely not standardized for use across the Web more generally. which is why they don't work in the link previews based on HTML processing.

when a link to the Fediverse is rendered by Fluxer, and that post has custom emoji, it just shows as the :emojiname: markdown. this is despite both platforms supporting inline pictograms in general, and despite both using nearly identical syntax for it. take, for example, this post and how i observed it rendering in Fluxer. [[file:Screenshot_20261021-131818.png]] compared to how it is supposed to look [[file:Screenshot_20261021-131931.png]]

I'd love for Fluxer to be able to properly fetch these posts and render them somewhat consistently, and in particular support the inline custom emoji, as those are the main formatting that is nontrivial to faithfully embed, yet still entirely possible without extending Fluxer markdown

getting rich information is somewhat nontrivial because you need to fetch over ActivityPub, which i believe in general requires being an ActivityPub server due to some servers requiring "authorized fetch". maybe on such posts Fluxer could just fall back to the existing behaviour or give up; or maybe there could be a way to configure a "fedi proxy" for link previews (e.g. in my case where my server is already on ActivityPub; so i don't see why i shouldn't let Fluxer piggyback off that if it makes link embeds render better) also i'm not requesting generalized fedi formatting or faithful embedding. there are SO MANY IMPLEMENTATION QUIRKS and the Misskey family of software can express very esoteric formatting options that are not at all convertible to Fluxer's content model. i entirely expect that any "mfm crimes" post (or CSS crimes from Wafrn/Tumblr/Cohost(rest in peace) ) will look broken in a Fluxer embed, just as they already look broken for half the users on fedi itself. but the custom emojis are fairly standardized across fedi and work very consistently between all major implementations. and they correspond nearly 1:1 to Fluxer's content model. they're just absolutely not standardized for use across the Web more generally. which is why they don't work in the link previews based on HTML processing.