peer-to-peer Amirouche Boubekki (05 Oct 2019 12:24 UTC)
We need a pre-SRFI list hga@xxxxxx (05 Oct 2019 12:41 UTC)
Re: We need a pre-SRFI list Arthur A. Gleckler (05 Oct 2019 19:14 UTC)
Re: We need a pre-SRFI list hga@xxxxxx (05 Oct 2019 20:20 UTC)
Re: We need a pre-SRFI list Duy Nguyen (06 Oct 2019 01:47 UTC)
Re: We need a pre-SRFI list elf (06 Oct 2019 01:51 UTC)
Re: We need a pre-SRFI list hga@xxxxxx (06 Oct 2019 02:18 UTC)
Re: We need a pre-SRFI list elf (06 Oct 2019 02:33 UTC)
Re: We need a pre-SRFI list Arthur A. Gleckler (06 Oct 2019 04:57 UTC)
Re: We need a pre-SRFI list hga@xxxxxx (06 Oct 2019 11:42 UTC)
Re: We need a pre-SRFI list Amirouche Boubekki (06 Oct 2019 06:09 UTC)
Re: We need a pre-SRFI list Arthur A. Gleckler (06 Oct 2019 17:30 UTC)
Planning how to organize Scheme discussion Lassi Kortela (06 Oct 2019 17:48 UTC)
Re: Planning how to organize Scheme discussion hga@xxxxxx (06 Oct 2019 19:41 UTC)
Re: We need a pre-SRFI list Arthur A. Gleckler (06 Oct 2019 18:30 UTC)
Re: We need a pre-SRFI list Lassi Kortela (06 Oct 2019 19:31 UTC)
Re: We need a pre-SRFI list Amirouche Boubekki (06 Oct 2019 19:48 UTC)
Re: We need a pre-SRFI list Amirouche Boubekki (06 Oct 2019 19:56 UTC)
Re: We need a pre-SRFI list elf (06 Oct 2019 01:53 UTC)
Re: We need a pre-SRFI list Vladimir Nikishkin (06 Oct 2019 03:06 UTC)
Re: We need a pre-SRFI list Duy Nguyen (06 Oct 2019 04:13 UTC)
Matrix libraries Lassi Kortela (06 Oct 2019 14:51 UTC)
Re: Matrix libraries John Cowan (06 Oct 2019 17:55 UTC)
Who's working on what? Lassi Kortela (06 Oct 2019 19:39 UTC)
Re: Who's working on what? Amirouche Boubekki (06 Oct 2019 20:19 UTC)
Re: Who's working on what? Amirouche Boubekki (06 Oct 2019 20:26 UTC)
Re: Who's working on what? John Cowan (06 Oct 2019 20:40 UTC)
Re: peer-to-peer Amirouche Boubekki (05 Oct 2019 14:43 UTC)
Re: peer-to-peer Arthur A. Gleckler (06 Oct 2019 05:14 UTC)
Peer-to-peer, sockets and binary s-expressions Lassi Kortela (06 Oct 2019 12:41 UTC)
Re: Peer-to-peer, sockets and binary s-expressions Amirouche Boubekki (06 Oct 2019 13:46 UTC)
Re: Peer-to-peer, sockets and binary s-expressions John Cowan (06 Oct 2019 20:35 UTC)
Re: Peer-to-peer, sockets and binary s-expressions Vladimir Nikishkin (07 Oct 2019 02:42 UTC)
WebSockets Lassi Kortela (06 Oct 2019 12:47 UTC)
Re: WebSockets Per Bothner (06 Oct 2019 14:40 UTC)
Re: WebSockets Amirouche Boubekki (06 Oct 2019 19:53 UTC)

Re: Peer-to-peer, sockets and binary s-expressions Amirouche Boubekki 06 Oct 2019 13:45 UTC

Le dim. 6 oct. 2019 à 14:41, Lassi Kortela <xxxxxx@lassi.io> a écrit :
>
> Your peer-to-peer proposal is awesome, but also quite ambitious.

Yes, it is not a simple or easy matter. But it is also lighter than
the competition.

> Is there really one true way to do peer-to-peer?

As usual, I had a look around. TL;DR: There is no other way, so far.

- IPFS: Only the JavaScript (and maybe the Go) implementation are in a
working state.
  The real problem with IPFS is that the specification / documentation
is not good enough.
  Last time I checked, around 6 months ago, I could not implement IPFS
just based on those.
  Also see https://github.com/orbitdb/orbit-db

- gnunet: I was heavily invested prior to 0.11.0 release. gnunet is
the only project that is both
  portable across operating systems and that one can bind using C
Foreign Function Interface.
  The main problem with gnunet is that it is _very slow_. Also, it
took me less time to create the
  prototype mentioned previously. Otherwise said, it is difficult to
work with gnunet.

- Freenet is based on the JVM.

- GNU Jami is coded in C++ and last time I checked it doesn't have C wrappers.

- DAT and Scuttlebutt are not documented and running on top of NodeJS.

- WebRTC requires a server to work.

Most of peer-to-peer work and knowledge was invested in libtorrent
(C++ with abandonned C wrappers). There is a specification, but so far,
libtorrent doesn't support BEP-50 (pubsub) and BEP-46 (mutable dht).

[0] http://bittorrent.org/beps/bep_0050.html
[1] http://bittorrent.org/beps/bep_0046.html

Also https://en.wikipedia.org/wiki/Bencode.

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.

I am not trying to convince anyone that prior art is full garbage.

So far, peer-to-peer tools were not deployed in a way that would allow
one to say
that there is an industry standard. Torrent protocol is too restricted
to build the kind
of application I am thinking about. The common pratice is to rely on kademlia.

They are things to learn from existing projects, but as far as I
understand, there is also
room for innovation(s).

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

Indeed. I like that paragraph:

>  Unfortunately, programmer laziness in conjunction with a misguided
>  desire for `nicer' interfaces tends toward not supporting any more
>  esoteric capabilities of BSD sockets or flexibility for later
>  extension or protocol independence.

I made a mistake in the early draft, send and recv procedures are not enough.

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

Thanks I will look around.