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 — though they are currently mostly used to test
the network performance and insert data.

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

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

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

;; basic operations
- genkeypair ;; generates a keypair
- put! private-key path value
- get public-key path
;; introduction
- create-captcha! private-key
- solve-captcha public-key path
- watch-captchas ;; needs state from create captcha
;; spam-defense
- set-trust! public-key path
- get-trust public-key path
- get-score public-key path

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.

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

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