2010/3/8 Hellekin O. Wolf <[email protected]> > 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=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 > > >
