introducing the new federated anarchist networking protocol: UUCP

[Mima-sama]

Original article at
https://raddle.me/f/wednesday/169488/introducing-the-new-federated-anarchist-networking-protocol


UUCP is a networking protocol that was popular prior to the rise of the
commercial Internet and TCP/IP. UUCP has a number of advantages
(implicit in its design) that make it much preferable to TCP/IP for
autonomous, distributed communities.

UUCP is a network of loosely-affiliated nodes, which are just computers
running the UUCP software. each node is identified by a human-readable
name (there is no numeric addressing system comparable to an IP address)
and each node is only aware of the nodes it is directly connected to.

each node may be connected to any number of other nodes. these
connections can happen over any telecommunications system that supports
byte-oriented data transfer; that includes TCP/IP (allowing UUCP to
interoperate with the Internet) as well as dial-up lines, leased lines,
direct connections (copper or fibre), wireless (radio) links, signals
bounced off the moon, and so on. UUCP nodes are typically not
permanently connected, but establish scheduled temporary connections;
for example a node connected via dial-up might connect to two nodes once
each per day, or a single wireless radio could connect to multiple
wireless peers.

a UUCP network with 6 nodes (A, B, C, D, E and F) might look something
like this:

```
C
|
A -- B -- E -- F
|
D
```

here, B is a large 'hub' node which connects to many peers. A, C, D and
F are probably end-user sites. E might be an end-user site which also
provides connectivity to F, because with UUCP, any node can provide
connectivity to any other node without needing any kind of formal
approval from the rest of the network.

because UUCP lacks centralised routing database, a user must specify the
complete path to the destination, so a user on D who wants to email the
user 'wednesday' on F might send email to `b!e!f!wednesday`, which means
“send this message to B, which will send it E, which will send it to F,
which will deliver it the local user `wednesday` on F”. to reply to
that message, the reverse email address from F might be `e!b!d!sendername`.

of course, it can be quite annoying to manually work out the path every
time you email someone, so many sites run automated 'routers' where you
send an email to 'wedn...@f.uucp' and the node's email software works
out the actual path based on its local UUCP map. but this is different
from how Internet email works, because the UUCP map is local to every
node; there is no centralised authority which creates the map or decides
which nodes can be included or how they can be named, like there is with
the Internet.

UUCP supports the transfer of any kind of file; often those files are
emails, but they could be discussion groups (Usenet), general file
transfers, or any other protocol someone wanted to implement on top of
the network.

so why is this preferable to the Internet TCP/IP model?

- completely decentralised: the Internet depends on centralised
authorities like IANA, ICANN and the IETF which UUCP, by its nature,
simply doesn't need.

- based on voluntary free association: any node can choose to federate
with or *not* federate with any other nodes if wants to, without needing
to ban those nodes from the entire network (and indeed, it would be
impossible to ban a node from the entire network).

- technically simple: UUCP can run on 1970s-era computers.

- explicitly anti-real-time: although UUCP can run over fast links, its
scheduled nature means it's inherently a 'slow' protocol which doesn't
rely on, or even permit, constant user engagement the way modern
Internet platforms do.

- interoperates with TCP/IP: we might imagine a community which had a
locally-managed IP network (an intranet) for its own communications, and
used UUCP to connect to remote networks.

in summary, it seems clear that UUCP (or a similar protocol based on the
same principles) is far superior to the centralised Internet model.

are there any downsides? well, the most likely downside is that like any
loosely affiliated network, certain nodes can become more important to,
or even essential to the network[0] and therefore gain implicit
authority over it; resisting this would be an ongoing process of
structuring the network in an antiauthoritarian way.

[0] this did happen historically with nodes like `ihnp4`, `uunet` and
`decvax`, but their prominance was a natural extension of their
prominance in capitalist society, so this is not necessarily inevitable.

--
Mima
Reincarnated Legendary Evil Spirit of Complete Darkness

[Marco Moock]

Am 10.09.2023 um 19:49:20 Uhr schrieb Mima-sama:

> are there any downsides?

You can't handle mail with UUCP with that many mail servers that
currently exist without some more central servers.

[CP]

Are you still entertaining the idea ?

[immibis]

Could you adapt a routing protocol such as OSPF?

