# 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 6523
# self = https://watcher.sour.is?uri=https://lyse.isobeef.org/twtxt.txt&offset=1134
# next = https://watcher.sour.is?uri=https://lyse.isobeef.org/twtxt.txt&offset=1234
# prev = https://watcher.sour.is?uri=https://lyse.isobeef.org/twtxt.txt&offset=1034
@fastidious Is she walking so slowly or recording videos with her photo camera? :-)
@prologic Good to see @xuu's lextwt finally rocking without any alternative! :-)
@prologic Good to see @xuu's lextwt finally rocking without any alternative! :-)
@movq If I understood RFC 5005 correctly, the current and an archive feed are two separate things, there's no overlap between them. So an item is either in the current or in the archived, but not in both. So a symlink is not enough. But of course we could change that for our purpose. Regarding meta data changes, not sure how to go about them. Changing the nick is probably no problem, but changing the URL causes twt hashes to break again. The never ending story.
@movq I agree, browsers are terrible.
@xuu Yes, I just pushed them together with a fix: https://git.mills.io/yarnsocial/yarn/pulls/484 Please have a look. I'm not super satisfied with it, it looks a bit more complicated than it should be, but I have no idea how to simplify it even further. Maybe you can come up with something. :-) Btw, our new shiny Metadata Extension Specification limits keys to alphanumeric, hyphens and underscores, but the implementation here permits even more. I'm very impressed with your lexer modes, xuu, they saved me from a ton of work! :-) /cc @prologic
Definitely a bug in the parser. I came up with several failing test cases. Now to actually understanding the parser code so I can also fix it.
@movq I'm using Firefox with the Tridactyl extension. Vimperator was waaaaaaaaaaay better, but Mozilla replaced XUL with their newest coolest shit, so this extension didn't work anymore. >:'-( Haven't found anything better so far. Maybe I need to have a look at Uzbl, Brave and all these others again.
I'm writing a cgo bridge for lextwt to be used from within Python and I might have discovered a bug parsing empty values in metadata comments. Obviously it could also just be a problem in one of my C briding code. Let me dig deeper.
@movq @thecanine Correct. Fixing typos would be the only allowed thing, but that's it. Clients who have fetched a certain archive feed may not redownload this particular one again in the future since it's considered stable/fixed/frozen/unmodifiable. So people might not get any updates from this archive feed.
@movq „Alle anderen waren mir zu anstrengend.“ :-D
@prologic Nice setup, looks very professional, too!
@prologic Ta, well, this project got started before I even wrote my first twt. ;-) It's going on the stair-head.
@prologic @movq Basically yes. RFC 5005 makes a very interesting and subtle distinction between paged and archived feeds. Archive feeds are stable and navigating in them guarantees that no result will be duplicated or missed. On the other hand, paged feeds are not required to fulfil this property. The JSON Cursor Pagination is more like archived feeds. I reckon that we can use the archive approach, too. It suits us quite well, since we probably split off pages/archives by date ranges. Prologic might be the only one whose feed needs a max twts limit over a grouping by date. :-D So prev/next should do. Btw. I find it quite weird that RFC 5005 calls the link relations previous and next for paged but prev-archive and next-archive for archived feeds. Do we want to tie any paging/archiving semantics to that? Also use first and last? Too bad that link is already taken as titled hyperlinks in the metadata. What are your thoughts?
@prologic I haven't touched that little helper for months. And I also didn't upskill on packaging. But if you want to transfer it to your yarn organization, please do so. :-) One thing I want to add some day is to automatically fetch the Who Follows Resources and thus get a more accurate list on the followers. Another nice thing would be to highlight followers you're not following yet. But that is a bit more involved as the sources differ from client to client. So an intermedite format would be needed I reckon.
Slow progress on the bench: https://lyse.isobeef.org/tmp/bank.jpg I think we started pretty much exactly one year ago and the timebers have moved quite a bit. It's blocking the paths in the workshop ever since.
Slow progress on the bench: https://lyse.isobeef.org/tmp/bank.jpg I think we started pretty much exactly one year ago and the timbers have moved quite a bit. It's blocking the paths in the workshop ever since.
@prologic I fear so, too. Two weeks ago he told us that arrakis was no more. ;-)
@prologic Yes, this time I wasted about two hours on sorting. Needed some breaks here and there, so in total three hours. For just a two and a half hours hike that's a long time. It always depends on how many photos I have to go through, yesterday was definitely on the very extreme end. And then there's the occasional fix in post with the fuzz in my lense (I should try to disassemble and clean it). I talked to a fairly local old fellow on his bike at the bridge and he told me they're going to pave tomorrow on Wednesday.
@fastidious>, is your other feed at @fastidious now back online again and should be followed or is this just some temporary test thing?
@adi @thecanine Go for it, it has huge potential: It could become THE major platform for bosses to check before inviting candidates to job interviews.
@thecanine Haha, no worries mate. Glad to seed some inspiration. :-)
@thecanine Oh, okay. Thanks for the explanation! I like the light jacket more than the uniform, so good job. ;-) And to throw in another animal, the uniform dog reminds me of a bear. ;-)
@adi It's the small things in life, eh? ;-)
@thecanine Yup, I meant you. Nice colors now! Sorry, might be a completely dump question (I don't have any dog expertise), what kind of trousers is this dog wearing? The bushy tail now reminds me of a fox or squirrel. 8-) Nevertheless, I like it.
@movq Oh, right, this feed. Well, if you detect some garbage (unparsable twts) with the range request, you can always fall back to a complete request. It probably works most of the time, but there are certainly plenty of pitfalls you can come across. You might detect the order of the feed and then formulate your queries accordingly. Maybe if you construct the range so that the last seen twt will be refetched, you can detect whether the request was off and a full sync needs to follow. Some metadata changes might be missed with the range request if the amount of bytes didn't chance, but fully querying the feed once a day/week/whatever might take care of that – if metadata are actually of any use to jenny. But it's getting complicated really quickly. So maybe some kind of pagination/archive would be easier.
Down to 92 in round one. Still a long way to go.
Hiking alone in the woods really sucks. Now I have to sort through 452 photos. /o\
Hiking alone in the woods really sucks. Now I have to sort through 452 photos. /o\\
@jlj, last week I cleared of weeds after – I don't know – maybe half a year. ;-) Brilliant, @movq and @thecanine! :-D Despite the name I always saw a bunny in your avatar. :-S
@movq @prologic Maybe we need some kind of feed paging. E.g. next and prev metadata pointing to other URLs or something along those lines. Not sure if there are even some standard HTTP headers for that of thing. I think Podlove did something similar for podcast feeds if I'm not mistaken.
@movq The original Twtxt File Format Specification says: "A specific ordering of the statuses is not mandatory." So range requests are getting problematic if feed authors don't append but prepend – or even worse, randomly sort – new twts. To be fair, most if not all (I don't know) feeds I found so far are in append style. Another thing: If the metadata header at the top is expanded, range requests might skip new twts. I just want to emphasize that this apparently simple problem might get really tricky quickly with its tons of edge cases.
@prologic @jlj Looks like a completely different person to me. :-D
@off_grid_living Did I understand that correctly? You're not installing the horizontal bars individually, they're mounted to a rack structure and the rack is then screwed to the timber supports? Can't imagine vertical bars for towels.
@off_grid_living Hang on, your towel rails are going to end up horizontal, right? So I assume you have several rails stacked (that's why this vertical support is so long) and the photo just shows the left or right upright.
@thecanine It appears for _italics_ you just need a single asterisk or underscore. Double always make it bold.
@prologic @thecanine Nice! Ah, the mobile client lets you enter multiline text? I don't use it, I just turned the <input> into a <textarea> to reproduce this. Now the mobile client just needs to interpret the Unicode LINE SEPARATORs back to real newlines. Somebody else has to do that.
@movq Then no need to even sew anything. ;-)
@movq Yuck, this looks yummy. :-D But looks like it can really end up nicely. Cool closeups btw.
@prologic Turns out that this is not tt's fault, but the official twtxt client which I'm still relying on has the if created_at > now: raise ValueError("Tweet is from the future") check. So tt just never saw them. Fixed locally.
@prologic Oh, the font size is quite small. But I blame the browser's default settings. ;-)
@prologic I didn't experience any future twts from her myself, so not sure. But @movq's theory sounds plausible. Now that I write these lines I think I discovered a bug in tt which throws away future twts. Let me address this quickly.
@prologic, so this mechanism only works for yarnd (or others who update their avatar URL). Most other users probably just update their avatar image and don't bother with the URL. Maybe HEAD the external avatar once a day/week to see whether something changed. I think a lot of people don't want to be distracted by animations in avatars, @thecanine, that's why plenty of sites don't support it.
@movq I was about to suggest the same. Cutting and sewing is the best option.
@prologic Hmm, not sure what's the matter with small screens. It's just a <figure> and and <figcaption>. Should work everywhere. Just resized my browser and it looks alright. Haha, English is an obscene language. :-D
@prologic Should the original error be wrapped so you get a bit more information on the cause?
Yeah, @movq, I'm thinking the same. What do you mean, @prologic? Names are in the shiny new image descriptions (I just extended my script for that). Both German and English.
@movq Ta, I'm glad the fabulous adept approves of my botching. :-D
@prologic @thecanine The only problem with time-based approaches is that if a feed is down for some reason (or just not fetched in time) you might miss older twts you haven't seen. Depending on the use case that might even be a feature to ignore outdated content. In my client I just mark every twt read and the next time I start it, all fully read conversations will be hidden.
@prologic This sheet lightning looks really nice.
@prologic I agree on a release process. However, I'm not so sure on the code signing part. M$ lately signed rootkits again. So it's more a false sense of security. Could be a different story for your own code, though, as there's no other party involved. Need to think about that a bit more.
@prologic :-D Don't get me wrong, the idea isn't bad at all, maybe just needs slight tweaking. Like maybe showing the new unread twts in that conversation if you're logged in. But I think there's no concept of read/unread twts in yarnd, so well, probably won't work, but could be useful I reckon. It's just an appearance issue.
@prologic So that's not too bad. But skimming over Cache.FetchTwts(…) reveals that the cache isn't touched when the parsing of the feed fails. Assuming that an invalid feed produces an error (might be wrong, didn't investiage any further), the cache is not populated, triggering a fetch each time somebody visits the profile.
@prologic I reckon the metadata should certainly be honored. Only if that is unsuccessful fall back to the trial and error search. Maybe also limit the attempts to find an avatar to a smaller subset of filenames. Do you have any numbers on (un)successful filename discoveries?
@prologic Do you have any numbers on how often that happens? Maybe viewing a profile should not immediately fetch the feed but only if the feed hadn't been fetched in say the last five minutes or so. Otherwise it just displays its empty cache. Or will this empty result set trigger the fetch?
@fastidious It was dramatic, indeed. I completely felt like @darch, the red circles were too encroaching in my opinion, just like ads. Warning, click me! Fix me! You need to act now! Don't miss out! And all it was was an informational number. Especially since twtxt.net puts great stress on a calm and unagitated user experience with no push notifications and things like that, it just looked exactly like the opposite. Your blue version over on arrakis.netbros.com is a completely different deal, it fits much better but still raises too much importance on the number for my taste.
@prologic Auto updates are one the worst things in the world in my opinion. They always update at the wrong point in time which is not only very inconvenient but also often breaks stuff and then you're fucked for at least a moment. It adds useless complexity to the software. The most terrible thing, however, is undermining security in my opinion. Don't do it.
@off_grid_living Uuuuuuuh, very nice bedtime sweet, thanks mate! So you're turning it with a pipe wrench then? Happy fitting!
@darch Didn't know what you're talking about until I visited twtxt.net. Agreed, this looks really wrong!
We had a colorful sunset just now: /home/lyse/pictures/abendhimmel-2021-10-22/
@movq Nice, off with that shit!
@movq Thanks! Yeah, not sure why I can't hold my camera straight. :-( I rotated it 2° to the left, now the sign post is pretty much vertical and the horizon horizontal. In case you're interested in the original versions: 1[15]{,-gedreht}-original.jpg
@prologic So does yarnd try to fetch this "feed" now periodically or just at the very first time or when somebody tries to view the profile?
@prologic @quark So tt just renders this mention as an unfollowed feed as I expect. I can then open the URLs view manually and follow the "feed". But that would be a manual step, tt doesn't fetch anything automatically. I don't think you can't really do something about it. Maybe the URL was valid at the time or will become valid in the future. Valid as in a valid twtxt feed.
@quark I quite like autumn storms, but when the wind rattles the shutters it's getting quite loud.
@prologic Hmm, what do you mean by "rebuilding by hand"? I think it's best to just write everthing directly in HTML. No processing required. I don't think there will be frequent updates.
@movq Ah, I see. Yes, the fallback would still be needed and thus, doesn't really change the world. In fact there are now two ways to produce message IDs and if one client doesn't adpopt to the new message ID field, conversations are forking themselves automatically in a rather ugly way.
@quark It is then a very different format, though. Not twtxt anymore. All the extensions we're having now are still backwards-compatible to the original spec. Granted, they don't really work without client support, but technically it's still compatible. At the moment I'm not sold on redoing everything. But a version 2 would allow to fix a couple of things. E.g. feed relocation and stuff like that.