Hello Arne,

Thanks for joining the mailing list.

Le dim. 13 oct. 2019 à 13:35, Arne Babenhauserheide <xxxxxx@web.de> a écrit :
>
> Hi,
>
> Amirouche Boubekki <xxxxxx@gmail.com> writes:
> > My interest in this group is to gather ideas and hopefully cooperate
> > together to build peer-to-peer applications
>
> I have some working tools that build on existing peer-to-peer networks —
> specifically on Freenet —

Compared to Freenet, the qadom prototype is much less focused on preserving
privacy or being censorship resistant, see:

  https://framagit.org/amz3/qadom#qadom

See peer.py for the actual protocol implementation:

  https://github.com/amirouche/qadom/blob/master/qadom/peer.py

> though they are currently mostly used to test the network performance and insert data.

Interesting.

> A slightly outdated standalone file is available at
> https://notabug.org/ArneBab/guile-freenet/src/master/fetchpull-standalone.scm
>
> The up-to-date file with dependencies on some self-written libraries is
> https://notabug.org/ArneBab/guile-freenet/src/master/fetchpull.w

I do not understand how it works. Does it connect to another local
processus that implement the actual freenet wire protocol? Maybe it
does implement kademlia (or something similar) but it is not obvious
to me.

> The basic interaction needed to implement communication tools is in
> place.

We need to define or draw boundaries about what the p2p system will
allow. In my mind, it is better to avoid anything realtime at the
application layer. Also, big files would be better left to another
protocol.

> In an older python project[1] I showed that what’s needed to
> implement a communication tool on a DHT with immutable data is:

Public DHT are immutable if the key is always the hash of the value.
If one change the value, the key changes hence the immutability. The
pre-SRFI describe three datastructures, the vanilla hash-table where
the key is the hash of the value, so called distributed hash-table.
There is also the "bag" that is a mutable free-for-all datastructure
that will allow to promote immutable or signed keys. At last they are
signed keys aka. namespaces.

The naming is probably off.

I also would like to add a way to store geographical or temporal
information maybe via Xz space filling curve.

> ;; basic operations
> - genkeypair ;; generates a keypair

That is the cryptographic toolkit that provide those primitives. Maybe
it should be part of one spec?

> - put! private-key path value
> - get public-key path

That is equivalent to the namespace procedures:

  https://github.com/scheme-live/peer-to-peer#namespace-procedures

> ;; introduction
> - create-captcha! private-key
> - solve-captcha public-key path
> - watch-captchas ;; needs state from create captcha

What is it?

> ;; spam-defense
> - set-trust! public-key path
> - get-trust public-key path
> - get-score public-key path

Trust is a big topic.

I was planning to push that to downstream. Mostly. The pre-SRFI
describe foobar-at procedures that allow the application to work
around key-space poisoning:

Imagine there is HASH that is interesting. Say, an organization does
not want you to access the value associated with HASH. It can spawn
max replication factor, currently 20, or more peers with UID that are
near or even equal to HASH. The kademlia algorithm will look for uid
that are near HASH using bitwise-xor... If all the nearest peer claim
they do not have the associated key, it will appear like the key does
not exist. But:

- The algorithm will walk the key space, if the key is found before
reaching the nearest peers, it will be returned by the network layer.

- Otherwise, the application can fallback to use peer-ref-at against a
peer that it thinks has the value associated with HASH.

> The interface I wrote on top of that is a simple REPL-based interface:
> You have a simple command interface with the interactivity limited to
> sending commands and requesting states.
> On top of the input it shows updated state, so it can notify you of
> changes while you type.
>
> [1]: Details at https://github.com/freenet/pyFreenet/blob/py3/babcom_cli

> To separate the user-interface from implementation, it could be a good
> idea to model such an interface on an IMAP-like protocol: Commands you
> send need a unique ID and you can request the state of commands via
> their ID.

I am not sure text based protocol is a good thing. Like I tried to
explain, I would like to avoid the "microservices" approach for the
Scheme prototype. Implementations will be free to choose whatever
approach they think is good because only the wire protocol will be
specified. Similarly for the graphical interface.

The pre-SRFI describe distributed datastructures.

> On top of this you can then model a more complex interface with multiple
> states (because you can always request states asynchronously).

Yes, this is important for the specification. Maybe instead of
specifying the procedure exported by the scheme library, it will be
better to only specify the network messages sent between the peers. So
that, the implementation will be free to choose between sync or async
interface. Another approach could be to specify an optional callback
argument.