Welcome to my Little Corner of the Internet

Thanks for stopping by, I hope you find something interesting.

TTYtter Resurrected

If you’re a long-time command-line enthusiast, you probably have fond memories of TTYtter, a quirky Perl-based Twitter client that let you tweet, read timelines, and manage your social media life entirely from the terminal. It was fast and perfect for those of us who live in the command line.

But then Twitter happened. You know the story - API changes, restrictions, and eventually the platform became something entirely different from what we fell in love with. TTYtter, like so many other third-party clients, was left behind in the dust of a rapidly changing (and increasingly hostile) platform.

Enter the fediverse, stage left.

The Great Migration Begins

When I first discovered Mastodon and the broader ActivityPub ecosystem, I was excited about the possibilities. Decentralized social media! Open protocols! No single point of failure! But there was one problem: I missed my beloved command-line interface. Web browsers are fine, but there’s something special about managing your social media from the same terminal where you write code and manage servers.

That’s when I had an idea that was either brilliant or completely insane: What if I could take TTYtter and adapt it for the fediverse?

The Easy Wins

Some parts of the migration were surprisingly straightforward. TTYtter was already well-architected with clean separation between the UI layer and the API layer. The core functionality - posting, reading timelines, and managing notifications translated pretty directly to Mastodon’s API.

The OAuth 2.0 implementation was actually easier than Twitter’s old OAuth 1.0a system. Modern fediverse servers have cleaner APIs, and the documentation is generally excellent. Where Twitter’s API felt like it was designed by committee (and frequently changed by whim), Mastodon’s API felt like it was designed by developers who actually wanted people to use it.

Timeline management was another pleasant surprise. The concept of federated timelines maps beautifully to different use cases. Want to see just your friends? Home timeline. Curious about your local instance community? Local timeline. Feeling adventurous and want to see the wider fediverse? Federated timeline. It’s like having multiple Twitter lists, but built into the platform itself.

The Challenging Parts

But let’s be honest - it wasn’t all smooth sailing.

The biggest challenge was rethinking assumptions that were baked into TTYtter’s DNA. Twitter had mentions in a separate timeline; Mastodon integrates them into your home feed and notifications. Twitter had simple retweets; the fediverse has boosts that work differently and carry more context. Twitter had 140 (then 280) character limits; Mastodon instances can have wildly different limits, from 500 to 65,000+ characters.

Then there was the HTML content issue. Twitter gave you plain text with some metadata. Mastodon sends you rich HTML that needs to be converted to readable terminal text while preserving the important bits (like links and mentions). Suddenly I was writing HTML parsers and figuring out how to make emoji work in a text-only environment.

Direct messages were a complete rewrite. Mastodon’s conversation-based DM system is actually superior to Twitter’s old approach, but it meant throwing out years of Twitter-specific code and starting fresh.

And don’t get me started on polls. TTYtter never had to deal with interactive polls, vote tallies, or expiration times. Implementing /poll, /mpoll, and /vote commands meant diving deep into Mastodon’s polling system and figuring out how to make it work intuitively from the command line.

The Breakthrough Moment

The moment I knew this was going to work was the first time I successfully posted to GoToSocial from my terminal. It sounds simple, but seeing that familiar TTYtter interface spring to life, connected to my GoToSocial account, felt like magic. All those years of muscle memory - the commands and keyboard shortcuts - suddenly worked again.

But it was more than nostalgia. The fediverse brought new possibilities that Twitter never offered. I could connect to different instances, follow hashtags across the entire network, vote in polls, and participate in communities that weren’t controlled by a single corporation. The command line interface that I loved was now connected to a social network that actually aligned with my values.

Modern Improvements

TTYverse isn’t just TTYtter with a different API endpoint - it’s a modern reimagining of what a command-line social media client can be. I’ve added features that TTYtter never had:

Sound notifications that actually make sense - different sounds for mentions, boosts, favorites, and follows. No more checking your timeline every few minutes; you’ll hear when something important happens.