The OSPF *concept* (not the full protocol) is quite simple: nodes gossip
amongst each other about the topology of the network (all nodes and
links). When a node sends a packet, it finds a path based on the network
topology. (Actually, routers pre-calculate all possible paths, but mail
is less frequent so it could find paths as needed)

On modern CPUs, it should scale to at least 10000 nodes, probably more.
After that, you can start thinking about ways to form a hierarchy. A
bigger problem is that all nodes have to be trustworthy.

If mail is passed alongside news, topology update messages could already
be passed along by the news network, just like newsgroup control
messages are.

[Grant Taylor]

On 12/16/23 09:03, immibis wrote:
> Could you adapt a routing protocol such as OSPF?

Maybe in concept. But I don't think in practicality.

My understanding of OSPF is that it fundamentally relies on broadcasts
wherein it can send one message and all the other OSPF peers can receive
it. As such, OSPF peers discover each other and learn what each other
has access to with one (set of) message(s) per OSPF peer.

I don't see how UUCP nodes would be able to do that type of broadcast as
they are spread out and don't enjoy the benefit of a shared broadcast
medium.

I suspect that UUCP would benefit from something more like BGP wherein
each UUCP node has an explicit configuration to one or more other UUCP
nodes.

I can see how UUCP nodes could exchange files that contain data of what
they have access to with other explicitly configured UUCP nodes. This
data could then use something akin to BGP algorithms to derive bang
paths between end UUCP nodes.

> On modern CPUs, it should scale to at least 10000 nodes, probably more.

I'd be surprised if there were more than 100 UUCP nodes that would
participate in this technique /at/ /this/ /time/ in 2023.

> After that, you can start thinking about ways to form a hierarchy. A
> bigger problem is that all nodes have to be trustworthy.

I think that you would want to work on the hierarchy capability from the
start. Lest you end up with having to completely re-design things
again. A very simple example that I've run into multiple times in the
past with small UUCP networks I've run is wherein you have two private
LANs with multiple UUCP nodes one of which has Internet access and can
talk to other similar counterparts. So you end up with a bang path of
something like the following:

A1!A2!...!Z3!Z4

Where:
- A1 & Z4 are private UUCP nodes on their LANs.
- A2 & Z3 are gateways between a shared network and the their private
LANs.

A1 and Z4 will never be able to talk to each other directly. They must
rely on A2, Z3, and the common intermediary.

Thus you end up with three distinct parts of the topology:

- LAN-A
- Common routed network
- LAN-Z

I suspect that support for these distinct parts of the topology will
need to be accounted for from the very beginning.

Perhaps we could sort of treat these distinct parts of the topology
analogous to Autonomous Systems in BGP and do the rout calculation
between ASs like BGP does.

We still have the issue of determining which AS a given node belongs to
much like prefixes belong to an AS in BGP.

None of this accounts for any of the software being used having any idea
how to utilize these dynamic routes / bang path. Maybe that could be
handled with a customization of UUCP software and put a magic place
holder in the path (much like the "!...!" above) and allow UUCP to
figure it out / hide the complexity from the software using UUCP; news
email, etc.

> If mail is passed alongside news, topology update messages could
> already be passed along by the news network, just like newsgroup
> control messages are.

I would not want the UUCP topology to depend on a service that itself
depends on the UUCP topology. Seems like asking for a priming issue and
/ or a recursive problem.

I could see some possibility of using uux to remotely execute uuname to
learn the names of other UUCP nodes that the remote UUCP node you are
asking knows about.

Then there is the issue of name duplication. UUCP doesn't care if there
are duplicate node names. But route discovery would need to be able to
handle it.

The elephant in the room is DNS. DNS is how email abstracted away
needing to dynamically learn paths. I see no reason why we couldn't do
similar with UUCP, at least in concept. But you're back to the name
duplication issue and likely need to publish some sort of record for
each host somewhere.

If we started using some sort of hierarchy / domain structure in node
names, that would make auto-discovery of paths easier.



--
Grant. . . .

[Marco Moock]

Am 16.12.2023 um 13:37:54 Uhr schrieb Grant Taylor:

> On 12/16/23 09:03, immibis wrote:
> > Could you adapt a routing protocol such as OSPF?
>
> Maybe in concept. But I don't think in practicality.
>
> My understanding of OSPF is that it fundamentally relies on
> broadcasts wherein it can send one message and all the other OSPF
> peers can receive it.

