💾 Archived View for carcosa.net › journal › 20230411-next-trick.gmi captured on 2024-08-24 at 23:52:34. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-04-19)

-=-=-=-=-=-=-

And now for my next trick

As of now, all of my personal side projects that I've shared are basically complete (I just have to add query support to Cosmarmot). Lately I've been playing with writing GTK4 apps in Common Lisp, my reasons being that I really enjoy the look of a well-designed GTK/Libadwaita application, especially one that supports responsive design for narrow windows and mobile, and fits in well in my Gnome desktop, and because the Common Lisp bindings are so good thanks to the very good GObject introspection bindings. I've done enough to start to get comfortable with writing GUI code, something that has never been my forté. The last time I dipped my toes in desktop GUI programming was writing panel widgets for Gnome 1 (!) in Python. I do feel like writing something fun in it, though.

I have two ideas, and I'm only probably going to work on one. Both of them are kind of unnecessary for their respective ecosystems, but each would add something that hasn't appeared or hasn't become common yet.

A Gemini client with publishing support

There is already a Gemini client for Gnome with excellent design, Geopard. It's not terribly full-featured, but it looks gorgeous, which makes me somewhat less interested in writing a GTK Gemini client *per se*. However, what if it facilitated posting, and discovering and signing up for a hosting provider?

This is an idea I've had for a while, with the goal being to make a cross-platform desktop app that is a complete Gemini publishing solution for new users (I know, I should get geminiquickst.art back up to date, especially considering that geminispace.info is going to go away). It would implement a protocol that server operators could implement the other side of, where a user can sign up for an account at any of several hosting providers from a drop-down, and after approval (approval process being up to the server admin), the user would receive a welcome email, and the user's client would receive a public key for sftp publishing to an autoconfigured host and directory. Honestly, though there are lot of details to get right, cross-platform is the hardest part.

The downsides to this one are that there are so many Gemini clients, I'm not convinced the world needs another one just yet, and that while I'm up for writing a server that implements the signup and publication protocol, it's not actually all that useful unless a critical mass of server operators sign up for it.

A Mastodon-API client with advanced sorting and filtering

The backend part of this is an idea I've had for a while, too. While I have sometimes enjoyed the Fediverse, in particular the Mastodon-adjacent parts, I've also missed the "score files" from good Usenet clients like trn and Gnus. Mastodon has decent blocking, muting, and filtering features, but they're not a patch on what Gnus can do. Instead of a binary block/don't block decision, you can up-score or down-score articles by subject, author, content, or a variety of other factors, and then sort your incoming articles by score. Have a friend that doesn't post a lot, but when they do, you don't want to miss it? Score them up by author. Have a topic that gets discussed a lot in your feed, that you're not super interested in, but not to the point of blocking or muting it — you might want to read about it when you're bored and out of other things to read — score it down by content. And you can keep track of individual articles' read/unread status, so that meme that everyone is re-sharing? You can see it exactly once, if you want.

I've written a Mastodon client before (brutaldon), but it was web based, and designed around the principle that it would store as little user data as possible, just an auth token attached to a username, and settings. A scoring client would have to save a lot of information, which means it really would have to be a desktop or mobile native client. brutaldon was limited to the transient, reverse-chronologically ordered stream provided by the Mastodon API. And the reverse-chronological stream is not all bad; it's certainly better than a black-box server-side algorithm determining what you see. But in a desktop client, we *could* do better. The Mastodon client API is not optimized for such a client (it serves you a reverse-chronological stream, 40 posts at a time, like it or not), but that could be worked around.

The downside to this one is that I'm not all that committed to the Fediverse anymore. I deleted my old accounts and handed over maintainership of brutaldon because I saw the same kinds of social dynamics that I disliked on commercial social media (gaining clout by attacking other users, tying real-world income to online clout-chasing). I've been back on since the Twitter implosion (though I was not even on Twitter at the time),and it's fine. It's okay. But do I have the love for it to maintain a substantial project? Maybe not.

Feedback wanted

I would absolutely love to hear feedback on this. I'll probably post a poll on my nerd Mastodon account (as opposed to my communist witch Mastodon account). I'll link to it when I do. But if you want to give me feedback otherwise, send me an email (jmcbray at carcosa dot net), or write a gemlog response and send me a link.