@lyse@lyse.isobeef.org Ahh ok! I was just wondering and curious whether it was a bug that I’ve caused anywhere along the way 🧐

@prologic@twtxt.net A screenshot won’t help in this case, as you don’t see anything. :-D It starts off just fine with a conversation tree like that:

Unknown conversation root
└╴Read reply
  └╴Read subreply

Everything works. After reloading the feeds, a new message becomes part of the conversation, so the conversation e.g. looks:

Unknown conversation root
└╴Read reply
  ├╴Read subreply
  └╴Unread subreply

However, the bug is that the whole conversation is not shown at all. None of the three (or four with the root) messages appear in the message tree view. My recursive SQL determining the messages to display is clearly broken.

Ahh yes! Please do upgrade your twtd instance. Few things changed, many bugs fixed there too.

I should really fix this damn bug where new replies to read replies to unknown conversation roots are not showing up in tt. I run into this bug almost daily for weeks now.

@dce@hashnix.club Fixed! 🥳 That 403 was our bug — connect was checking your token via /api/v1/user (needs read:user), but your token’s scoped to just the repo so it can’t. Now it validates against the repo itself instead 👍

@david@daiwei.me I think it might be a bug i just fixed 🤞

@david@daiwei.me Found it. Some bugs in the “claim limiter”. Fixing…

based on this, it’s entirely possible that there may still be a subtle bug somewhere with the app

@movq@www.uninformativ.de please don’t waste your time to bugging this. I’ll figure out what’s going on with these new clients.🙏

Hurray, I can now press gg instead of g to go to the top in tt. Much better! :-) Other multi-key combinations are also easily possible now.

I should probably write a real article about this at some point, but here we go. The only downside with my new key binding system is that it breaks tview’s established pattern. You’ve got an InputHandler(), that is implemented using WrapInputHandler(…). It typically then directly implements the switching logic depending on the key press. Something like this:

func (w *Widget) InputHandler() func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {
    // WrapInputHandler allows for intercepting key events with SetInputCapture(…)
    // from the outside for customization. This handles the default key bindings.
    return t.WrapInputHandler(func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {
        switch event.Key() {
        case tcell.KeyRune:
            if event.Modifiers() == tcell.ModNone {
                switch event.Rune() {
                case 'k':
                    w.scrollUp()
                    return // we already handled the event, stop processing

                case 'j':
                    w.scrollDown()
                    return
                }
            }
        }

        // We didn't handle the key event. Maybe the parent
        // widget knows what to do with it.
        if handler := w.parent.InputHandler(); handler != nil {
            handler(event, setFocus)
        }
    })
}

From the outside, you can intercept and either stop or continue the widget’s original key handling with a potentially rewritten key event using SetInputCapture(…):

