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

[Melvin Carvalho]

2010/3/8 Hellekin O. Wolf <address@hidden>

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

Thanks for the pointer.  You mention global stability, do the users in the psych system have a global identity?  XMPP/JID kind of is one, but they're not easy to dereference.  OpenID is easy to dereference, but not so easy to get at more data, after that.  I think to be global you need identifiers capable of being global, else you're inventing yet another protocol, that everyone else has to build a bridge to.
 

 * 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="">]

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