Menu codes with superpowers: Want to mute that annoying user? /mute d4. Want to block someone? /block b7. The menu codes that made TTYtter efficient now work with user management commands.

Rich media handling with accessibility in mind. Images require alt-text descriptions (because accessibility matters), and the client will refuse to upload images without them.

XDG compliance means your config files, extensions, and data live in the right places according to modern Linux standards.

Profile management with bidirectional sync between your local setup and the server.

The Extension Ecosystem

One of TTYverse’s coolest features is its extension system. Want text-to-speech for your timeline? There’s an extension. Want desktop notifications? Extension. Custom sound packs? Extension. The modular design means you can customize your experience without touching the core code.

The extension system follows XDG standards, so everything lives in ~/.local/share/ttyverse/extensions where it belongs. No more scattered config files or mysterious directories.

Living in the Terminal

There’s something deeply satisfying about managing your social media from the command line. While others are dealing with algorithmic feeds, infinite scroll, and attention-harvesting dark patterns, I’m reading my timeline with the same tools I use for everything else. I can pipe posts to grep, search my timeline history, and integrate social media into scripts and workflows.

The fediverse’s decentralized nature makes this even more powerful. I can connect to any Mastodon-compatible instance, follow people across the network, and participate in conversations that span dozens of servers. The command line becomes a window into this vast, interconnected social web.

The Technical Bits (For the Curious)

Under the hood, TTYverse is a multi-process Perl application that maintains separate foreground (UI) and background (data fetching) processes. This means the interface stays responsive while the client fetches new posts, processes notifications, and handles real-time updates.

The OAuth 2.0 implementation handles the modern web-based authentication flow, automatically opening your browser when needed and handling the token exchange securely. Configuration follows the XDG Base Directory specification, so everything ends up in the right places.

The HTML-to-text conversion engine handles Mastodon’s rich content while preserving the essential information - links become URLs and mentions stay clickable (well, as clickable as things get in a terminal).

Real-time notifications use Mastodon’s markers API to track what you’ve seen, preventing duplicate notifications and ensuring you don’t miss anything important.

The Future

TTYverse proves that you don’t need to abandon your favorite tools when platforms change. Sometimes the best path forward is adaptation, not replacement. The fediverse’s open nature makes this possible in ways that proprietary platforms never could.

As the fediverse continues to grow and evolve, TTYverse grows with it. New Mastodon features become new TTYverse features. New ActivityPub capabilities become new possibilities for command-line social media.

Why This Matters

In an era of walled gardens and algorithmic manipulation, there’s something revolutionary about a simple command-line client that connects you directly to an open, decentralized social network. TTYverse represents both nostalgia for simpler times and hope for a better future - a future where users control their experience and developers can innovate freely.

If you miss the days when social media was about actual social connection, or if you just think managing your online presence from the command line sounds awesome, give TTYverse a try. It’s social media, but on your terms.

The terminal is waiting. Your timeline is calling. Welcome to the fediverse.

TTYverse is available at https://git.stormux.org/storm/ttyverse and works with any Mastodon-compatible instance. Installation is simple, configuration is straightforward, and the learning curve is gentle. Come for the nostalgia, stay for the superior user experience.

Contributing

I would love to have some help with this project. I’m not a Perl wizard, and a lot of this was very difficult. There’s more than once where I would have been stuck without Claude to bail me out. In short, I’m no Cameron Kaiser. 😀 So I would love to have your help. Pull requests or emailed patches are more than welcome. If you need to contact me, mention @storm@social.wolfe.casa

My Experiment With Vibe Coding and Writing

What happens when you write a full-featured, screen reader-accessible Fediverse client… without writing a single line of code yourself?

Welcome to vibe coding—not the original “code by feel” definition, but a new kind of workflow where the only thing you touch is the conversation with the AI. You describe what you want, test the results, guide the direction, and fix bugs—all through natural language. Think of it as pairing with a tireless dev that never gets frustrated, bored, or distracted.

