Re: [Social-discuss] What should GNU social be?

[Hellekin O. Wolf]

On Wed, Mar 03, 2010 at 06:55:13PM -0500, Matt Lee wrote:
> 
> Should GNU social include the creation of a protocol for decentralized,
> encrypted communication between social networks? I think it should.
>
> [snip]
>
> What are your ideas for GNU Social?
>
*** Hello list!

At Dyne.org, we've been working on such topics in the last few months.
Here are a few ideas and directions so far, that breaks with the
casual idea about social networking...

The Delcorp folks have been working on Elgg for
[http://red.artelibredigital.net] and more or less everybody is
interested in PSYC [http://about.psyc.eu].

Using PSYC as the backend we aim at:

 * Global scalability: not by racking more servers, but with routing
   optimization (no unicast to unicast presence packet flood), and
   promoting server decentralization

 * Inter-Server Federation: psyced interconnects with XMPP S2S and IRC
   networks already, possibly other protocols.

 * Client diversity: XMPP, IRC, Telnet, HTTP, Email or native PSYC
   such as the jsPSYC library by tg

Etc. The PSYC protocol takes cares of the underlying routing.  One of
its goals, and a primary reason for our choice, is global scalability.
PSYC naturally distribute data between nodes to maintain the state of
the connection between them.  More PSYC integration with our websites
in under way.  Already, [http://hinezumi.im/] is providing a public
PSYC service.

We also worked on distribution / decentralization of data and came up
with a "Website Kit" using a combination of Emacs+org-mode, git and
make to provide contents in HTML, PDF, TEX.  A simple way for
developers to maintain a mostly-static website, offering
semi-automated mirror capability at the tip of a git clone and make.
[http://code.dyne.org/index.cgi?url=dyne-web/tree]

Apart from the technical side of it, some important points were made
during our conversations on the topic.

* Social Networking != Loss of Privacy

  Because the Social Graph is mappable doesn't  mean one has to abandon
  her concerns about privacy.  Today's large  SN such as Facebook    or
  Twitter encourage  publicity  of  your data, but  don't  allow you to
  export it in whole. 
  
  In the GNU Social Network, each participant  SHOULD keep its own data
  locally  or in a place of her choice (usually a trusted  server)  and
  federated servers  should  access it according to  the  participant's
  choice (and not, like I've seen for OAuth  implementations, according
  to the service  will: fined-grain grant of  access   to private  data
  MUST be  enforced by the  user, not imposed  by the querying service.
  In other word, the  fact I want to share  my  location with Service A
  doesn't mean I want it to know my name or email).
 
* Confidentiality

  What matters always as regards to privacy is the confidentiality of
  messages. Today, encrypting emails is not for the casual user, and
  there's no easy way to have your grand-mother include GPG in her
  Internet toolset.
  
  Sean O'Neil proposed PureNoise, an automated encryption layer that
  proxies all outgoing connections and encrypt the packets if the
  other side supports the PureNoise protocol. Although he didn't come
  up with the new version yet, I'm curious to see such a thing
  happening in the near future.

* It's not the Web!

  The web is one thing, but the Internet is bigger than that. The web
  makes it easy now to integrate different things and present them to
  the user and other apps. 

  Presenting a nice face and awesome UI is not the point. Making the
  data and functionality available is. The GNU Social network should
  allow anyone to participate with any tools she likes, with any
  degree of privacy she likes.
  
  Each participant should be able to maintain a complete collection of
  their contributions regardless of their destinations. E.g., have a
  copy of any comments made on any blogs, forums or micro-blogging
  services. 
  
  Each participant should be able to authorize a service for a single
  operation, review the operation and revoke any rights granted to any
  service at any time. Oauth is a good way to do it, but the current
  implementations tend to forget about that functionality and grant
  permanent access to all data to a service. Ahem.
  
  ...

I'm going to stop this and share it before it becomes an obsolete book
:)

==
hk