The HINFO.network.

What

An RFC9432 Catalog Zone
A list of hosts
Hosts may have some of their basic metadata – CPU and system – published as RFC883 HINFO records

Why

an ill-conceived sense of drip
nerds want one thing and it's fucking disgusting (old standard no one's used for 40 years (on the dot this year! happy coincidence), especially when combined with a barely-standard from 2023)
funi
no point to being a type of guy if you can't post about it
hard-line-reduxionist take on what "a social network" could be (it's not a medium, since nothing is transmitted. some would say it's a webring) – there is precisely one string of user data (link in bio? all it is is a link to the user's drip); the most computationally expensive part is record signing and key exchanges
eternal gentoo user meme

How

You publish a HINFO record, then you register that name in the HINFO.network..
Every 6 hours or when knot posts an UPDATE, this site is refreshed. The time of the latest change to the network is visible in the SOA serial (decoded on this page for your convenience).
Names that are part of the HINFO.network. are queried for their HINFO records, and those are included at the top of this page.
Those names are additionally turned into web links if they also carry A or AAAA records, or into mailto:hostmaster@%s?subject=Cool host! links if they have non-null MX records.
You can link to your host directly by linking to //hinfo.network#your.host.invalid..

The state of the network can naturally be queried in the usual way via dig hinfo.zones.hinfo.network. ptr and dig +noall +answer hinfo $(dig +short hinfo.zones.hinfo.network. ptr).

Drip

88×31 badges are available (cf. the bottom corners of your view-port):

 <a href="//hinfo.network#your.host.invalid." title="As seen in the HINFO.network.!"><img src="//hinfo.network/drip/88x31.gif"></a> <a href="//hinfo.network#your.host.invalid." title="As seen in the HINFO.network.!"><img src="//hinfo.network/drip/88x31vore.png"></a>

For inline dripping, the word-mark is constructed from AMIX sunfont & AMIX topaz.

Standards considerations

RFC883 in November of 1983 defined HINFO as a "CPU"/"OS" string pair

used to acquire general information about a host. The main use is for protocols such as FTP that can use special procedures when talking between machines or operating systems of the same type.

with a set of 14 "CPU"s, among which

IBM-PC/XT
IBM-PC
PDP-11/70
VAX-11/780

which is basically almost defensible, since these are computers, but mostly discriminated down to a single CPU type/peripheral set, and maybe vaguely can be used for the purpose of arch-discriminated binaries or whatever FTP bull shit.

And a set of 42 "OS"es, among which

DOS/360
UNIX
VM/370
VM/CMS
VMS

which really isn't — as we all know, every UNIX is interchangeable (especially in a. d. 1983 when 4.2BSD and SysV dropped), DOS exists only on IBM mainframes, and VM's canonical name is different from VM on the System/370.

These allocations are now handled by IANA as "Machine Names", which is slightly closer than "CPU", and "Operating System Names". Both are restricted to 40 bytes, the A-Z0-9/- alphabet (+ . for the latter), must start with A-Z and end with A-Z0-9; this is enforced for display on this page.

The 343 "Machine Names" were last updated 2001-08-23, don't have a defined registration procedure, and are actually a "machine name or CPU type"; naturally this includes:

35 different strings similar to "AMIGA-2000/EC030", sometimes without the slashed part, and 41 different brands of SUN; these are the only two vendors that use this list almost correctly, it'd seem,

DECSTATION
DEC-VAX
DEC-VAXCLUSTER
DEC-VAXSTATION
DEC-VAX-11730

(there are another 9 VAXes listed, among which "VAX"),

INTEGRATED-SOLUTIONS-CREATOR-8 (the longest on the list, right next to "I…-S…", and "I…-S…-68K", of course. and "I…-S…-C…").

IBM-PC
IBM-PC/AT
IBM-PC/RT
IBM-PC/XT
INTEL-386
~~INTEL-IPSC~~

(this is where the PC ends).

The 188 "Operating System Names" do have a "call us" registration procedure, and were last updated 2010-10-19 (which is still shockingly recent). Naturally this includes:

MUSIC
MUSIC/SP
MVS
MVS/SP

~~(which are spelled correctly)~~

X11R3,

a, frankly, reasonable collection of sensibly-versioned UNIXes,

OPENBSD

~~and~~

FREEBSD

~~, but~~

NETBSD-1.0
NETBSD-1.1
NETBSD-1.2
NETBSD-1.3

OPENVMS
VMS
VMS/EUNICE

{INTER,}LISP and LISPM!?,

CYGWIN ඞ INSTANT-INTERNET,

and, of course,

LINUX
LINUX-1.0
LINUX-1.2
LINUX-2.0
LINUX-2.2
LINUX-2.4
LINUX-2.6

since as we all know, Linux is a system, and only comes in stable form. Sure, you could defend "LINUX", but by 1.0 the distribution model was very much set, so much so that there was already significant drama (some may recall SLS, which was so horseshit they made Debian).

Thus, the

guide-line

which should be a reasonable synthesis of the realistic convention with the modern taste and requirements:

Probably either use SysV ABI/Debian arch names for the architecture (cf. machine classes like i686/amd64 where any (modern) CPU can run three distinct ABIs), especially when that discriminates the system distribution architecture. Or the canonical system distribution architecture name like "sun4c".

Probably use "system/version" for stuff like "DEBIAN/BOOKWORM" or "FREEBSD/13.2", probably use "system" for stuff like "ARCH-LINUX" (or, if you're that type of guy, "system/date-of-last-update" à la "VOID-LINUX/2023-09-20").

Probably also normalise dumb ass bull shit like "Arch Linux ARM" into "AARCH64"/"ARCH-LINUX".

Which should, once the "FTP bull shit" nominal requirement is generalised to "can i copy a binary over and it works" (which effectively is what I think it's driving at in present-day), fulfil the HINFO purpose.

Register

 $ nsupdate key hmac-sha512:public.zones.hinfo.network NE5vBR0amAvWdFJ6q9DA820hK+QW1wOoAPs1TvfSeIhhz5iF9UKZ0e8/f400fA5QeEZIRsXbkZHmA+OiFjPWselS5TncyTM+Ji51LxCRADmSY1CP94dI1BhVX6v7N2hUm1IN5AwNNvVoAsnY0bj3K46aB9epP1M4rtuzCs9+iccS9OfwCKoizYrEWd5YZdkv/4UPZyu0X6zF9SK+J9fTpNKQ87opKbM8rBz5zOxFHL9SbTKhQnVI9VZFN55bbMtdM0Pxoh0dCN+wTXEhOFRnpjFcq+2DOgOzW++tbIQFCf3AWN4VFOeL9Vt9DgyLn+13Mb1wqmXN7XxM7HAAvL0YQg== ;                             0x4849, 'HI' server ns.nabijaczleweli.xyz. 18505 zone zones.hinfo.network. add hinfo.zones.hinfo.network. 1 ptr your.host.invalid. send

Normal RFC2136 UPDATE semantics should apply, with a sand-boxed feature-set (no deletions, no prereqs, &c.), and the TTL is ignored. All inserted names must have a HINFO record present, and must not be a CNAME, according to the local resolver — otherwise the query fails with YXDOMAIN and the failing RRs are returned in ADDITIONAL. Names are REFUSED if they're wider than 50 columns (yes, columns) (for the sole purpose of keeping the table at the top readable).

For display on this site, each HINFO RRset is trimmed at 2 entries (for now).