@prologic@twtxt.net I’m not a yarnd user, so it doesn’t matter a whole lot to me, but FWIW I’m not especially keen on changing how I format my twts to work around yarnd’s quirks.

I wonder if this kind of postprocessing would fit better between composing (via yarnd’s UI) and publishing. So, if a yarnd user types ¼, it could get changed to ¼ in the twtxt.txt file for everyone to see, not just people reading through yarnd. But when I type ¼, meaning first out of four, as a non-yarnd user, the meaning wouldn’t get corrupted. I can always type ¼ directly if that’s what I really intend.

(This twt might be easier to understand if you read it without any transformations :-P)

Anyway, again, I’m not a yarnd user, so do what you will, just know you might not be seeing exactly what I meant.

@falsifian@www.falsifian.org about this:

but FWIW I’m not especially keen on changing how I format my twts to work around yarnd’s quirks.

Yet, you are asking Yarn to change the format to work around how you want it display. 🤔

I think realistically the only way to resolve this is to formally support and define a specification for feed formats. The available mime types lists two formats that I think are important here. text/plain and text/markdown. I believe a specification that defines and formalizes this so that a feed author can state in their feed that their feed is primarily text/plain or text/markdown or via HTTP headers (not mandatory) will work here. I also think it might be worthwhile niversing this and defaulting to text/plain (by design and by default, spec TBD) and then clients like yanrd can just be updated to declare text/markdown.