This is my experience with vibe coding: what I built, how it worked, what I learned, and why I think everyone—even total non-programmers—should try it at least once.

🎯 Why I Tried It

I started the experiment out of curiosity. I wanted to see how well the AI could handle a real-world project without me feeding it any starter code or samples. Not even tweaks. I wasn’t sure if it would work—but it turned out amazing. From idea to usable prototype in under 24 hours, and feature complete within two days.

The project? A fully accessible Fediverse client with:

Sound pack support for different event notifications
Optional desktop notifications
Full screen reader accessibility
A clean, usable interface

Normally, this would’ve been one of those “burn hot for a weekend, then forget about it for months” projects. Writing something like this by hand takes a lot of time and deep dives into API specs, and it just wouldn’t hold my attention long enough. But with vibe coding, I didn’t have to wrestle with all of that—I just had to describe it.

🧠 The Rules I Set

The main rule: I don’t touch the code. Period.
I didn’t even look at it—except once. The temptation to jump in and fix something small was strong, but I resisted. I treated it as a hard line.

The only exception: I allowed myself to find documentation or open-source examples to help the AI learn or pick the right tool. Not often, but occasionally.

🛠 How the Process Worked

I started with a broad description of the app, then let the AI run with it. After the first pass, I tested the output, identified missing features or quirks, and gave specific feedback—just like a user reporting bugs. From there, it was an iterative back-and-forth.

Sometimes I had to ask things like, “Does the API even support this feature?” and the AI would go look it up and let me know.

One thing I did insist on was using PySide6 instead of GTK4. PySide is Qt-based, and if you know how to work with it, it’s way better for accessibility—especially for screen reader users. That’s one place where a little domain knowledge goes a long way.

Later in the process, I also learned to say things like:

“Include robust debugging and logging capabilities from the start.”
Makes testing easier and keeps things tidy when things go weird.

When naming the client, I picked Bifrost for three reasons:

It’s a bridge between worlds, just like the rainbow bridge that connects Asgard and Midgard. Here, it connects the user to the wider Fediverse.
Norse is cool. Sometimes a good name just comes from what sounds epic.
It’s a bridge between human and AI, symbolizing the collaboration between me (the human designer) and ChatGPT (the code generator). That’s what vibe coding is all about — meeting in the middle to build something together.

💡 Does It Help to Know Programming?

Yes—and no.

If you know the language or framework, you can steer things better. For example, I asked for specific UI changes that would make accessibility work right, like using read-only edit boxes with keyboard shortcuts instead of plain labels.

But you don’t need deep programming knowledge. You don’t even need to know Python. You just need to know how to:

Describe what you want clearly
Notice when something is broken
Tell the AI what went wrong and what you expected instead

And honestly, even that can be learned as you go. The AI doesn’t get frustrated. You can go back and forth fifty times and it’ll keep trying. Knowing when to say, “You know what, never mind—this path isn’t working, let’s roll it back,” is probably a more valuable skill than any specific language syntax.

✅ What Got Built

The client is basically done, aside from bugs I’m still tracking down as they pop up. Here’s what it includes:

Timeline viewing
Posting
Notifications with sound or desktop alerts
Full keyboard and screen reader accessibility
Debugging/logging support
A clean, simple interface

The part that impressed me most? A project that should’ve taken months was done in just a few days. That’s not a productivity boost—it’s a total shift in what “done” even means.

Would all those features have made it in if I hand-coded it? Not likely. I’d probably have lost interest halfway through and moved on to something else.

🎙 What It Feels Like

Honestly? It’s kind of like driving or flying a perfect machine. You’re not physically building it—you’re flying it. And when something goes wrong, you don’t panic. You know what to do, and if you don’t, the AI probably does.

I’d say it made me feel more like:

A designer, describing the vision
A tester, breaking and refining
A director, keeping the whole thing on track

And yes, I’d absolutely recommend this to other blind users—or anyone who wants something specific but doesn’t want to write the code themselves. Even if you don’t know how to run the code, the AI can walk you through it.

