social
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Social] Re: [Social-discuss] Announcing P2P GNU Social


From: B. Kip
Subject: [Social] Re: [Social-discuss] Announcing P2P GNU Social
Date: Sat, 10 Jul 2010 13:29:43 +0900

Hi Ted,

I've read through the documents you linked below, but my technical understanding is thin and I'm still trying to wrap my brain around the issues involved in doing privacy on a  social network, so please bear with me :-)

I have three questions:

1. I was wondering why you are taking the approach of combining the storage and routing functions into a single core application.  In my own imagining about how this might work I was thinking that having the UI, storage (which could be physically fragmented), and routing as independent functions would allow for the most flexibility in configuring the network.  If these functions were all allowed to work independently, it wouldn't matter how they were packaged- they could all be combined into a single desktop app in one instance, and all be on different machines in different places installed and maintained by different people in another.  Since end-to-end encryption would allow the user to control all access to data, it shouldn't matter where any functions outside of the UI itself took place.  Is there a particular reason why you are combining them?

2. I'm also trying to understand the differences between the P2P GNU Social and Main GNU Social approaches to privacy.  I've read the Private Messaging Plugin description for GNU Social.  With respect to objectives- not implementation- as far as I can understand the main difference between the approaches is that P2P GNU Social works to privatize the social graph (connections between users) in addition to the content, while GNU Social only secures the content itself.  Both would keep content data encrypted end-to-end, provided it was encrypted at the origin.  So the most significant privacy difference (in terms of objective) between the two systems is exposure of the social graph.  Is this understanding correct? 

3. If the answer to no.2 is 'yes', what then are the main privacy implications of differences in implementation?

Brad


On Fri, Jul 9, 2010 at 8:21 PM, Ted Smith <address@hidden> wrote:
For the past few weeks, Miron Cuperman and I have been thinking about
how to do social networking in a p2p and privacy-enhanced way. We've
come up with some code and documents that describe a distributed social
networking system that is able to make and enforce strong guarantees
about user privacy while still providing usability in the same vein as
traditional, centralized or hub-and-spoke services. We've collected this
into an effort to build a P2P GNU Social.

The GNU Social P2P effort attempts to create a distributed,
privacy-enhanced and privacy-enforcing, user-controlled social network.
The goals of the P2P effort include:

* User Control - The user can run their own node on their own machine
with maximal ease of use and maintenance - it shouldn't take a sysadmin
to be social
* Privacy controls are not merely stated, but are enforced by strong
cryptography and time-tested protocols. All user data, including the
social graph, is private by default.
* Transparent developer access to other social networking systems,
including OStatus - the modular transport/translation system of the P2P
GNU Social will ensure that from the point of view of the end-user and
developer, there is only One Big Network.
* Modularity - Components in the node stack should be separated such
that it is simple to add and remove components. A full, working GNU
Social P2P node will be composed of several different individual
programs, and several different user interfaces. A strong client-side
API should enable developers to integrate P2P GNU Social into all
relevant existing desktop applications. Some of you may remember this
design from the document I posted to this list some months ago[1].
* Composition - Whenever possible, P2P GNU Social will borrow/loot from
existing Free protocols and implementations, though all code written by
us will be licensed under the AGPL.

To learn more about the P2P GNU Social design and structure, visit
<http://groups.fsf.org/wiki/Group:GNU_Social/P2P>. Currently, we have a
prototype for the GNU Social "core", written in Java, hosted on
Gitorious here: <http://gitorious.org/social-p2p/core>. We also have our
own mailing list at <http://lists.gnu.org/mailman/listinfo/social-p2p>
and an IRC channel at <irc://irc.freenode.net/social-p2p>.

We need people to help make this system a reality, by hacking on it and
fleshing out the protocol. Some things that people could get started
with include transport layers or translators for pre-existing networks,
and building user interfaces, ranging from a basic prototype to
integration with existing "social desktop" initiatives and mobile
devices.

We'd like to emphasize that this is **NOT** a fork of the mainline GNU
Social. StatusNet GNU Social and P2P GNU Social fulfill different niches
in the social networking space and should interoperate fully. If you
have to choose on one implementation to work on, it's probably better
for you to work on StatusNet GNU Social - there's more maturity and
it'll be possible to create free social networking systems faster. We
expect that P2P GNU Social will be more of a "research" effort - a
vanguard into privacy-enhanced social networking - which other social
networking systems, including and especially StatusNet GNU Social, will
be able to learn and build from. We have signed copyright assignment
papers with the FSF and expect contributors to do so as well.

We hope that many of the questions people have about how the network
works and how it guarantees privacy can be answered by our design
documents on groups.fsf.org, but please feel free to ask further
questions.

[1] http://groups.fsf.org/wiki/Group:GNU_Social/P2P/Node_Architecture




reply via email to

[Prev in Thread] Current Thread [Next in Thread]