A little while ago, I wrote a thread on glitch.social about ephemerality of posting on social media as compared to Usenet. It got a little bit of traction, and one person asked if I could post more about Usenet clients. I haven’t gotten to it until today, and I thought I would post on my blog instead of on glitch. The original thread wasn’t really about Usenet clients; it was mainly about how posts on Usenet expired, which is contrary to people’s current expectations about social media, but actually worked very well. You can read the thread at the link above and then come back. I expect this article to still be here, though you never know.
The extremely high quality of the clients available for Usenet, as opposed to those for current social media, is what I want to talk about in today’s article. I’ll start with a micro-refresher on the architecture of Usenet, as it was back when I used it, and for all I know, it’s the same today. At the time I used it, practically all servers and clients used NNTP. It was still possible to use a client that directly accessed the news spool on the server it was running on, and if you had the right gateway, it was still possible for a server to get its news feed over UUCP, but both of those were in the minority. When you posted an article to a newsgroup, your client posted it to your server, which put it in the local spool, and also, eventually, to any of its neighbors that carry that newsgroup. Your server would eventually receive posts to the groups it carried from everywhere, and make them available to your client. It’s basically the same as the #fediverse, though Usenet feeds have tended to be more hierarchically-ordered than the connections between fediverse servers — your server tended to only have one parent server it got its feed from.
The big difference in user experience was the clients. Most fediverse clients are either web-based, or mobile, though there are a few native desktop clients. Most Usenet clients were TUI programs (though desktop GUI clients were available later on). But despite this difference, which might initially make the Usenet clients seem more primitive than what we use on the fediverse, the main clients that I used were much more powerful than any fediverse client I’ve used in the sense of how they enabled their users. Most fediverse clients are fairly thin wrappers around the Mastodon API (I know brutaldon certainly is). But Usenet clients implemented a lot of client-side logic that was only tangentially related to the “API” provided by NNTP.
The very basics: subscriptions and read lists
The one thing that every Usenet client supported was the .newsrc file.
This file contained a list of the newsgroups you were subscribed to, and,
for each one, a compacted list of the article numbers you had read. You
could switch between clients, and, because they all read your .newsrc, you
could be sure that the different clients would all keep you synchronized on
what you had and hadn’t already seen. Usenet clients mostly worked on the
assumption that you wanted to read new news, that you haven’t seen, and that
if you wanted to go back and read older things, then you could. If a Usenet
client displayed seen articles in the same list as unseen articles, it would
at least give you separate keybindings for “next article” and “next unread
article”.
Contrast current social media, including the fediverse. Most sites have an endless scroll, and if you keep scrolling for long enough, you will come down to things you have already seen. Typically there will be no indication that they are something you have already seen; you just have to remember that you’ve seen them before. And there are also various ways that stuff you’ve seen can come back into the top of your feed. On Mastodon, boosts don’t care whether you’ve seen the same toot already; you’ll see it once for each time it is boosted by someone you follow. On Facebook, new comments will often push an old article to the top of your feed.
I don’t believe that Mastodon keeps track of what you have and haven’t seen, though it could, and I don’t know of any clients that do so on the client side, though it’s completely possible.
Threading
Threading is one area where contemporary UIs have really dropped the ball. Mastodon has, like Twitter, a flat, pseudo-threaded thread display where posts are shown in the order a depth-first traversal of the thread tree would show them. This is not unlike the “conversation view” that is now common in email applications thanks to GMail. My opinion of conversation views is that they became widespread because they are relatively easy to implement, and because the threaded interfaces in early 2000s graphical email clients were terrible. If you wanted to navigate by keyboard, you generally couldn’t navigate only between unread messages, for example, having to go through all the intervening read messages. And there were no commands for operating directly on threads, so to move a thread to an archive folder required multi-selecting messages in the header pane. But done properly, as in several Usenet clients, threads are one of the keys to an efficient message interface.
In the newsreader I most preferred, trn, while you were reading an
article, the nearby branches of the thread tree were displayed in ASCII
graphics, and distinguished whether those articles had been read or not.
There were variants of every command (archive, mark read, etc.) that
operated on threads as well as on single articles. The default path through
the program assumed that you would want to read only new messages, but would
want to have the context of old messages available. This was also the case
with Gnus, the advanced newsreader for GNU Emacs — you could
easily operate on threads, and a mode (gnus-tree-mode) displayed ascii art
trees in a window pane.
Pick-and-read mode
The defining feature of trn was its pick-and-read operation. When you
started trn, you’d pick a newsgroup to start reading, then be presented with
a multi-page list of threads with new messages. You’d page through the list
and select the threads you wanted to read before you started reading;
anything you didn’t select would be marked as read. Then you’d go through
and read the unread articles in the threads you had selected, and nothing
else unless you went to extra effort to refer back to read articles. I don’t
think this particular mode of operation was common, though Gnus supported it
(gnus-pick-mode), of course.
Do you see how different this was from the infinite scroll of current social media web sites and apps? The idea was that your newsfeed would be updated periodically. Maybe hourly, maybe only once a day. And the goal of your newsreader was to let you be caught up and finished before the next time it updated. The newsreader helped you accomplish this by giving you a good overview of what was available, but empowering you to read less of it.
Killfiles and Scorefiles
The other way that newsreaders helped you read less news was killfiles (and later, scorefiles). A killfile is a file with rules for which articles to kill — that is, to never show to you. Most social media websites have only the most primitive and heavy-handed version of this, user blocking. Mastodon is a little better, with word filters. With trn or Gnus, you could block articles based specifically on subject line, author, body content, thread membership, or even more precise if less generally useful criteria. While killfiles generally used regular expressions, you could add a rule kill articles like the current article or thread in the future without knowing how to use regular expressions.
A scorefile is similar to a killfile, but better (as the Gnus manual notes, scoring is better than killing). A rule like a killfile rule could raise or lower the score of an article, rather than killing it outright. Lower-scored articles could be sorted lower in your list for picking, making it more likely that you’d mark them read without reading them unless you were bored. Very low scored articles could be automatically marked read. But conversely, higher scored articles (for example, by someone you like to read), could be sorted higher up, so that you don’t miss them.
What does this sound like? It sounds a lot like The Algorithm, except that it’s completely controlled by you, rather than by a company trying to sell you ads. Mastodon has a completely chronological timeline, which is better than the Facebook or Twitter algorithms, but having your own algorithm that is loyal to you is far better still.
Conclusions
Modern social media is easier to use than Usenet was, and this is as true of the Fediverse as it is of corporate social media sites. But despite the initial ease of use, current social media clients (web and mobile) fail as User Agents. Part of this is just that early web social media (forum software, for example, and SlashDot-alikes) were designed without really learning from Usenet. But a bigger issue is the attention economy. Corporate social media is advertising-driven, and is designed to keep you on the site for as long as possible. The example of Usenet clients suggests that what we need for a good social media experience is something that helps us be done with it as quickly as possible, to process the firehose without being forced to drink from it — just the opposite of corporate social media.
For historical reasons, the Fediverse has mostly duplicated the design decisions of corporate social media (another aspect of which has been commented on by Pleroma’s kaniini), and this has meant no really good clients, even though the underlying protocols (and even the Mastodon API) give you the data access you’d need to do so. It will be interesting to see if this niche gets filled, and, if it does, if it gets filled based on existing server software, or a completely new client and server ecosystem.