Support linux's TIPC (aka "cluster-domain-sockets") support; use key `tipc`?

Before your eyebrows raise too much, i know TIPC may be unfamiliar outside the esoteric realm of "cluster computing on linux", so a quick bit of context.

This is not a new or experimental transport ✌🏼

Transparent Inter-Process Communication was developed by Jon Maloy and the TIPC team at Ericsson (yes the same entity responsible for the EVM and friends) for carrier-grade cluster applications, was presented at the 2004 Linux Symposium, and was merged into mainline Linux on 2 January 2006. It has therefore been an in-tree Linux networking subsystem for twenty years.

It is sometimes called Cluster Domain Sockets, which captures the
idea well: the Linux docs introduce it as the convenience of Unix
domain sockets extended across cluster nodes. An application binds a
location-independent service name, the kernel publishes it in a
cluster-wide name table, and clients connect by that name without an
IP address, DNS name or transport port.

I am implementing TIPC as a transport for distributed Python
processes in goodboy/tractor#493. The current prototype
uses an interim string form because /tipc is not registered with
multiaddr:

/tipc/<service-type>/<instance>/<scope>

The composed form I ultimately care about is a TIPC service reached
through a WireGuard bearer:

/ip4/<public-ip>/udp/51820/wg/u<key>/tipc/<service-name>

Unlike TCP-over-WireGuard, TIPC deliberately has no inner IP/port:
the wg portion identifies the bearer and peer, while TIPC's kernel
name table resolves the service to whichever cluster node currently
publishes it.

SO,

Would the project be open to a draft tipc codec implementation,
following the prototype-first path used for wg in #107 / PR #108?
I would especially value maintainer review before treating any of
these choices as settled:

• one structured text value, currently proposed as
  <type>:<instance>:<scope>, versus another existing multiaddr
  convention, which please do suggest alts if there are options 🙏🏼
• a fixed nine-byte binary value (uint32be type, uint32be instance, uint8 scope) versus a variable/self-describing tuple
• whether a generally shareable address should admit node scope or
  only cluster scope: the kernel UAPI defines these as publication
  scopes, while the TIPC addressing guide
  distinguishes node-local from cluster-global binding visibility
• whether this endpoint protocol should represent singleton service
  names only, leaving TIPC service ranges to a separate concern
• when to reserve a multicodec and submit the eventual multiaddr spec

I am happy to implement the codec, deterministic vectors, malformed
input coverage and standalone/composed round trips. My preference is
to let review of that concrete Python implementation shape the later
registration plan, as happened with the follow-up work in #123 and
#130, rather than presenting an unfamiliar protocol as a finished
specification up front.

Primary references:

• Linux kernel TIPC documentation
• current in-tree net/tipc implementation
• Linux TIPC socket UAPI
• initial mainline merge, 2 January 2006
• current kernel Kconfig provenance and feature summary
• Jon Maloy's 2004 Linux Symposium paper
• TIPC overview and “Cluster Domain Sockets” terminology
• downstream encoding research and open questions

I realize this one is a bit of strange ask (given that noone i've talked to in the conc-eng space seems to have heard of this proto despite its age 😂) but i'd very much appreciate some feedback and am obvi very happy to adjust the prototype around the project's
preferred codec and registration conventions.

Start by reviewing the prototype-first path in #107/PR #108, the current implementation in goodboy/tractor#493, and the downstream plan linked in the issue. Resolve the proposed text and binary forms, scope and service-name questions with maintainers, then add the codec, deterministic vectors, malformed-input coverage, and standalone/composed round-trip tests described in the issue.