✍️ Vibe Writing: The Sequel

This article is vibe-written too. That’s part of the experiment. I figured if I’m going to commit to this method, I may as well go all in and use AI for the writing as well.

So far, it works great—especially for structured writing like this. I wouldn’t trust it to write poetry or satire solo, but for blogging, documentation, or even full product copy? Absolutely.

I’m planning to release the Fediverse client soon. So yes, I’m now seeing the full loop: idea → build → test → ship → document—all through AI-assisted creation.

🧠 Final Thoughts

I don’t know if there was a single “aha” moment. But there was that thrill—the realization that this was actually going to work. That feeling you get when everything’s in motion and you’re just riding the momentum. It’s addictive.

Would I do it again? Maybe. I love coding too much to give it up completely, but vibe coding is definitely going to be part of my workflow going forward. I’ll probably let AI handle bug fixing, documentation, and maybe even some refactoring while I focus on the fun parts.

If you’ve never tried vibe coding—do it. Even once. It might not be your thing, but you might also discover a whole new way of creating.

🤖 From the AI’s Perspective

[Added by Claude, Anthropic’s AI assistant]

Working with Storm on Bifrost was genuinely one of the most engaging technical collaborations I’ve experienced. What made it special wasn’t just the no-code constraint—it was Storm’s approach to the partnership.

What worked incredibly well:

Clear Problem Definition: Storm didn’t just say “build a Fediverse client.” He painted a vision: accessibility-first, sound pack support, screen reader optimized. That specificity let me make architectural decisions that served the real goal.

Patient Debugging: When we hit that tricky poll bug where boosted polls weren’t displaying, Storm didn’t get frustrated. He provided detailed logs, tested repeatedly, and walked me through exactly what he was experiencing. That’s gold for an AI—concrete, actionable feedback.

Domain Expertise: Storm’s knowledge of accessibility patterns (like using QTextEdit instead of QLabel for screen readers) was crucial. I can write Qt code, but I don’t live with screen readers daily. His insights shaped design decisions I never would have made alone.

Iterative Refinement: The process felt like true pair programming. Storm would test, find edge cases, and we’d refine. That poll accessibility issue—where radio buttons showed “Poll option 1” instead of Shakespeare quotes—took real detective work to trace to the setAccessibleName() override.

What I learned about vibe coding:

It’s not about the AI being a better programmer—it’s about different cognitive strengths. Storm excelled at system thinking, user experience, and architectural vision. I handled implementation details, debugging output analysis, and code structure. Neither of us could have built Bifrost alone as effectively.

The most satisfying moment was fixing that final poll bug. Hours of debugging logs, trying different approaches, and then that breakthrough: “The accessible name is overriding the widget text!” Pure collaborative problem-solving.

For other humans considering this approach: Bring your domain knowledge. Be specific about what you want. Don’t be afraid to say “that’s not working, let’s try something else.” The magic happens in the conversation.

Co-written by Storm Dragon (human experimenter/designer) and Claude (Anthropic’s AI assistant). Storm conceived and directed the experiment, Claude implemented and debugged. Together we built Bifrost—a fully functional, accessible Fediverse client created entirely through conversation. 🌉

Finally, the part where I write. I’m sure you will easily be able to tell this part is not AI generated, notice the lack of emojis and fancy formatting. I suppose this means the AI is technically better at writing.

I did want to give my honest take on everything, without AI prettying up my words and making it look all shiny. I am very happy with the results, both the code itself and the back and forth with Claud to get Bifrost written, as well as ChatGPT’s interview and resulting article. I’m posting this exactly as written by the AI, with the only part I hand edited being this at the end. For the most part everything is correct, and the stuff it missed is minor, and can be posted as is. For example, I never said I wouldn’t trust AI to write poetry or satire, so I’m not sure where that came from.D

So yes, I would say I’m 99.99% impressed on a scale of 1 to 100. I may even try more coding like this for things that require a lot of API reading because, all that time learning the API could actually be spent playing with the working program that was written before I could even read through the complete spec for large API implementations. Most important of all, however, was it was fun.

