# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 11
# self = https://watcher.sour.is/conv/gctrz4q
@prologic 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 1/4, it could get changed to ¼ in the twtxt.txt file for everyone to see, not just people reading through yarnd. But when I type 1/4, 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 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.
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.
@bender @prologic I'm not exactly asking yarnd to change. If you are okay with the way it displayed my twts, then by all means, leave it as is. I hope you won't mind if I continue to write things like 1/4 to mean "first out of four".
What has text/markdown got to do with this? I don't think Markdown says anything about replacing 1/4 with ¼, or other similar transformations. It's not needed, because ¼ is already a unicode character that can simply be directly inserted into the text file.
What's wrong with my original suggestion of doing the transformation before the text hits the twtxt.txt file? @prologic, I think it would achieve what you are trying to achieve with this content-type thing: if someone writes 1/4 on a yarnd instance or any other client that wants to do this, it would get transformed, and other clients simply wouldn't do the transformation. Every client that supports displaying unicode characters, including Jenny, would then display ¼ as ¼.
Alternatively, if you prefer yarnd to pretty-print all twts nicely, even ones from simpler clients, that's fine too and you don't need to change anything. My 1/4 -> ¼ thing is nothing more than a minor irritation which probably isn't worth overthinking.
@falsifian Only that this rendering behavior comes from yarnd's Markdown parser library that is used:
> What has text/markdown got to do with this? I don’t think Markdown says anything about replacing 1/4 with ¼, or other similar transformations. It’s not needed, because ¼ is already a unicode character that can simply be directly inserted into the text file.
@falsifian Only that this rendering behavior comes from yarnd's Markdown parser library that is used:
> What has text/markdown got to do with this? I don’t think Markdown says anything about replacing 1/4 with ¼, or other similar transformations. It’s not needed, because ¼ is already a unicode character that can simply be directly inserted into the text file.
> What’s wrong with my original suggestion of doing the transformation before the text hits the twtxt.txt file? @prologic, I think it would achieve what you are trying to achieve with this content-type thing: if someone writes 1/4 on a yarnd instance or any other client that wants to do this, it would get transformed, and other clients simply wouldn’t do the transformation. Every client that supports displaying unicode characters, including Jenny, would then display ¼ as ¼.
So many clients do client-side transformation already, mostly in the form of -mentions. e.g: If I @falsifian mention you, that gets transformed into the full proper Twtxt mention syntax. We _could_ in theory transform other things too, but I see little value in doing so? 🤔 -- Also it's probably more a "Client" recommendation anyway at that point right?
> What’s wrong with my original suggestion of doing the transformation before the text hits the twtxt.txt file? @prologic, I think it would achieve what you are trying to achieve with this content-type thing: if someone writes 1/4 on a yarnd instance or any other client that wants to do this, it would get transformed, and other clients simply wouldn’t do the transformation. Every client that supports displaying unicode characters, including Jenny, would then display ¼ as ¼.
So many clients do client-side transformation already, mostly in the form of -mentions. e.g: If I @falsifian mention you, that gets transformed into the full proper Twtxt mention syntax. We _could_ in theory transform other things too, but I see little value in doing so? 🤔 -- Also it's probably more a "Client" recommendation anyway at that point right?
> Alternatively, if you prefer yarnd to pretty-print all twts nicely, even ones from simpler clients, that’s fine too and you don’t need to change anything. My 1/4 -> ¼ thing is nothing more than a minor irritation which probably isn’t worth overthinking.
Yeah I've closed the PR, I just wanted to write it up and see what we all thought. Much easier to talk to a concrete spec proposal sometimes. I realised as I was writing it too that it wasn't really going to achieve much in practise. I think we all agree 👍
> Alternatively, if you prefer yarnd to pretty-print all twts nicely, even ones from simpler clients, that’s fine too and you don’t need to change anything. My 1/4 -> ¼ thing is nothing more than a minor irritation which probably isn’t worth overthinking.
Yeah I've closed the PR, I just wanted to write it up and see what we all thought. Much easier to talk to a concrete spec proposal sometimes. I realised as I was writing it too that it wasn't really going to achieve much in practise. I think we all agree 👍