Re: Distributed architecture and social justice / at risk individuals

On Mon, Jan 12, 2015 at 10:37:41AM -0600, Christopher Allan Webber wrote:
> Francesco Ariis writes:
> 
> > On Thu, Jan 08, 2015 at 05:11:05PM -0600, Christopher Allan Webber wrote:
> >> I'm not proposing any thoughts of my own in this email... I think it's
> >> best to let hers take center stage.  But I'm interested in peoples'
> >> feedback on how we can make federated technologies more responsive to
> >> these needs/concerns?
> >
> > Not federated, but p2p projects like twister [1] and the more
> > comprehensive [2] gnunet plus some client side scripting should
> > address most if not all the problems.
> >
> > [1] http://twister.net.co/
> > [2] https://gnunet.org/
> 
> How so?


4. Self-doxing

You don't have to own a domain name to use twister (there are no such
things as domain names in twister), while, as long as you don't forget
your password, you (and only you) own your handle.
This means you can have an online presence without revealing your address
or contact information to /anyone/.

Tangentially related to the problem at hand, but it is worth to notice
that this [1] (removing content) would have been impossible on Twister.

[1] https://blog.diasporafoundation.org/4-islamic-state-fighters-on-diaspora


2. Securing your installation

To use Twister all I had to do was clone/compile a repository and launch
the application. While of course this is yet not ideal, it is far a simpler
experience than installing your average federated social network (my
experience: status.net).

Security is a `git pull` away, too, while owning your own server has some
overhead (i.e. more stuff you have to care about).


1. Lack of redundancy

I am going out on a limb on this one but I guess it is more difficult
to target a single user and silence them via a DDOS on twister. As long
as there are other users storing and forwarding your messages, everything
should be OK.
There is more on the matter on the Twister FAQ page [2] ('What is the
thread model for Twister').

[2] http://twister.net.co/?page_id=25


3. Block lists

As Ben Werdmüller eloquently explained:

> We're very concerned about these issues at Known, but I think a lot of them
> don't necessarily fall into the protocol design. Things like blocklists are
> implementation features of individual systems, and may even turn out to be
> features on which different systems compete. As an analogy, I think
> blockbots are not a million miles away from spam blacklists, and are
> totally cool in that respect - but those spam lists aren't a part of the
> core email protocol. Things like analyzing a third party user to determine
> whether they should be automatically blocked is a client feature.

Received on Tuesday, 13 January 2015 02:23:53 UTC