Show HN: Retronews – TUI for HN and Lobsters emulating classical Usenet readers
github.comI noticed the README comment about NNTP's limitations. I wonder if a new NNTP-over-HTTP protocol could find enough traction among the text-using crowd, or if ActivityPub could be used to provide a similar feature set efficiently.
Tried it, was fun.
How about automated updates every minute or so?
Usually I keep these windows open in the background and look at what pops up.
Actually one of the reasons for writing the app was to reduce my compulsive browsing of social media. A feature like this would go in the opposite direction :) But if you really want it, feel free to tinker with the code, it should be pretty straightforward.
Script it? ^_^
Or code it..
I'm coding something similar for nostr events. Might add HN too keep different feeds on the same TUI location. Text is less distractive than these modern crafts of devil called CSS and god-forbid: images.
Always nice to see text consoles coming back.
In later peak Usenet, there was also threading, and scoring.
Scoring rules would let individuals define rules for how thread subtrees and siblings are ordered, highlighted, and hidden. For example, comments by a particular user you like bump up the ordering priority for that comment, and also maybe some boost to the tree above it. And some keyword you think tends to happen in threads you don't like adds a negative score to that subtree, and maybe it hits a threshold causing it to be hidden (though the positive score from that user you like participating might save it, with you thinking that maybe they'd step into a flamewar and say something smart). And, separate from rules you defined, you could also manually hit a key to raise or lower a post or subtree (which could be used as an alternative to the earlier feature to say hide a subtree no matter whether more comments are made on it, like you might do for a flamewar).
Wow I love the look of this; gonna try it out.
Not really retro news, since it assumes everyone is using a large window and full-color terminal.
I was hoping to use it with one of my retro machines, and got
use_default_colors() returned ERR
The Unix ethos used to be "run anywhere on anything," but even basic programs like top assume a window of a certain size.
Similarly, Lynx markets itself as being for retro environments, but a number of its flags that would be useful in retro environments are ignored/broken.
Surprisingly (to me), htop is very well-behaved, and works even in tiny windows, or on tiny monochrome screens.
There's more to retro than just being text.
To be precise, it only assumed 80x25 terminals with 16 colors, which I think fits into some definitions of retro, but I see your point :)
I've just added support for ascii & monochrome modes, and reduced the required screen size to 80x12, which I think is a reasonable minimum for readability.
Would you mind sharing what kind of hardware did you try it on?
You're almost there. But 80x12 is still a bit big for truly retro hardware.
Remember that 80 column screens were not the majority of computers in what we now consider the retro age. 40, 36, and even 32 columns screens were common.
Also, terminals would often have status bars, reducing the amount of vertical real estate. 12 sounds small, but with status indicators active, you're looking at 10 or even 8 usable lines.
Either I am very young or you are very old, because ANYTHING with a fixed 80 column screen is definitely retro. This is a weird thing to gatekeep.
What commonly used UNIX terminals had less than 80 columns? VT100 had 80 columns, IBM PCs had 80 columns. I remember some 8 bit computers having text modes where you could choose to display less columns in return for getting more colors, but those computers never ran UNIX and getting on usenet was surely a pipe dream.
I agree, any terminal I ever used to access a shared unix host had 80 columns. Typically a VT100 or ADM-3a or something like that.
TRS-80, TI-99, Commodore, Apple etc. home computers had 32, 40, maybe 64 columns and you could get terminal emulator programs for them but most people would use them for CompuServ or America Online, or maybe BBS logins. I think I tried using my TI-99 terminal emulator with a unix host and it wasn't very successful. The host had no idea what my terminal was and operated in a very limited "dumb tty" mode.
Eh, to do it properly, 40 cols and less would require adjusting the whole layout and I just want to keep the code simple. I'm also not sure if the code would be fast enough to run on so old machines, I mean it's Python and not optimized at all. But feel free to fork and tinker if you're interested, at this point it's not really far off.
How come it is 80x25 instead of 80x24 (default dimensions for XTerm)?
Interesting, I never noticed that 80x24 resolution. Apparently it's been inherited from VT100.
Now 80x25 was the standard text mode of IBM PC, which I'm much more familiar with. I used it because I was testing (over telnet) on some retro ones.
This is nice. Useful to look busy at office while reading HN
I see it's read only
Is it possible to launch a browser for writing replys/comments?
Sure, that's how I use it.
In every message you can see its URL in the Content-Location header.
You can press 'o' to select it and open in a browser, and you can select the browser with the BROWSER env var.
Although many terminals have built-in support for simply clicking on URLs, and that's what I usually do.
Why not an NNTP gateway?
NNTP doesn't support browsing threads by title (let alone paginated) and requesting their messages on demand. Clients need to fetch metadata of all available messages in all available threads in advance. Given the volume of messages on HN, synchronizing them to the gateway is not practical. Even when attempted, some clients struggle with the sheer number of messages in a single group.
I always liked USENET news for its "pull" approach, and for the same reason hated email newsletters. The threaded discussions via Emacs GNUS were a delight, and modern Web-based forum solutions are distractive and never respect my font/color settings; plus, they also diff in UX.