It uses link-local multicast:
https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml
https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml

[Grant Taylor]

On 12/16/23 13:58, Marco Moock wrote:
> It uses link-local multicast:

Agreed.

But when you get down to the bits on the wire, there is very little
difference between a broadcast frame and a link-local multicast frame.

There is a good chance that clients and / or their NICs, need to process
more of the frame to identify that the frame isn't for them than they do
a unicast frame.

}:-)

Either way, the ability to speak to multiple recipients on the network
medium is a paradigm that doesn't exist between systems on separate
networks on the Internet today.

If multi-cast was still a thing on the Internet today, sure, but it's
not in any way like it used to be (for testing).



Grant. . . .

[Marco Moock]

Am 16.12.2023 um 14:27:45 Uhr schrieb Grant Taylor:

> On 12/16/23 13:58, Marco Moock wrote:
> > It uses link-local multicast:

> There is a good chance that clients and / or their NICs, need to
> process more of the frame to identify that the frame isn't for them
> than they do a unicast frame.

Multicast exactly has that ability to have that decision already when
processing the MAC address (the NIC only needs to accept multicast
frames for multicast MAC addresses the devices listens to) and the dst
IP address.

> Either way, the ability to speak to multiple recipients on the
> network medium is a paradigm that doesn't exist between systems on
> separate networks on the Internet today.

Define network. Multicast routing is possible, IIRC it should also be
possible between multiple AS, but as I know, it isn't used very much.

> If multi-cast was still a thing on the Internet today, sure, but it's
> not in any way like it used to be (for testing).

It least for IPTV it is used inside an AS, at least for Deutsche
Telekom's Magenta TV service.

[Grant Taylor]

On 12/16/23 15:43, Marco Moock wrote:
> Multicast exactly has that ability to have that decision already when
> processing the MAC address (the NIC only needs to accept multicast
> frames for multicast MAC addresses the devices listens to) and the
> dst IP address.

Either the NIC needs to support multicast or it passes the frame up to
the software to filter.

Even if the NIC supports multicast directly, it has an upper bound on
the number of multicast MACs that it supports.

There is a small amount of additional demand for processing multicast
frames. It's a question of how much and where it is.

> Define network.

I'll go with any layer 2 connection that is able to carry broadcast frames.

> Multicast routing is possible, IIRC it should also be
> possible between multiple AS,

Yes, it is technically possible.

> but as I know, it isn't used very much.

That is the rub. Virtually nobody enables support, or explicitly
disables support, for multicast across the Internet.

> It least for IPTV it is used inside an AS, at least for Deutsche
> Telekom's Magenta TV service.

Yes, multicast works quite well in closed systems, or within an AS.

Crossing the Internet is decidedly not within an AS.

[immibis]

On 12/17/23 07:07, Grant Taylor wrote:
> Yes, multicast works quite well in closed systems, or within an AS.
>
> Crossing the Internet is decidedly not within an AS.
>

Newsgroups are multicast; I understood you already had news running on a
UUCP network, and wanted to add routing in order to send (unicast)
emails. Grant has told me in a private reply this was incorrect. Since
the subject of this thread is "introducing the new federated anarchist
networking protocol" and not "archaeology of ancient technology some old
farts couldn't give up when the internet was invented" I thought that
was quite a sensible interpretation.

(To Grant: did you mean for your reply to be private, or was it a
fat-finger? I see you posted the same message to the newsgroup 3 hours
later.)

Nor is it "introducing the new pointless overlay protocol for capitalist
TCP/IP networks", so I also don't see the interest in discussing how to
represent the Internet in a bang path. An anarchist cypherpunk UUCP
network *expecting* the Internet to be in the middle of every
transaction seems to defeat the point of having an anarchist cypherpunk
UUCP network - you may as well just tunnel SMTP/NNTP over Tor instead.
Or I2P. Or use Retroshare. Or Mixmaster.



