Le sam. 19 oct. 2019 à 00:43, Arne Babenhauserheide <xxxxxx@web.de> a écrit :

> >> 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.
>
> It connects to a full Freenet node that provides services similar to a
> DHT (but with private/public key crypto to provide personal keyspaces).

namespace procedures in the peer-to-peer document rely on
private/public key crypto.

>
> >> 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.
>
> Big files are one of the things which are easiest with peer to peer
> programs. For example Gnutella provided torrent-like swarming without
> tracker by exchanging additional sources with other downloaders.

The file sharing problem is almost or already solved by other protocols.

> See http://rfc-gnutella.sourceforge.net/developer/tmp/download-mesh.html
> and http://web.archive.org/web/20091203212059/http://open-content.net/specs/draft-jchapweske-thex-02.html
>

Thanks.

> >> 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.
>
> Signed keys and immutable keys are understandable, I think. Or rather
> they are what I know …
>
> A mutable free-for-all datastructure is dangerous: it needs some kind of
> rate limit or exposure limitation, otherwise you’ll see spam.

Spam is inevitable. The mutable free-for-all datastructure items will
have a Time-To-Live. Also that is why I think there should be way to
blacklist IP from the application layer.

>
> >> ;; basic operations
> >> - genkeypair ;; generates a keypair
> >
> > That is the cryptographic toolkit that provide those primitives. Maybe
> > it should be part of one spec?
>
> Yes, I think so.

Ok.

>
> >> - 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
>
> Yes. Why is the public-key in peer-namespace-set? Can the public key not
> be calculated from the private one?

There is mistake, the public key and the private key should not be
passed to the network layer in this case. I think the signature should
be:

  (peer-namespace-set peer key value signature)

Where the signature is computed beforehand.

>
> Why does peer-namespace-set not end with a bang (!) ? I would have
> expected it to, because it mutates a datastruture.
>

It will. Thanks for noticing.

> >> ;; introduction
> >> - create-captcha! private-key
> >> - solve-captcha public-key path
> >> - watch-captchas ;; needs state from create captcha
> >
> > What is it?
>
> This is a way to provide CAPTCHAs on a per-user basis. Others can solve
> your CAPTCHAs to inform you about something new.
>
> It is not enough to prevent spam on its own, but it provides a
> rate-limit that helps level the playing ground between spammers and others.

Ok, I will need to investigate this.

>
> >> ;; spam-defense
> >> - set-trust! public-key path
> >> - get-trust public-key path
> >> - get-score public-key path
> >
> > Trust is a big topic.
>
> Yes, and it is hard to get right, and to get it right, it has to be
> optimized for the network to avoid overhead (that you cannot afford in
> such a hard challenge).
>
> >> 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.
>
> For the wire protocol it would be nice to have something very efficient.
> But that’s hard to do. In Gnutella three teams of 5 or more people each
> worked for half a decade to build a very efficient protocol.

Ok.

>
> > The pre-SRFI describe distributed datastructures.
>
> Do you know the current state of the art of distributed datastructures?
> With their performance characteristics and guarantees?
> I’m not as up to date as I’d like to be.

Sort of. Maybe you think about CRDT [0]. I do not think they are
useful in environments that can not be trusted.

[0] https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type

>
> >> 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.
>
> I think it would be better to define an API and allow experimentation
> with the network protocol.

Without a common wire protocol, there will be no cooperation possible.

>
> For example you could define a set of async procedures. For example:
>
> (peer-namespace-ref/async peer public-key key signature) → returns uuid
> (command-get-state uuid) → 'pending 'running 'canceled 'complete
> (command-get-result uuid) → bytevector

That is promise-based API.

> For (peer-set peer value) I would like to know the peers that received
> the value. This allows health checks of the network, and even size
> estimates.

I will think about it.