My 2 cents on (maid)SAFE

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============1936481251==
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="kLGOv5NM6ha07uihmsMCKBXeBjGpUcMmw"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--kLGOv5NM6ha07uihmsMCKBXeBjGpUcMmw
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Very similar to Freenet. A few interesting different choices. This is
just my first impressions from a talk; I haven't investigated in detail,
please reply if you have!

1. A proper DHT allows them to solve the dynamic content / updatable
content problem. The cluster of nodes closest to a key maintain
permanent connections to each other, so they can run consensus
algorithms. IMHO the best way to do this on Freenet is for updatable
keys (TUKs?) to be only updatable on one node, but then duplicate across
several locations in such a way that we can heal them all.
2. Economics allows them to implement permanent storage. Moving content
around when nodes go down (or in Freenet when they swap locations) must
be very costly. In any case I don't think they have an economy right
now. Updatable content in principle allows them to build one, but I
don't think basic mutable content is working at present.

The rest is very similar. They "telescope" requests, i.e. relay both the
request and the data, in much the same way as we do. They have CHKs, I
think updatable keys are similar to SSKs, and KSKs (which could be
spam-proofed by economics in future). Some things are much easier due to
it being a proper DHT. They use client-side data encryption for
plausible deniability (and privacy for non-public documents). They use
chunking. Telescoping is supposed to provide some privacy, which is even
less credible for them than it is for Freenet; routing is entirely
predictable!

They do not solve the Sybil problem. Internal payment systems cannot
solve the Sybil problem because the bad guys can always run nodes at a
slight loss - and the more of the network they control, the cheaper this
gets, since they can cheat internally as well as exploit economies of
scale. Especially as they can then undermine the internal currency
system - creating a financial incentive to control as much of the
network as possible. I don't think the Sybil problem can be solved.

I didn't stay for all the Q&A, so I don't know whether they have an
OMG-I-could-have-encrypted-child-abuse-images-on-my-PC problem yet. They
are more open to embedding in websites, javascript, etc, which we
generally reject for reasons of security; this is simply a choice -
privacy or dynamic content, you can't (easily) have both.

It is not clear what the plan is to solve the wider economic problem:
the internet is screwed because people don't pay for anything, therefore
we seek alternative revenue streams, i.e. owning everyone's data.

There is some discussion of micro-clients. E.g. phones can be clients
but not vaults. This means they need to get credits from somewhere else,
e.g. your home vault. On Freenet, mobile nodes don't make sense, but you
can connect to your home node. The other case is browsers - embedding a
distributed chat system in a regular website for feedback. Again, where
do you get the credits from?

They don't seem to have any publish/subscribe or ULPR type stuff yet, so
I seriously doubt that chat systems based on this will give acceptable
performance. However that is certainly feasible, and there may be some
better options than what we use on Freenet if they have currency working.=



--kLGOv5NM6ha07uihmsMCKBXeBjGpUcMmw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJYlxmsAAoJEBzu1zFxXR53TnUP/RWXKZMlyRxrV7oq3xmOb8Yj
LgZSczsDIb1N+WYmUVJEwidG2o2as5Z5ofR97oPy4jK3Vasnal44aHck+UTTfYgj
/hu22bUVJAN1JEwxwTiStTdROWw66MbkliM/vjxvY9qhYSQQ9b6eErNP2E+LG9kL
H+aocPaCVkLph2JnM8TNBNTLxaxAh8QrOkV3Jv0yOvgq+zq8VR09vNXpVutDOJBd
6cww0t5weYBwiw/AuPU3jEuFahTBIec6145V0Jpsl8DAO4vdIVqJoBdmVPyOSwtX
saDyNwPDMX+khsnVKQ++YHZzmiQuK0Auc4hkDGSdBs7N82neC7Nzosw8hSEMw/mE
kHRSiCmAMbNNh3tVmS5zf1LoFXY4t0+BUMQ6r+5bKnyU9Ywa6Fz62zwa/vRHdxHW
E2FRHPfUJJ6jgnQdaj0YlnspdtB19ahtoQSxfSJ5mrJfW8jffZ+ygaqi95I79Njc
m81q/caL724CNtIO9XG2tnvQHP84mWfJ0qd7jxFKCMfCg8isAyPGmV6zsTljhEB8
KA8jdOt/vGvbUe5Zz/1wl1aDy4Dm3J/gHNW2I/b/4hizvU7/kuqcsOlPUsrzBvDg
epHL+RORviG088aEryRhi0h2DMAk5fq6q2H5v28kU5jR+/bXIkeX/rdnQlUZ/Oev
Q9VUTxRn7EQR05lJGV10
=Dp7o
-----END PGP SIGNATURE-----

--kLGOv5NM6ha07uihmsMCKBXeBjGpUcMmw--

--===============1936481251==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVGVjaCBtYWls
aW5nIGxpc3QKVGVjaEBmcmVlbmV0cHJvamVjdC5vcmcKaHR0cHM6Ly9lbXUuZnJlZW5ldHByb2pl
Y3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby90ZWNo

--===============1936481251==--