# 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 196314
# self = https://watcher.sour.is?offset=170099
# next = https://watcher.sour.is?offset=170199
# prev = https://watcher.sour.is?offset=169999
how little data is needed for generating the hashes? Instead of the full URL, can we makedo with just the domain (example.net) so we avoid the conflicts with gemini://, https:// and only http:// (like in my own twtxt.txt) or construct something like like a webfinger id nick@domain (also used by mastodon etc.) from the domain and nick if there, else use domain as nick as well
how little data is needed for generating the hashes? Instead of the full URL, can we makedo with just the domain (example.net) so we avoid the conflicts with gemini://, https:// and only http:// (like in my own twtxt.txt) or construct something like like a webfinger id nick@domain (also used by mastodon etc.) from the domain and nick if there, else use domain as nick as well
how little data is needed for generating the hashes? Instead of the full URL, can we makedo with just the domain (example.net) so we avoid the conflicts with gemini://, https:// and only http:// (like in my own twtxt.txt) or construct something like like a webfinger id nick@domain (also used by mastodon etc.) from the domain and nick if there, else use domain as nick as well
how little data is needed for generating the hashes? Instead of the full URL, can we makedo with just the domain (example.net) so we avoid the conflicts with gemini://, https:// and only http:// (like in my own twtxt.txt) or construct something like like a webfinger id nick@domain (also used by mastodon etc.) from the domain and nick if there, else use domain as nick as well
Wow, a blast from the past. Look at that Yarn version!
[47°09′08″S, 126°43′14″W] Weather forecast alert -- storm from SE
@lyse this one is hilarious 🤣
@lyse this one is hilarious 🤣
@lyse this one is hilarious 🤣
[47°09′58″S, 126°43′15″W] Reading: 0.66000 PPM
Parannoul - Beautiful World.m4a
[47°09′27″S, 126°43′47″W] Reading: 0.31000 PPM
@movq Peobably not and I wouldn't expect them to either 😅
@movq Peobably not and I wouldn't expect them to either 😅
But in all seriousness I've only ever wanted to improve Twtxt without sacrificing its simplicity too much.
But in all seriousness I've only ever wanted to improve Twtxt without sacrificing its simplicity too much.
@movq Sorry haha I didn't mean for it to sound like that 🤣
@movq Sorry haha I didn't mean for it to sound like that 🤣
mfw it says someone updated 1 days ago 👹
🧮 USERS:1 FEEDS:2 TWTS:1087 ARCHIVED:78676 CACHE:2491 FOLLOWERS:17 FOLLOWING:14
@lyse let’s do Drops of Jupiter too! (hopefully my markdown foo works, if not I am editing and breaking replies! 😅)
Video
@lyse let’s do Drops of Jupiter too! (hopefully my markdown foo works, if not I am editing and breaking replies! 😅)
@lyse let’s do Drops of Jupiter too! (hopefully my markdown foo works, if not I am editing and breaking replies! 😅)
@lyse oooooh! That one looks lovely too! Let me know when there is something to alpha/beta test. I am volunteering! 😊
@lyse This looks like a nice way to do it.
Another thought: if clients can't agree on the url (for example, if we switch to this new way, but some old clients still do it the old way), that could be mitigated by computing many hashes for each twt: one for every url in the feed. So, if a feed has three URLs, every twt is associated with three hashes when it comes time to put threads together.
A client stills need to choose one url to use for the hash when composing a reply, but this might add some breathing room if there's a period when clients are doing different things.
(From what I understand of jenny, this would be difficult to implement there since each pseudo-email can only have one msgid to match to the in-reply-to headers. I don't know about other clients.)
@lyse I just wanted to state that this is excellent news! Are you going to use some BubbleTea? 🙈
It’s been a little over 14 years since Isis broke up and I have yet to find a band as good as them. Not a single song that disappoints (at least since the Oceanic album). Glad I could see them live a couple of times. // Isis - Grey Divide // https://www.youtube.com/watch?v=eI2-8I3j4Vg #NowPlaying
It’s been a little over 14 years since Isis broke up and I have yet to find a band as good as them. Not a single song that disappoints (at least since the Oceanic album). Glad I could see them live a couple of times. // Isis - Grey Divide // https://www.youtube.com/watch?v=eI2-8I3j4Vg #NowPlaying
It’s been a little over 14 years since Isis broke up and I have yet to find a band as good as them. Not a single song that disappoints (at least since the Oceanic album). Glad I could see them live a couple of times. // Isis - Grey Divide // https://www.youtube.com/watch?v=eI2-8I3j4Vg #NowPlaying
It’s been a little over 14 years since Isis broke up and I have yet to find a band as good as them. Not a single song that disappoints (at least since the Oceanic album). Glad I could see them live a couple of times. // Isis - Grey Divide // https://www.youtube.com/watch?v=eI2-8I3j4Vg #NowPlaying
I'm finally continuing with my tt rewrite in Go. So, I thought I use the shiny io/fs.FS. That's supposed to be a super cool new file system API. It allowed me to write tests more elegantly. I don't have to place actual test files on disk, but can keep everything nicely in RAM with testing/fstest.MapFS. That actually worked out great, I do like that.
However, os.DirFS("/") for production code is just a terrible solution. I noted that OS paths and io/fs.FS paths are fundamentally different. This new API does not allow leading slashes in the passed paths. This results in an error. So, I have to cut the leading slash off myself.
Also, the whole thing is totally useless on Windows, because of the drives. Simply does not work at all. Well, honestly, I don't care the slightest bit about that operating system, but it would be nice if this concept were cross-platform.
I haven't tested it, but I'm pretty sure relative paths or ~ do also not work. I have to first build absolute paths myself. Unfortunately, there is no builtin helper to translate an OS path into a io/fs.FS path.
Of course, others noted these shortcomings and surprising results, too: https://github.com/golang/go/issues/44279 There is no OSFileSystem implementation that would simply allow the easy transition from all the classical os.* functionality to io/fs.FS. And they also do not wanna add something like that either. Sigh.
I'm really wondering what they were thinking when introducing this. :-?
Even though, it's very silly, I'm gonna keep using it. At least for now. Tests have been written. I'm not keen on rewriting them. Sigh.
[47°09′42″S, 126°43′00″W] Saalmi, retransmit, please
@lyse Brilliant idea! 😂 One way ticket to Venus please! 🤘
@lyse Brilliant idea! 😂 One way ticket to Venus please! 🤘
@lyse Brilliant idea! 😂 One way ticket to Venus please! 🤘
[47°09′31″S, 126°43′39″W] Reading: 0.31 Sv
@prologic Come on, that’s a little condescending, isn’t it? 😅
@prologic Come on, that’s a little condescending, isn’t it? 😅
@prologic Come on, that’s a little condescending, isn’t it? 😅
@prologic Come on, that’s a little condescending, isn’t it? 😅
[47°09′38″S, 126°43′50″W] --interrupted--
twts are immutable in the sense that a twt is its own identifier. you might think that a twt can be modified, but what's really happening is a delete and redraft operation. an edit would require you to append a special twt that says that old twt was actually meant to say this other thing, here's the twthash please hide my shame in the UI.
@movq Tbey all hate me for stomping on their precious dear twtxt 🤣
@movq Tbey all hate me for stomping on their precious dear twtxt 🤣
@lyse Hmmm interesting idea 🤔
@lyse Hmmm interesting idea 🤔
@prologic Oh, wait, there’s already another thread about it. 😅
@prologic Oh, wait, there’s already another thread about it. 😅
@prologic Oh, wait, there’s already another thread about it. 😅
@prologic Oh, wait, there’s already another thread about it. 😅
On second thought, the same rule with the last physically encountered URL when starting parsing from the top applies to prepend-style feeds as well. Much simpler and cleaner this way. Should also fit prepend-style feeds better I reckon.
[47°09′55″S, 126°43′06″W] 4160 days without news from Herve
@prologic @bender That's exactly the case here with us as well. Maybe not 100% applicable to yarnd, but all other clients that only fetch from their user-controlled subscription list.
@movq @prologic Oh yeah, we have to take our time with that and craft it very carefully.
My theory about the descent of the original twtxt universe is that a) people just move on to other things and b) it was just not practical enough.
Nicely put, @movq! Exactly, reminding people to subscribe etc. is dodgy. To me it feels they think their audience is dumb (and they might be right, I don't know). Super annoying.
@prologic No, it’s all just speculation and I don’t like spreading rumors. 😅 It would be more interesting to hear from the twtxt folks themselves why they stopped working on the original twtxt.
@prologic No, it’s all just speculation and I don’t like spreading rumors. 😅 It would be more interesting to hear from the twtxt folks themselves why they stopped working on the original twtxt.
@prologic No, it’s all just speculation and I don’t like spreading rumors. 😅 It would be more interesting to hear from the twtxt folks themselves why they stopped working on the original twtxt.
@prologic No, it’s all just speculation and I don’t like spreading rumors. 😅 It would be more interesting to hear from the twtxt folks themselves why they stopped working on the original twtxt.
@prologic
> the right way to solve this is to use public/private key(s) where you _actually_ have a public key fingerprint as your feed's unique identity that never changes
Okay, this is interesting. How would this work in practice? 🤔
@prologic
> the right way to solve this is to use public/private key(s) where you _actually_ have a public key fingerprint as your feed's unique identity that never changes
Okay, this is interesting. How would this work in practice? 🤔
@prologic
> the right way to solve this is to use public/private key(s) where you _actually_ have a public key fingerprint as your feed's unique identity that never changes
Okay, this is interesting. How would this work in practice? 🤔
@prologic
> the right way to solve this is to use public/private key(s) where you _actually_ have a public key fingerprint as your feed's unique identity that never changes
Okay, this is interesting. How would this work in practice? 🤔
@falsifian If the timestamp included a nanosecond part (which is *not* a valid twtxt feed at the moment, because it mandates RFC3339 timestamps and those only permit one subsecond digit), this could solve the editing problem with little effort. 🤔
Btw, @prologic, in my experience, people editing their twts is a much more common thing than people changing the URL of their feed. 😅 It breaks threading all the time.
@falsifian If the timestamp included a nanosecond part (which is *not* a valid twtxt feed at the moment, because it mandates RFC3339 timestamps and those only permit one subsecond digit), this could solve the editing problem with little effort. 🤔
Btw, @prologic, in my experience, people editing their twts is a much more common thing than people changing the URL of their feed. 😅 It breaks threading all the time.
@falsifian If the timestamp included a nanosecond part (which is *not* a valid twtxt feed at the moment, because it mandates RFC3339 timestamps and those only permit one subsecond digit), this could solve the editing problem with little effort. 🤔
Btw, @prologic, in my experience, people editing their twts is a much more common thing than people changing the URL of their feed. 😅 It breaks threading all the time.
@falsifian If the timestamp included a nanosecond part (which is *not* a valid twtxt feed at the moment, because it mandates RFC3339 timestamps and those only permit one subsecond digit), this could solve the editing problem with little effort. 🤔
Btw, @prologic, in my experience, people editing their twts is a much more common thing than people changing the URL of their feed. 😅 It breaks threading all the time.
Wow, there are a lot of ideas in this thread already. 😃
Wow, there are a lot of ideas in this thread already. 😃
Wow, there are a lot of ideas in this thread already. 😃
Wow, there are a lot of ideas in this thread already. 😃
[47°09′59″S, 126°43′30″W] Dosimeter overflow