Hacker News new | ask | show | jobs
by j16sdiz 921 days ago
Guess it's hard to get others sync with you?
2 comments

The principle use-case for Usenet has always been small, controlled-access networks.

That's what ARPANET and the early Internet were, where "small" meant < 1 million active participants and "controlled access" meant meeting the requirement of belonging to one of a limited number of academic institutions, tech companies, government agencies, or select military units. Total Usenet participation in April 1988 were 140,000 readers, by Eric Reid's DEC surveys, as cited in John S. Quarterman's The Matrix (1990):

<https://archive.org/details/matrixcomputerne0000quar/page/24...>

Spinning up an NNTP group for internal company communications, for a family group, or for a (sufficently tech-savvy) organisation or hobby group would be a viable option. My experience is that peak group experience tends to occur with somewhere between about 5 and maybe 1,000 participants on the high end, and that's being generous. In practice, 5--50 is probably a better sweet spot.

The technology isn't the stumbling point nearly so much as convincing people to use the service. In some industries, privacy and disclosure rules may preempt usage (e.g., healthcare, finance). And the fact that Usenet has no intrinsic authentication or attestation of identity (though these can be provided by additional mechanisms such as PGP/GPG signatures) means that publicly accessible newsgroups are likely to be nonviable given malicious actors.

What's underappreciated about much of the early Internet / online world is how small most of the "large" (as in influential) groups or movements were. Usenet, the WELL, Slashdot, and early blogging had core groups of perhaps a few hundred to a few thousand people, possibly fewer. Yes, there were additional participants in many cases, but in terms of how concentrated the bulk of activity was, small.

Hmm and if you limit the use case to those small groups, there are a lot more options now. There's the whole Fediverse stack, of course, but also lots of stand alone forum options you can self host. And why self host when there are also lots of low-cost community platform options out there?
So, that really wasn't the original question, so noting that we've moved on from that ...

Basic protocols such as NNTP and IRC have the benefit of being stable, small (running a Usenet server on an OpenWRT router with additional writeable storage would be doable, running a Fediverse instance not so much), and being relatively client-independent and even protocol-flexible. NNTP <-> SMTP gateways are, for example, A Thing, and people can participate in such newsgroups from either Usenet or email clients. Similarly Web gateways to either NNTP or SMTP systems.

The flipside is that the underlying protocols are also simple and absent some additional tooling lack much of what it is that people have come to expect from more recent messaging systems:

- Mobile device access. That's probably the big one, though I'd argue that for useful discussion you're better off eliminating mobile use. I've commented that losing a keyboard and being forced to a small screen cuts my effective IQ by half, and that quality of discussion on public systems also seems strongly negatively affected by mobile use. Read-only access might be a compromise, with some "I have something to say but will wait until I can access a Real Computer" might be an option. Android + Termux + Bluetooth keyboard meets my minimums as "real computer", FWIW.

- Formatted text, usually a flavour of Markdown or some "smart editor" for normies. Then again, we seem to survive with much less than that on HN.

- Images. That's the principle feature NNTP lacks natively, though they can be shoehorned in via uuencoded posts. Along with audio and video, the ability to create multimedia posts (popular, occasionally useful, terribly abused) might be an objection raised by many.

- Third-party clients. The great strength/weakness of NNTP and SMTP are that neither are locked to a single client, or Web client (though the latter is available). Having a specific tailored client program (tin, slrn, Emacs, pan, etc.) is useful because the features of the platform are strongly supported by those clients. Downside is Yet Another Piece of Software to install and train on. In the mobile world apps have been breaking the notion of everything-in-the-browser, though often bringing along their own set of issues, most notably surveillance, but also general issues of design, UI/UX, maintenance, security, and abandonment.

The initial question addressed could and the answer really is "trivially", from a technical level.

Yours is "should", and as I'd hinted in my initial response, that's far more social and up for debate (as we're doing here).

But at least you're demonstrating a exception to Ian Malcolm's could/should criticism.

It's actually pretty trivial. Eternal-september seems happy to peer with anyone who asks (just send an email), and there's a newsgroup specifically for asking for peers; everyone who posts there gets lots of offers pretty quick.