Some very high level thoughts on your proposal
(https://srfi-email.schemers.org/srfi-discuss/msg/12322901/):

> From: Amirouche Boubekki <xxxxxx@gmail.com>
> Date: Saturday, October 05, 2019 7:24 AM
>
> [...]
>
> # peer-to-peer
>
> ## Status
>
> Early Draft
>
> ## Abstract
>
> This library describe the primitives for a peer-to-peer network that
> can be used to implement networked applications that do not require a
> central server to work. It offers the building blocks to create
> decentralized applications.

Central servers should be allowed for, but as you say, not required.

> ## Rationale
>
> It is very schemey to operate toward a common goal in a distributed
> fashion. This library brings the distributed social characterics of
> Scheme to Scheme programs.

My biggest concern is having enough peers to make the effort
worthwhile.  That probably requires one or more compelling
applications, enough so that for example people will manually punch
a pinhole through their ISP's router's firewall.

For an application where data transmission requirements are modest,
the Skype supernode approach is an alternative to peer-to-peer.

This also needs to be viewed as "secure", not something that can
likely be hijacked for evil.  BitTorrent's "you have one job" of file
sharing limits mischief to a degree.  You touch on this in a reply
to Lassi:

> As far as I understand, to be able to offer the features required to
> build (rich internet) applications that are more complex than file
> sharing, one needs to have control over the code of the peer. And
> that is without mentioning some kind of security or network health.

That strikes me as a seriously unsolved problem (as I sit behind
uMatrix for my normal browsing: https://github.com/gorhill/uMatrix).

Network health also really needs to be done correctly, especially
for the potential *far* out peer locations I mention below:

> [...]
>
> The network protocol is based on serialized scheme expressions
> compatible with `write` prefixed with the size of the serialized
> expression in network byte order (TODO: big or little?). Because the
> network can not be trusted the procedure used to parse messages from
> the network must be safe.

Can we define that *our* network order is little endian, since that's
nearly universal today?  Whichever, we'll want some extra testing
effort to make sure big endian nodes really work ... probably should
run a Scheme instance in a simulated big endian host unless someone
has a big endian system handy for this sort of thing, or can dedicate
a bi-endian system to this.

> The maximum size of serialized scheme expression transmitted over the
> network know as message is defined to be 1 megabyte.

And you later said:

> This is an arbitrary value. That limitation requires lots of
> bookeeping to make sure that network procedures do not try to reply
> with a big message...

I'm *really* uncomfortable with making this a hard limit.  Sure, it
sounds more than big enough today, and as you comment using UDP for
anything bigger is likely to be iffy, but for basic infrastructure we
should allow for lots of unanticipated growth and developments, using
something other than UDP, etc. etc.

See for example the fates of the PDP-6/10, DEC's first mainframe
family with a hard 256 Ki word address space, 1 MiB of 9 bit bytes,
and the contemporary IBM System/360, initially 24 bits byte
addressed, so limited to 16 MiB, but easily enough extended to 2 GiB
before going 64 bit.

> [...]
>
> A peer initiating a request must wait for a reply at most 5 seconds.

Another hard limit that should be thought about.  Colonies on the
Earth's moon, and in space in our Earth-Moon Lagrangian points,
are close enough to consider including in the remit of this system
(https://en.wikipedia.org/wiki/Lagrange_point_colonization), and
let's say they enforce a minimum round trip of ~2.5 seconds.

I can imagine terrestrial situations where a long round trip is
possible, although I'm not sure they'd be suited for this protocol.

> [...]
>
> #### Distributed-Hash-Table procedures
>
> ##### `(peer-set peer value) → bytevector`
>
> Set `VALUE` bytevector in the network at the nearest peers to the
> SHA-256 of `VALUE`. Returns the SHA-256 of `VALUE` as bytevector....

If I'm groking this correctly, the absolute security of SHA-256 is not
an issue in the protocol.  This should be confirmed, and explained so
that when SHA-256 goes the way of SHA-1 we can say, "here, it's not an
issue", or an allowance should be made for transitioning to SHA-3 or
future undetermined secure hash functions.

Can we assume a hash result of 256 bits is future proof?

- Harold