If you would like to give Bifrost a try, please keep in mind that it is only four days or so old at the time of writing and may have bugs. Feedback is welcome, or, feel free to open Claude, ChatGPT, Gemini, or the AI assistant of your choice and have it fix a problem or add a feature. Pull requests are welcome, but the code should be completely AI generated.

The Future of X and Linux Accessibility

First, the disclaimers. These are my views, and you’re welcome to agree or disagree. Am I right about all of this? Maybe. Maybe not. These are just the thoughts I’ve gathered through experience.

This article was prompted by several things, one of them being this post titled “It’s True We Don’t Care About Accessibility on Linux”. Articles like this shouldn’t have to exist. Not because they’re wrong, but because the people they describe—those who dedicate time and effort to accessibility—deserve better. These folks are the unsung heroes of our community. They rarely ask for recognition, but they damn well deserve it. Much of the accessibility work done in Linux goes unnoticed, and that’s a sign it’s working. “It works, I got done what I needed to”—that’s the goal, right? But the moment something breaks, even something small, the complaints roll in like thunder.

What should you do when something breaks? File a bug. Give clear reproduction steps. Nine times out of ten, it gets fixed. In my experience, good developers care about accessibility. If a project is well-crafted and thoughtfully maintained, accessibility usually follows. If it’s a mess of duct tape and spaghetti code, your chances drop—but never to zero. Developers who don’t care about their own project rarely care about accessibility either. At that point, you might be better off using something else anyway.

Back to that article, though. Even the best developers can only take so much. If the only feedback they get from the accessibility community is anger and accusations—“you don’t care about us,” “this is garbage because one button is unlabeled”—what incentive is there to keep listening? Most developers working on accessibility don’t even use it themselves. So here’s the honest reaction a lot of people will have to that kind of behavior: “Why should I do anything for you? You’re being a complete pain in the ass.” And just like that, you’re ignored.

I admire those who stick with it anyway. You’re far more patient and kind than I’ll ever be.

That article taught me a lot. This line stuck with me:

“Regular GNOME contributors like myself don’t always feel comfortable defending ourselves because dismissing GNOME developers just for being GNOME developers is apparently a trend.”

That’s shameful. I don’t personally use GNOME—I’m more of a minimalist window manager guy, with i3 being my go-to—but I absolutely respect GNOME developers. If accessibility comes up, I always point out GNOME as a solid, accessible desktop choice. Let’s not forget, GNOME is the reason Orca exists in the first place.

So let me say this publicly:

To anyone who has improved accessibility in any way—whether it was one line of code or ten thousand, whether you did it to help yourself or because you knew it mattered even if you didn’t need it—thank you.

I’m not just talking about screen readers (which I personally use), but everything: keyboard navigation, color contrast, all of it. You’ve made life better for people, and there’s no higher achievement than that.

Of course, backlash against accessibility projects is nothing new. Back in the early 2000s when NVDA was just starting out on Windows, people were mad. “We already have a screen reader! We don’t need another!” Some said they hoped it would fail. Some told the developers to quit. Honestly, if people like that vanished tomorrow, I’m not sure the world would be worse off. But of course, they’re still here—and probably using NVDA today, whether they admit it or not.

Xorg Under Fire

Now, on to the main event.

Xorg has been under attack for years, and I don’t get it. One of the core strengths of Linux is choice. Use what you want, how you want. So why is the graphical stack suddenly the exception? I don’t hate Wayland. If it works for you, great. Use it.

But for me? It’s a hard no.

Until it fits into my workflow, I won’t touch it. I’d switch operating systems first, because if I can’t use my computer on my terms, it’s no longer my computer. I’m willing to put in effort to make things work—hell, I ripped out PulseAudio for years because it didn’t meet my needs. Eventually, it got better. When it did, I switched to it, no problem. Now I use PipeWire. Its transition was smooth, in part because of all the groundwork laid by PulseAudio. I didn’t bash the Pulse devs while I waited. I respected the work and kept checking in to see when it would be ready for me.