I re-read the initial question and I seem to have mis-read it as well.
The problem was: "You can't handle mail with UUCP with that many mail
servers that currently exist without some more central servers." and I
understood it to be complaining about the existence of central servers
(such as ihnp4`, `uunet` and `decvax`) due to the routing system, not
the necessity of *gateway* servers to reach non-UUCP nodes.

[Grant Taylor]

On 12/18/23 02:06, immibis wrote:
> (To Grant: did you mean for your reply to be private, or was it a
> fat-finger? I see you posted the same message to the newsgroup 3 hours
> later.)

No, I didn't mean to send the reply privately. Suffice it to say that
contemporary Thunderbird is making a worse and worse news client with
each successive version.

> I re-read the initial question and I seem to have mis-read it as well.
> The problem was: "You can't handle mail with UUCP with that many mail
> servers that currently exist without some more central servers."

My interpretation was something along the lines of the years old issue
of needing to source route from the sender to the recipient. For a
while there was effort under way to have UUCP nodes derive a route to
the destination node. My understanding is that this was based on shared
data and wasn't automatically discoverable in any sense.

Aside: UUCP is both a line protocol (as in what is sent over a serial
port between two systems) as well as a file transfer protocol
(independent of the physical communications ports). -- I have been
talking about UUCP in the latter form in this thread.

[immibis]

On 12/18/23 15:46, Grant Taylor wrote:
> My interpretation was something along the lines of the years old issue
> of needing to source route from the sender to the recipient.  For a
> while there was effort under way to have UUCP nodes derive a route to
> the destination node.  My understanding is that this was based on shared
> data and wasn't automatically discoverable in any sense.
>

Routing inherently relies on shared data. Nodes need to know how distant
nodes are connected to each other. If you already have Usenet running,
you can propagate it through Usenet.

Routing is a theoretically solved problem, but you might not like the
tradeoffs of any particular solution. There are two main ideas: one is
to propagate information about the entire network's connectivity
throughout the entire network, so that each node can independently
compute the paths it needs. This works quite well until it runs into
scalability problems (probably in the hundreds of thousands, if not
millions of nodes nowadays). This is called link-state routing, and is
used in most routing protocols.

The other idea is for each node to tell its neighbours which nodes it
knows how to reach. There's no non-local data sharing. While this works
very well in a spanning tree, you have to add some extra information to
make it handle loops acceptably. For UUCP you'd want to pass the whole
bang path around (if you still want source routing), and you get a
path-vector protocol similar to BGP. Most administratively closed
networks use link-state routing, and the internet at large uses a
path-vector protocol (BGP) which seems to work better as it requires
less cooperation between nodes.

Note that link-state routing of hop-by-hop-routed protocols requires all
nodes to compute exactly the same paths to avoid cycles. This may be
another reason the Internet uses path-vector. This limitation doesn't
apply to source-routed protocols.

[Grant Taylor]

On 12/19/23 08:04, immibis wrote:
> Note that link-state routing of hop-by-hop-routed protocols requires all
> nodes to compute exactly the same paths to avoid cycles. This may be
> another reason the Internet uses path-vector.

Agreed on all accounts.

The Internet presents another problem for link-state protocols, and
that's how often things change.

Things are constantly changing on the Internet for various reasons; many
good while some bad. Such changes would mean that calculation would not
finish before the next change happened, thus never stop and constant
churn / path calculation.

[Andy Valencia]

immibis <ne...@immibis.com> writes:
> Could you adapt a routing protocol such as OSPF?

I remember living with source routing. At its best, it was rather
cool. At its worst, it was tedious. By the end, I mostly just lobbed
my email at ucbvax and let them figure it out.

If your topology doesn't change very often, you can distribute it
as files. This was the UUCP Mapping Project, again one of those
very late-stage things before UUCP went away.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

[immibis]

On 12/26/23 00:06, Andy Valencia wrote:
> immibis <ne...@immibis.com> writes:
>> Could you adapt a routing protocol such as OSPF?
>
> I remember living with source routing. At its best, it was rather
> cool. At its worst, it was tedious. By the end, I mostly just lobbed
> my email at ucbvax and let them figure it out.
>

Which is the same way Internet routing mostly works - we lob packets at
our ISPs and let them figure it out. Our ISPs lob packets at their
transit providers and let them figure it out, except when a direct or
IXP peering exists.

> If your topology doesn't change very often, you can distribute it
> as files. This was the UUCP Mapping Project, again one of those
> very late-stage things before UUCP went away.
>

And the Internet does this automatically with routing protocols. BGP
doesn't build a full map, but it's not wrong to say that each ISP of a
sufficient size has a file that lists how to reach every other ISP, and
these files are maintained automatically.