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

It is worse than spam. Any peer can DoS another peer with its uid. I
will need to change that into something that only allow one put
operation per (ip, port, uid) association.

This is a problem that was solved in gnunet somehow.