💾 Archived View for sporiff.dev › 2023 › 07 › 26 › nntp captured on 2023-09-08 at 15:50:46. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Posted on 2023-07-26
Is Usenet actually dead?
Nothing ever truly dies, I'm just saying I want it to be big again.
I'm on the record as a lover of email. Communications these days are all too... immediate. Urgent. Grabbing your attention away from the day-to-day and demanding you give over your soul to the neverending stream of thoughtless messages, gifs, and links. It's exhausting. Working in Slack channels is a surefire way to get a migraine (or worse).
Email, meanwhile, is more patient. Emails come in and sit there until you're ready to deal with them. There is an expectation that emails will take longer to write and contain a greater level of thought than the average instant message. You also get the benefit of truly contextual communication. Consider the following scenario in Slack:
Jeremy has an idea for an exciting new project for his company's backend service. He types up a long message on Slack in the <Backend> channel outlining his proposal. Immediately, a thread is formed.
This is a good start. We have a dedicated channel (<Backend>) that contains the initial message and now we have a segregated thread containing discussions about the suggestion. However, it doesn't take long for this to fall apart.
Naoimhe has spotted a problem with Jeremy's suggestion and wants to discuss it further. She responds in the thread outlining the issues and her ideas. People start responding, but they can't respond to the actual message or start a sub-thread! The thread becomes a mess of crossed wires and mixed messaging.
I've seen this happen many times at my place of work. All I can do is sit there thinking: "this works just fine with email. Why aren't we using email?"
Email threads are elegant, allowing people to split off different topics at various points throughout the conversation while keeping everything contained in a single thread. Messages can be edited to leave only the necessary context. For example:
Jeremy sends the following email
Hi all, I've had an idea for a new backend project that I'd like your thoughts on. Basically, I would like to implement Redis to more efficiently queue our backend processes. We're seeing lots of process blockers that might be effectively sorted by implementing smarter queueing. I'd like to get your thoughts on what you think the development effort for this would be. I think it should be fairly easy to implement, but I'm pretty new to this part of the codebase. Thanks! Jeremy
Naoimhe responds, quoting sections of the original message.
Hi Jeremy, First of all, thanks for opening up this discussion. I think it's a great idea to talk about what we can do to improve efficiency in the backend process. > We're seeing lots of process blockers that might be effectively sorted by > implementing smarter queueing. I'd like to do some more investigation into these blockers before we look at adding another product to our stack. Not that adding Redis isn't a good idea long-term, I'm just wondering if we're putting a sticking plaster over a larger wound. Maybe we should set up a hackathon to see if we can't track down where the blocks are coming? > I'd like to get your thoughts on what you think the development effort for > this would be. I think Marques is probably the person to ask for this...
And so on. The email thread might branch off into different topics, but thanks to the unbroken and easily linkable chain of responses it's harder to get lost than in an instant messenger like Slack or Teams.
You remember Reddit? It used to be kind of good before the redesign and the awful decision to massively overcharge for its API and effectively lock out third-party clients. Before Reddit, threaded discussions took place in one of two places:
Reddit is conceptually similar to both of these, presenting itself as a forum with conversation threads that behave similarly to Usenet threads. Sounds ideal, but unfortunately, Reddit is:
Usenet has the benefit of being a distributed system that is accessed using an open protocol (NNTP), meaning that you have myriad ways of accessing its content on any machine. Since posting and following up threads is all done through standard SMTP, you can easily get involved with Usenet by just having an email address. It's old school magic, but it's still magic.
Conversations on Usenet are organized into separate "newsgroups" by topic, and each conversation starts with a single thread to which anyone can respond. Reading back through historical threads on groups like "alt.folklore.computers" is a special treat. Years and years of historical knowledge and insight are available in these long threaded mazes, each one a joy to unpick. And unlike standard web forums, which can easily disappear if the owner decides to shut off the server, these Usenet threads are stored on multiple servers, so we're much less likely to lose them altogether.
The best way to start (in my opinion) is to set up an account on a free service like eternal-september. This gives you access to all the major public newsgroups and the historical conversations stored within.
https://www.eternal-september.org/
Next, pick yourself a client. I personally use slrn, but if you're an emacs user you can use gnus instead. If you prefer a graphical client, Thunderbird does a remarkable job of interacting with newsgroups!
https://support.mozilla.org/en-US/kb/creating-newsgroup-account
The next (and most important) thing to do is start picking through the different newsgroups to see what interests you. Search for a topic you know well, or pick a random one that has interesting people in it. Subscribe, and maybe post something. You'd be surprised who picks up on the other end.
Because email is the king of comms, and because the more the web centralizes around a few "crucial" websites like Reddit rather than open repositories like Usenet, the worse it's going to be for all of us.