w := NewWidget()
// customized or additional key bindings
w.SetInputCapture(func(event *tcell.EventKey) *tcell.EventKey {
    switch event.Key() {
    case tcell.KeyUp:
        // Rewrite the event, so the "cursor up" key is an alias
        // for the vim key binding "k", that is handled by the
        // wrapped input handler above. (I know, I know, this is a
        // completely unrealistic example, why would anyone use
        // cursor keys when there are vim key bindings available?!)
        return tcell.NewEventKey(tcell.KeyRune, 'k', tcell.ModNone)

    case tcell.KeyRune:
        if event.Modifiers() == tcell.ModNone {
            switch event.Rune() {
                case 'q':
                    app.Stop()
                    // we already handled the event, do not pass it
                    // to the wrapped input handler above
                    return nil

                case 'r':
                    toggleMessageReadStatus()
                    return nil
            }
        }
    }

    // we didn't handle the event, pass it to the wrapped
    // input handler above
    return event
}

Since they all expect a single key, I’ve noticed that using multiple dedicated KeyBindings of mine on these different levels kinda breaks multi-key handling with common prefixes. The outer-most KeyBinding captures the prefix, but it can’t transfer it to the inner one if not handled by the outer one. At least not without some more (potentially ugly) changes. So, I now have to work with just a single KeyBindings object for the entire widget chain (if it consists of multiple other widgets or the regular input handler and input capture are in the game). The outside needs to register all its key bind customizations or extensions at the same level that the original widget handles its default ones. Doable by exposing the widget’s KeyBindings instance, but not pretty. You always have to keep this in mind.

With the KeyBindings, it will look like that:

type Widget struct {
    parent tview.Primitive

    // make it available to children or the outside either by
    // direct field access or by providing a getter method
    KeyBindings *bind.KeyBindings
}

func NewWidget() *Widget {
    w := &Widget{KeyBindings: &bind.KeyBindings{}}
    w.KeyBindings. // default key bindings
        Bind0(bind.KeySequence('k', w.scrollUp).
        Bind0(bind.KeySequence('j', w.scrollDown)
    return w
}

func (w *Widget) InputHandler() InputHandler() func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {
    return t.WrapInputHandler(func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {
        // also note the missing support for focus transfer at the moment
        event = w.KeyBindings.Capture(event)
        if event == nil {
            return
        }

        if handler := w.parent.InputHandler(); handler != nil {
            handler(event, setFocus)
        }
    }
}

And then from the outside, or in a child widget:

w := NewWidget()
w.KeyBindings. // additional or customized key bindings
    Bind1(bind.KeySequence(tcell.KeyUp), func(*tcell.EventKey) *tcell.EventKey {
        return tcell.NewEventKey(tcell.KeyRune, 'k', tcell.ModNone)
    }).
    Bind0(bind.KeySequence('q'), app.Stop).
    Bind0(bind.KeySequence('r'), toggleMessageReadStatus)

When directly working with tview primitives that are not part of custom widget implementations, the following works well so far:

textView := tview.NewTextView().
    SetWordWrap(true).
    SetText("…")
    SetScrollable(true)
textView.SetInputCapture((&bind.KeyBindings{}).
    Bind0(bind.KeySequence('q'), app.Stop).
    Bind1(bind.KeySequence('g', 'g'), func(*tcell.EventKey) *tcell.EventKey {
        return tcell.NewEventKey(tcell.KeyHome, 0, tcell.ModNone)
    }).
    Capture)

I need to sleep on this some more.

Also, writing very long messages like this one is really not all that fun in tt’s editor. I should absolutely provide a way to shell out to vim.

(Took me about one and a half hours to compose, holy crap. But not only because of not using vim. Although, that might have saved me a quarter hour or so for sure. Proof-reading this message also uncovered quite a few bugs in my real documentation. So, that’s a big win!) Good night!

I believe we’ve nailed all the bugs down🤣 Though i am sick at the moment so i’m not at my best 😢

@balloon-fu-sen@tw.fus.f5.si Ahhh! That’s a bug! Lemme fix that!

🥳 Finally! After nearly 4 years, yarnd v0.16.0 “Silver Sojourner” is out! 🚀 Twt Hash v2, SQLite FTS5 search, HTMX-powered UI, first-time setup wizard and literally hundreds of bug fixes 🐛

Release notes: https://git.mills.io/yarnsocial/yarn/releases/tag/0.16.0

Upgrading is fully automatic — the Twt Hash v2 migration re-fetches all feeds on first start, so expect the first cycle to be a bit heavier. Images on Docker Hub as prologic/yarnd:0.16.0 👌

cc @kat@yarn.girlonthemoon.xyz @abucci@anthony.buc.ci @shinyoukai@yume.laidback.moe @eldersnake@we.loveprivacy.club 🙏

@bender@twtxt.net No idea. I can only tell you that the correct hash would have been rwzz277nkyju for this line:

[2026-07-11 14:47:17+00:00] [(#5bpwpdcjnhcz) <a href="https://yarn.girlonthemoon.xyz/external?uri=https://daiwei.me/twtxt.txt">@david<em>@daiwei.me</em></a> (This thread is broken again on my end. Another bug or fix not released yet? 😅)]

@david@daiwei.me (This thread is broken again on my end. Another bug or fix not released yet? 😅)

I will aim to have most issues bugs and user experience problems, identified and fixed by this weekend!

And if we can compile a list and file issues for feeds, twtxt.app and anything else as issues for when i get back 🙏 feature requests, bug reports. etc 🤞

FYi 👋 I’m aware of an optimist precomputed hashing bug on the new twtxt.app 🤯 Trying to work with @bender@twtxt.net remotely on my vacation yo fix it 🤣

@movq@www.uninformativ.de I figure there is a bug somewhere, but where?

What’s the bug?

@movq@www.uninformativ.de we found a bug. @prologic@twtxt.net loves it!

I think I fixed this bug!

@lyse@lyse.isobeef.org Found it and fixed it! 🎉 The crawler’s discovery spider was fetching every feed a second time, without any conditional headers (plus a couple of other politeness bugs: redirected feed URLs never stored their cache validators, and there was no floor between re-fetches). Now every feed is fetched at most once per crawl, always with If-Modified-Since / If-None-Match, and never more than once per 15m no matter what. Just deployed — please keep an eye on your access logs and let me know if you still see anything impolite from the crawler 🙏

@lyse@lyse.isobeef.org Thanks! I’ll look into that! Could be a bug in the crawler.

Hey folks 👋 Today I announce the re-release of the Twtxt Search Engine now live and running and actively re-crawling and re-indexing. 🎉 Please report bugs or any useability issues to me! 🙏 #Twtxt #Search

My mate and I hiked up the backyard mountain. We got 25°C and quite some wind, so it was actually not too terrible. The wind could have blown harder or the temps a little lower, but oh well.

I saw the squirrel’s bushy tail stick up on the forest floor in the sunlight and immediately thought of this cute little feller. Since it didn’t move at all, even when we came closer, I got irritated and reconsidered that it might actually be some kind of dried up farn. But then we also were able to see its body. Unfortunately, the squirrel ran up the tree too quickly, so all the shots are kinda crap.

At one flower spot, there were sooo many butterflies, wasps, flies, bugs and other insects. The botanic was completely crowded.

The workers were transferring logs from one log truck to the other in a parking lot. I’ve never seen this happening before. When we passed the same place on the way home, they had moved logs into a sea container. That was surprising. This semi wasn’t there on the way there. One log was probably too long and sticking out the container, so they probably had to wait for somebody to return with a chainsaw. Crazy that they’re shipping logs from here probably overseas. Why else would they put them in a sea container?

After our first break, a blackbird was really posing for us with his worm in the dark shade.

Today was my first time I ever saw a hummingbird hawk-moth (Taubenschwänzchen) for real. My mate photographed them many, many times before, but I never came across one myself. So, that was really special.

The forest service installed an outdoor table with two benches next to the timber lion, that was cool to see. We sat down for a few minutes and enjoyed both the view into the Fils valley and ant on the tabletop, but the sun was beating down too heavily on us, so we had to move on.

All in all, it was a very nice few hours long hike. Enjoy! https://lyse.isobeef.org/waldspaziergang-2026-07-03/

@lyse@lyse.isobeef.org oh yes! And, when I mow the lawn (which reminds me I need to mow the front soonish), you can add dust, bugs, and grass blades to the equation. Just “lovely”. 😂

@lyse@lyse.isobeef.org If I were to guess: They might have done so to avoid bug reports from users with heavily outdated versions. 🫤

there was supposed to be a plus in there but it got eaten by a bug!

@lyse@lyse.isobeef.org Interesting approach. 🤔

The master branch should never be in a broken state (apart from bugs I don’t know about). Any intermediate state during the development of a larger feature will happen in a different branch.

I mean, yeah, but … I don’t know, I like having “traditional releases” as a second safety net when I write programs. I like to let things mature for a while and then I cut a new release. So it’s, like, “we have a bunch of new features and fixes here, and to the best of my knowledge this works fine now”. But maybe I’m just paranoid. 🤔

@movq@www.uninformativ.de Oh yeah, way better! :-) I didn’t spot the bug, though.

I think I could work with the feature set. I typically don’t need a lot. Until I do. :-D The message tree in tt is an example of that. But tt is also special that it needs something like this in the first place. It’s unusual.

(And of course there’s a bug because I’m an idiot. 🤪)

@itsericwoodward@itsericwoodward.com Turns out, this is a bug in my config to cache synchronization. Nickname changes in the configuration file are just not synced to the cache at startup if the feed URL already exists in the cache. I must have fixed this typo in my config ages ago, because I don’t even recall having that spelling mistake to begin with. Yet, the cache was happily showing the erroneous nickname. Composing a reply automatically adds the mentions from the conversation participants. Everything originates from the cache, so, I successfully poissoned my replies.

@movq@www.uninformativ.de Honestly I think you build the team before you need the PRs 🤔 Start with relationships — people who’ve been using your software, filing good bug reports, asking smart questions. Those are your future maintainers. The PR comes later as a formality, not a tryout 😅

(#vixabsa) @movq@www.uninformativ.de Honestly I think you build the team before you need the PRs 🤔 Start with relationships — people who’ve been using your software, filing good bug reports, asking smart questions. Those are your future maintainers. The PR comes later as a formality, not a tryout 😅

Yay finally fixed some of those annoying “Mark as Read” behaviours/bugs 🐞

I wasted my entire weekend on the writeup. If you have way too much time to spare and also are interested in a bug analysis of a software that you don’t even use, I have you covered: https://lyse.isobeef.org/newsboat-time-parsing-bug-analysis/

Oh boy, it was bloody humid this morning. Just around 20°C when we left, but climbing rapidly. The flow of air when walking was okay, but as soon as we stopped, streams of sweat were pouring down on us. Luckily, it was cloudy, but the lack of wind was bad. Now, the sun is out, 29°C will be reached in an hour and I’m glad that the house is still cool. It will be a different story in a few weeks or months. Not looking forward to that at ll.

On the bright side, we saw the first tadpoles of the year and an also first, but sadly dead slow worm that probably some bird dropped on a bench next to the fountain. The fly was stuck to its feast and also cactus. The municipality fixed the railing nicely and we came across a giant patch of great looking fire bugs on the summit.

All in all, a successful stroll through the woods but for the humid heat.

https://lyse.isobeef.org/waldspaziergang-2026-05-30/

@prologic@twtxt.net Ahh, I see. Okay, I’m with you there. On this high level, I can understand how the thing works.

Maybe my wording isn’t good. 🤔 Let’s take a real life example from what we do at work.

There’s this AI chatbot. It gets support requests from users, so the user says something like “I need access to a particular system”. This triggers the bot to “run” the instructions stored in a large Markdown file, like “check if the user is authorized to do this, then issue the following API requests”, and so on. This is essentially like running a little script, except it’s written in natural language (German) and there’s no “script interpreter” but just the AI.

Now, suppose that the AI doesn’t quite do what was intended. There’s some subtle bug. How do you debug this? How do you find out how the AI came to the “conclusion” to run step A instead of step B? And how do you find out how exactly you have to change your prompt so this doesn’t happen again next time?

If this was an actual script/program instead of AI, you could repeat the request and attach a debugger or throw in some printf() or whatever. How do you do that kind of thing with AI? How do you pinpoint exactly what the problem was?

(Or is this just a stupid idea? Do we have to give up that way of thinking when using AI? Is the era of debuggability over?)

Aha, yesterday’s newly added support for LC_TIME to render localized timestamps also broke the feed parsing with my LANG=de_DE.UTF-8 and LC_CTYPE=de_DE.UTF-8 environment. :-)

Atom feeds make use of RFC 3339 timestamps. They are first converted into RFC 882 timestamp representation, which is the one that RSS feeds use. However, this conversion now results in localized RFC 882 timestamps, which cannot be parsed into Unix timestamp numbers via curl_getdate(…). I bet that it doesn’t know about the localization at all and expects English month and weekday names. Looking at its docs, I reckon that function was selected because of its myriad of supported timestamp formats: https://curl.se/libcurl/c/curl_getdate.html RFC 3339 is not included, though, hence the transformation up front.

The intermediate Item objects in the parser domain use std::string for the timestamp representation. This isn’t all that silly, because Newsboat supports all sorts of different feed formats with different timestamp formats. These RFC 883 timestamps are centrally parsed into time_t.

Speaking of time: It’s time to go to bed after this late bug hunting fun. :-)

You didn’t change your Atom feed by any chance yesterday or today, @movq@www.uninformativ.de? Not only do I have a metric shitton of “new” old items in my YouTube feeds, but also a bunch of your old articles are shown as new.

I fear that this is a Newsboat bug. I rebuilt it yesterday from master.

Eehhh, what the hell is going on here!?

SELECT
    printf("0x%x", (1 << 63) - 2),
    printf("0x%x", (1 << 63) - 1),
    printf("0x%x",  1 << 63     ),
    printf("0x%x", (1 << 63) + 1),
    printf("0x%x", (1 << 63) + 2)

SQLite yields:

0x8000000000000000 (instead of 0x7ffffffffffffffe)
0x8000000000000000 (instead of 0x7fffffffffffffff)
0x8000000000000000 (correct)
0x8000000000000001 (correct)
0x8000000000000002 (correct)

Huh!? O_o Am I stupid? What am I missing here? Or is this actually a bug? :-?

With 62 bits, everything is spot on:

0x3ffffffffffffffe
0x3fffffffffffffff
0x4000000000000000
0x4000000000000001
0x4000000000000002

And 64 bits rather unsurprisingly also yield:

0xfffffffffffffffe
0xffffffffffffffff
0x0
0x1
0x2

What do the Gopher Troopers think of the following? The Gopher protocol is a nearly-forgotten network protocol from the early 1990s, designed to serve and navigate text-based menus and documents over the Internet. While it’s far less common than HTTP/HTTPS today, there are still some security risks associated with Gopher and Gopher space. Let’s break them down carefully: 1. Lack of Encryption Problem: Gopher was designed long before widespread use of SSL/TLS. All data—including credentials, file transfers, and menu selections—is transmitted in plaintext. Impact: Anyone intercepting traffic (e.g., via a network sniffer, public Wi-Fi, or a compromised router) can read sensitive information, including usernames and passwords. 2. No Authentication or Access Control Problem: Gopher servers rarely implement robust authentication; access control is usually limited or non-existent. Impact: Unauthorized users might browse sensitive directories or download private files, particularly if servers are misconfigured. 3. Server Software Vulnerabilities Problem: Modern OSes can still run legacy Gopher servers, but the software is often unmaintained. Impact: Old software may contain buffer overflows, directory traversal bugs, or command injection vulnerabilities that attackers could exploit. 4. Malicious Gopher Links Problem: Gopher menus can contain links that point to scripts or other servers, similar to hyperlinks in HTTP. A client following a malicious link could inadvertently: Download malware Access sensitive internal network resources (server-side request forgery) Impact: Could serve as a vector for attacks if a user opens content from untrusted sources. 5. Legacy Protocol Weaknesses Problem: Gopher lacks modern web security mechanisms like: Content security policies Same-origin policies Cross-site request forgery protection Impact: If Gopher is bridged to other services (like modern browsers via gateways), old vulnerabilities may be exposed. 6. Information Leakage Problem: Gopher servers often provide directory listings without restriction. Impact: Sensitive files, backup directories, and internal documents may be exposed unintentionally. 7. Bridging Risks Problem: Some modern browsers access Gopher via gateways (HTTP-to-Gopher proxies). These bridges may: Expose sensitive internal resources to the gateway Introduce logging or tracking that wouldn’t exist on pure Gopher Impact: Attacks could occur indirectly through insecure intermediaries. Key Takeaways Gopher is inherently insecure due to its design in a pre-HTTPS era. Main threats: eavesdropping, unauthorized access, malware delivery, and exploitation of unpatched server software. Safe practice: Use Gopher only in isolated, trusted environments, or through secure HTTP(S) gateways with proper sanitization.

@rdlmda@rdlmda.me Oh boy, what a story! The infrastructure is indeed in need of overhaul. I’m glad you were so lucky in these circumstances.

(Btw. you posted the same message twice with just five seconds apart. I’m replying to the later one. Not sure if this is a client bug (like attempting to edit) or just operator error. ;-))

Hmm I think it’s a bug in the Javascript. It’s meant to be ![title](url)

@movq@www.uninformativ.de Luckily, I’ve never encountered any bugs in Vim with my type of work and features I use.

@bender@twtxt.net That’s the plan! Once I’m happy with this v1 (and we find no other obvious bugs/issues) updating “Changes” with user-facing / human-freidnyl changes is part of the release process!

Heh I thought I fixed that bug? (is it s abug?!)

@lyse@lyse.isobeef.org Bah. Yeah, that looks like a bug. Let’s see if this already reported upstream. 🤔

Hurray, I finally fixed another rendering bug in tt that was bugging me for a long time. Previously, when there were empty lines in a markdown multiline code block, the background color of the code block had not been used for the empty lines. So, this then looked as if there were actually several code blocks instead of a single one.