Hi,

Amirouche Boubekki <xxxxxx@gmail.com> writes:
> Thanks for joining the mailing list.

I’m trying to find enough time to be useful here :-)

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

It’s pretty hard to get to the level of Freenet :-)
(I haven’t yet seen a program which got close to Freenet in terms of
 privacy and censorship resistance)

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

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

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

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

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

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

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

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

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

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

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

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

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.

It could be useful to return records (from SRFI-9 or R7RS) as return
values — maybe as an additional format, not as only format (so it’s
possible to build fast-paths).

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken