Your peer-to-peer proposal is awesome, but also quite ambitious. Is
there really one true way to do peer-to-peer? I don't have any expertise
on the topic, so I'll defer to others.

> I meant to write that many other SRFIs should or could be written
> before this one. Here is the one I can think of:
>
> - UDP or TCP or Web sockets

Prior art:

- SRFI 106: Basic socket interface (2013)

- Quite complete BSD sockets API for Chicken:
https://wiki.call-cc.org/eggref/4/socket I've been thinking of writing a
full BSD sockets SRFI based closely on this. The Windows WinSock API is
a close copy of BSD sockets so it would have to work identically on that
as far as possible.

- Chez Sockets: <https://github.com/arcfide/chez-sockets>. IMHO this API
is very hard to use.

- Gambit has sockets as device ports:
<http://www.iro.umontreal.ca/~gambit/doc/gambit.html#Network-devices>
and DNS lookup starting at
<http://www.iro.umontreal.ca/~gambit/doc/gambit.html#Service-information>.

- Gauche BSD sockets wrapper:
<https://practical-scheme.net/gauche/man/gauche-refe/Networking.html#Low_002dlevel-socket-interface>

- Taylor Campbell's comments on lackluster socket APIs. Search for
"2006-09-16 On networking interfaces in Scheme" at
<https://mumble.net/~campbell/blag.txt>.

To Taylor's comments, I would add that the address/port/socket-options
interface is hard to do well. It tends to be either too simple or too
complex. I have an idea but haven't had time to test it.

> - Binary scheme expressions

If you mean writing S-expression-equivalent data in a binary format, see
long conversations between John, Alaric and I on schemepersist mailing
list. Working code at <https://github.com/lispunion/database-subprocess>
in files <binary.*>. We're debating switching to an ASN.1-based format.