@prologic@twtxt.net It’s not “true” oncall duty (I don’t do that anymore, it fucks up your life and health), but more of an unwritten rule that sysadmins should have a smartphone. If there is an emergency and I happen to have time to help, I will. But nobody can force me to. So far, it works for us.
And, well, I also need that thing for 2FA. 😅
@prologic@twtxt.net I’m pretty much required to have one. 🫤
jenny,ttandyarnd...
@prologic@twtxt.net No, wait, I removed something else. But I think it was never supported in the first place. 😅 Probably because nobody used it (which is probably because you didn’t implement a UI for them 😅).
When will I learn to not look at my work’s smartphone in my free time? 😂 Opened the corporate chat, instant regret.
jenny,ttandyarnd...
@prologic@twtxt.net Weeeeeeeeeeeeelllll … I have removed support for that in jenny about a month ago. 🥴 Nobody ever used them, only hashes.
@lyse@lyse.isobeef.org One of them is lying. >:-)
Mangled in what way? How does it look like? 🤔
@cuaxolotl@sunshinegardens.org
i hope we don’t go chasing mass-appeal
I don’t think this is going to happen any time soon.
What makes twtxt unique is its radical technical simplicity. And that means you have to be a tech-savvy person to appreciate twtxt and that means mass-appeal is pretty much out of the question to begin with. 😅
Yarn adds a lot of user-friendliness and, in a way, does try to appeal to the masses. And it almost worked. When Twitter died, we saw a substantial influx of new users, didn’t we? Only problem is, Mastodon had a massive headstart. The Fediverse was already huge, so what did Yarn/twtxt have to offer? It is way simpler and way easier to self-host, but who cares about that? Right, the tech-savvy people, not the masses. Many of the tech-savvy people were already using Mastodon, though, and, frankly, “simplicity” is not something that a lot of folks even care about. Thus Yarn/twtxt never took off.
A nice afternoon. Mild weather (~23°C), sitting on the balcony, working a bit on jenny, and spamming twt’s. 😅
@quark@ferengi.one At the moment, the twt in question exists in the sixth archive:
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/6 | head
[o6dsrga] [2020-07-18 12:39:52+00:00] [Hello World! 😊]
Does that work for you? 🤔
@prologic@twtxt.net Yeah, that thing with (#hash;#originalHash) would also work.
Maybe I’m being a bit too purist/minimalistic here. As I said before (in one of the 1372739 posts on this topic – or maybe I didn’t even send that twt, I don’t remember 😅), I never really liked hashes to begin with. They aren’t super hard to implement but they are kind of against the beauty of the original twtxt – because you need special client support for them. It’s not something that you could write manually in your twtxt.txt file. With @sorenpeter@darch.dk’s proposal, though, that would be possible.
I don’t know … maybe it’s just me. 🥴
I’m also being a bit selfish, to be honest: Implementing (#hash;#originalHash) in jenny for editing your own feed would not be a no-brainer. (Editing is already kind of unsupported, actually.) It wouldn’t be a problem to implement it for fetching other people’s feeds, though.
@quark@ferengi.one Hmm. I cannot reproduce this. 🫤 I just removed all files in ~/.cache/jenny and ~/Mail/twt/cur, and a subsequent jenny -f properly fetches everything.
Do you see all the “Fetching archived feed …” messages?
Your propose scheme while simple doesn’t do this.
It doesn’t do that because it’s not taking the content of a twt into account (only its timestamp). Okay. But the mere fact that we’re talking about “how to solve the edit problem” stems from using content addressing – so maybe content addressing isn’t the best thing to use here? 🤔
ssh-keygen -Y sign or ssh-keygen -Y verify tools already available? Maybe in combination with @xuu 's idea of generating a random unique ID for your feed, say # id = and signing it with your ED25519 key? 🔑
@prologic@twtxt.net I’m very torn on this.
It’s a cool idea and it’s cool technology. It would (probably) even be fun to implement.
But do we need it? Or rather, does twtxt need it? What problem are you trying to solve – are people migrating their feeds to new URLs all the time? 🤔 That’s rather rare in my experience. The URL as the primary identifier of a feed works fine for me.
Maybe I just don’t understand the problem well enough yet? 🤔
jenny does fetch archived feeds during the normal
jenny -foperation […]
… but you need to use the current Git version which includes this commit:
https://www.uninformativ.de/git/jenny/commit/6e8ce5afdabd5eac22eae4275407b3bd2a167daf.html
There was a bug that broke on @prologic@twtxt.net’s feed. 🥴
Since
jennycan’t fetch archived twtxts
I wiped my entire maildir and re-fetched everything. I did that recently because @aelaraji@aelaraji.com asked me to 😅, but I guess I also did this back in 2023.
What did you do to make yours work?
jenny does fetch archived feeds during the normal jenny -f operation. Only when using the recently implemented --fetch-context, archived feeds are not fetched (yet). That was an oversight and I intend to fix that.
@quark@ferengi.one Ahh, I see:
Message-Id: <o6dsrga>
That’s an older format that was used before jenny version v23.04. It should look like this nowadays:
Message-Id: <o6dsrga@twtxt>
Changelog entry from back then:
v23.04 2023-04-19
[Changed]
- The format of the "Message-Id" and "In-Reply-To" headers has
changed. They now need an "@twtxt" suffix to be more compliant with
RFC(2)822. This fixes issues when using aerc
(https://aerc-mail.org/) as a frontend instead of mutt.
If you want to retain compatibility with existing files in your
maildir, you must manually add this suffix to these headers. (Or go
ahead and re-sync everything.)
I guess I could have added backwards compatibility to the code. Maybe I’ll fix that later. 🤔
@bender@twtxt.net Ah, haha, --fetch-context doesn’t go back into archived feeds … 🤦
The bug in jenny that @aelaraji@aelaraji.com found:
Jenny has to look for the metadata fields, it must find the # prev = ... line. To do so, I naively wrote something along these lines:
for line in content.splitlines():
if line.startswith('# prev = '):
...
Problem is, we use \u2028 a lot in twtxt feeds and Python interprets those as line separators as well. That’s not what we want here. Jenny must only split at a \n.
Now @prologic@twtxt.net had a quote/copy of some of his metadata fields in a twt. Like so:
# prev = foo bar
Perfectly legitimate, but now jenny found the # prev = twice (once in the actual header, once in a twt), didn’t know what to do, and thus did not fetch the archived feeds. 🤦
Should be fixed in this commit: https://www.uninformativ.de/git/jenny/commit/6e8ce5afdabd5eac22eae4275407b3bd2a167daf.html
This is a bug in jenny. 🤦
@prologic@twtxt.net Oh so that’s how it works? The front page only shows the latest twt of each feed? 🤔
No, something is fishy. It didn’t fetch @prologic@twtxt.net’s archived feeds and now only 969 of his twts are in my maildir. 🤔
@aelaraji@aelaraji.com Yep, I just tried. It’s not that easy to verify, though. 😅 It looks fine to me. The number of twts in the maildir has gone down from 61759 to 34787 – but that’s probably because I unfollowed lots of (presumably dead) feeds in the last few weeks. 🥴
@aelaraji@aelaraji.com What was going on here? 🥴 Wiping the maildir and ~/.cache/jenny should reset everything, it doesn’t store any other state. 🤔
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
I think I like this a lot. 🤔
The problem with using hashes always was that they’re “one-directional”: You can construct a hash from URL + timestamp + twt, but you cannot do the inverse. When I see #weadxga, I have no idea what that could possibly refer to.
But of course something like (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) has all the information you need. This could simplify twt/feed discovery quite a bit, couldn’t it? 🤔 That thing that I just implemented – jenny asking some Yarn pod for some twt hash – would not be necessary anymore. Clients could easily and automatically fetch complete threads instead of requiring the user to follow all relevant feeds.
Only using the timestamp to identify a twt also solves the edit problem.
It even is better for non-Yarn clients, because you now don’t have to read, understand, and implement a “twt hash specification” before you can reply to someone.
The only problem, really, is that (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) is so long. Clients would have to try harder to hide this. 😅
@lyse@lyse.isobeef.org I think I’m with you on this. 🤔 I mean, it’s a cool and interesting topic, but it also adds lots of overhead. (And I’m not yet convinced that we actually need it. People don’t change URLs on a daily basis (but they do edit twts all the time).)
--fetch-context thingy: It can now ask Yarn pods for twt hashes.
@quark@ferengi.one Yep, it’s a list, you can define several pods.
@prologic@twtxt.net Oh, interesting. It doesn’t serve JSON, though, does it? curl -s -H 'Accept: application/json' https://search.twtxt.net/twt/j7f652q gets me an HTML page. 🤔
@aelaraji@aelaraji.com Must be your bubble. All I hear is “AI this”, “AI that”. 😂😭
Alright, I saw enough broken threads lately to be motivated enough to extend the --fetch-context thingy: It can now ask Yarn pods for twt hashes.
https://www.uninformativ.de/git/jenny/commit/eefd3fa09083e2206ed0d71887d2ef2884684a71.html
This is only done as a last resort if there’s no other way to find the missing twt. Like, when there’s a twt that begins with just a hash and no user mention, there’s no way for jenny to know on which feed that twt can be found, so it’ll ask some Yarn pod in that case.
@prologic@twtxt.net Congratz 🥳
@lyse@lyse.isobeef.org Wow, those are some great shots. Fall is finally here! 😍 (Might be a bit exaggerated by my redshift. 😅)
That temperature drop was pretty sudden. Boom, cold, no warning. Give me some time to adapt, man! 😂
Speaking of public transportation, though: If it works, then it’s an amazing system. I love it.
I recently took the time to find an alternative route to one of my doctors. Hardly any people using that route and it’s faster. Absolutely brilliant. It’s like having a chauffeur. 😅
But navigating through that system is also a total nightmare. Which bus takes you to which places at which times, getting info about current construction sites, all that stuff. It takes forever.
And it doesn’t help at all that this is what their website looks like:
https://movq.de/v/acb23dc1c2/s.png
You can’t move that window at the bottom. It just sits there and takes up space from the map. It gets even worse: When you ask for a route, you get to see the buses and individual stops and all that – but all in that little window with that large font! Why do we all have widescreen monitors and than stack UI items vertically?
Sure, 30 years ago it was much worse. But it could also be much better today. 😅
@lyse@lyse.isobeef.org Gosh, that sounds so horrible. 🙈🤢
Another idea for the upcoming Advent Of Code 2024:
OS/2 Warp 4 came with Java and that not only meant a runtime but a JDK including API docs. So, for AoC, I could try to solve as many puzzles as I can in that environment, directly on my old Pentium. For later puzzles, I’ll definitely want to switch to my normal workstation for faster development cycles – but I can still use Java and try to backport the solutions.
Sounds interesting. 🤔
https://movq.de/v/81ac0142f2/1.ff.jpg
https://movq.de/v/81ac0142f2/2.ff.jpg
# follow_notify = gemini://foo/bar to your feed’s metadata, so that clients who follow you can ping that URL every now and then? How would you even notice that, do you regularly read your gemini logs? 🤔
@aelaraji@aelaraji.com Yeah, that’s pretty close to what was outlined here: https://twtxt.net/twt/ansuy4a 😅
I went straight to bed after posting this and slept for 3 hours. 😩 Can’t I just win the lottery and be done with this whole “money” thing? 🤪
@lyse@lyse.isobeef.org Oof, well, good luck. Those multi-day meetings are usually really exhausting (and mostly pointless) in our company, hopefully it’s different at yours. ✌️
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.
@lyse@lyse.isobeef.org Indeed, great news! If you need testers at some point, let me know. 😅
It’s one of those days.
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
Great, now I fell into a rabbit hole of “old” music. 😂 https://www.youtube.com/watch?v=PGNiXGX2nLU
@prologic@twtxt.net Come on, that’s a little condescending, isn’t it? 😅
url field in the feed to define the URL for hashing. It should have been the last encountered one. Then, assuming append-style feeds, you could override the old URL with a new one from a certain point on:
For the record, out of the 89 feeds that I follow, only a single one has more than one # url = field:
gemini://gemini.ctrl-c.club/~nristen/twtxt.txt
And I wonder if @nristen@gemini.ctrl-c.club is aware that the order of those fields matter. 🤔
@prologic@twtxt.net Oh, wait, there’s already another thread about it. 😅
@prologic@twtxt.net 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.
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@www.falsifian.org 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@twtxt.net, 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.