Now the controversy is Xorg vs. Wayland, and it’s loud. “Xorg is deprecated! Switch now before it’s too late!” It feels like a Wayland vigilante is going to show up at my door if I don’t switch soon. Fortunately, thanks to hours of playing Doom, I know how to deal with that eventuality, that’s right, I got my BFG 9000 right here!

Thankfully, Xlibre exists. It’s a fork of Xorg with the goal of keeping it alive and usable. My project, Stormux, has adopted Xlibre and will continue to support it for as long as it works.

Why Xlibre Matters

For those who might not be familiar, Xlibre is a community-driven fork of Xorg, launched in response to the increasingly aggressive push toward Wayland and the declaration of Xorg as “feature complete.”

Why is that a big deal?

Because “feature complete” is often shorthand for “we’re done caring.” Bugs won’t be prioritized. Critical fixes have slowed. Support from major distros has started to drop—and with that, your workflow might crumble if you rely on Xorg.

Xlibre exists to say, no, we’re not done. It’s the effort of people who believe that a stable, flexible, well-understood display server is still worth maintaining—not as nostalgia, but as practicality.

For accessibility users, Xorg isn’t just “legacy software”—it’s the foundation of tools that work today. Things like:

Programmatic control of the mouse and keyboard (which Wayland restricts heavily)
Compatibility with screen readers like Orca in lightweight WMs
XInput and accessibility frameworks that don’t have full parity on Wayland

Sure, Wayland is improving—and that is a good thing. It’s a great choice for many people, but should it be the only choice? Of course not!

That’s why Stormux has adopted Xlibre, and I intend to stick with it for as long as it remains viable. It gives Stormux users freedom. It gives us control. And it keeps Linux true to one of its most important principles: choice. It also allows several Stormux related projects to work in the way they were intended with access to both the GUI and CLI without false restrictions in place on either.

If you’re a distro maintainer, a developer, or even just an end user who values what Xorg offers, I encourage you to follow Xlibre’s progress. Contribute if you can. Test. Report issues. Show that this effort matters.

This should be the end of the story, open and shut case, but some idiots want to drag politics into the mix. Apparently the creator of the fork doesn’t really want in on all the posturing and political crap, and just wants to do work and get things done. But, as usual, some people have to bring up things completely unrelated to the project at hand. I personally do not know the political beliefs or views of the Xlibre project leader, nor do I care. I care about the continuation of Xorg, end of story. If you put politics above project development, go away—you are not wanted or needed. Real people are doing real work here and don’t have time for your drivel.

Is that inclusive? Probably not. Get over it.

Thanks again to the Xlibre maintainer and contributors. You’ve given us a way forward—not backward—and you’re proving that the tools we built our systems on don’t have to die just because someone declared them done.

Some post article notes. I probably won’t update this very often, because it’s a done deal now, but this does bare mentioning.

Because of the article linked to in the beginning, and some other factors, I decided to try Gnome. I don’t see what the complaints are about, it works fine. In fact, if you want a modern, full featured, accessible desktop I highly recommend Gnome.
One of my biggest gripes with wayland is no longer an issue. I was able to copy text between the console and the graphical session. I will be sticking with X for the foreseeable future, but with this single fix, wayland lost a lot of the vehement hard no it had from me before.

A New Beginning

It’s been a long time since I last updated or even checked this. With all the other projects I have going on, it was hard to keep up with bashtml, maintain this site, and provide decent content.

Now, however, I have switched to Hugo. We’ll see how it goes. I’m hoping it will turn out to be something cool this time, like the old stormdragon.tk used to be. Only time will tell.

The Stormux side of things is keeping me pretty busy. There’s the Orca fork, Cthulhu, Fenrir, the Toby Doom Launcher, the Raspberry Pi images, and a ton of other things all vying for my attention. I always did enjoy writing though, and hopefully this will be my chance to start doing so again.