Le lun. 14 oct. 2019 à 20:50, <xxxxxx@ancell-ent.com> a écrit :
>
> 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,

If we build it, they might come. Like I tried to explain previously,
there is basically no public facing application that rely on
peer-to-peer. The reason is not because there is no interest, but
because there is no tools to do it.

> enough so that for example people will manually punch
> a pinhole through their ISP's router's firewall.

I think, if we explain how peer-to-peer is worth compared to the
centralized approach (including the fediverse) they will invest the
required time to open the required port. They prolly have done it
already for other tools.

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

What is Skype supernode?

> 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.

Mischief in file sharing is common. Virus spread via such tools. The
application will primarily share documents in the spirit of JSON REST
APIs. It will always be possible to transfer bytes and an application
might store it on disk and even execute it. But that will be the
responsibility of the user to not install peers that are not trusted.

>  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).

I also use uMatrix.

The peer-to-peer network does not prescribe a particular graphical
user interface. The described peer-to-peer network is a distributed
data structure, to some extend it can be seen as a distributed REST
API or a distributed REDIS. Even if some policy is established by the
kademlia algorithm e.g. you can not store a value where you want, it
still gives a lot of room for applications and mischiefs but that will
be the responsibility of the peer developer to avoid security
problems.

Simiarly to a REST API, peers must agree on some document schemas and
vocabulary to be able to interop. So, on top of the peer-to-peer
specification, there will be something similar to activitypub
https://activitypub.rocks (maybe activitypub as-is)

Some application developer might agree to store JavaScript inside the network.

When I write the following:

> > that is without mentioning some kind of security or network health.

I think about both the peer-to-peer network poisoning (via an attack
against a given HASH) but also attacks at the UDP layer.

See also https://en.wikipedia.org/wiki/Sybil_attack

>
> 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.

IIRC there is no technical limitation between little and big endian.
The thing is that one should avoid the name "network order" if it is
not the commonly understood endianess.

>
> > 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.

My idea behind the UDP with 1Mb payload has multiple facets:

- Security: Connectionless, so no connection poisoning
- Developer productivity The UDP API is easier to use
- 1 Mb is a lot when you consider that it is only text data (no video,
no images, no javascript)

I do not believe in unanticipated growth.

For big files, around 10Mb, we can think of some kind of pagination schema.

For very big files, bigger than 10Mb, there is bittorrent.

>
> 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.
>

This is not IPFS. My idea behind this protocol is to solve today's problems.

> > [...]
> >
> > #### 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?

To some extent there is a security risk, if the attacker can generate
a value that has the same SHA-256 and is still smaller than 1Mb (minus
the header) and can be de-serialized using the chosen bytes-exprs. In
that case, the attacker can reply with that value, and the client will
try to deserialize it. That is why the read procedure must be safe.

Also, there must be enough number for everybody (IOT etc...) because
peers are spread in 256-bits space and all peers SHOULD have a unique
uid.

> - Harold

Thanks!