|
From: | Melvin Carvalho |
Subject: | Re: [Social-discuss] What should GNU social be? |
Date: | Mon, 8 Mar 2010 16:40:29 +0100 |
On Wed, Mar 03, 2010 at 06:55:13PM -0500, Matt Lee wrote:> [snip]
>
> Should GNU social include the creation of a protocol for decentralized,
> encrypted communication between social networks? I think it should.
>
>
> 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="">]
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
[Prev in Thread] | Current Thread | [Next in Thread] |