Had we known in 2003, that in 2016 we are still stuck on commercial social network offerings that spy on us, maybe we would have worked harder on this topic…

Contents

[edit]

Decentralized vs. Distributed Social Networking

While psyced provides for decentralized social networking via federation, PSYC2 aims for distributed social networking with agnostic relays rather than servers. The reasons for such a choice are both the privacy and scalability properties of a distributed solution.

Since PSYC is about people and communication it provides friendship and trust modelling. Since 2003 we have been researching the idea of decentralized social networking with activity streams, friendcasting and a distributed social graph. To achieve functionality people expect from Facebook, Xing or Myspace, but without the loss of privacy and control.

By now there are dozens of projects in the field of federated social networking that now do it like we started in 2003, but we have grown to believe federation over servers is the wrong architecture for data as private as this and server-based tools will never convince people to stop using Faceboogle, that's why with PSYC2 we are digging into distributed architectures, pseudonymous routing and launched a project called secushare.

But if you want to discover the social features of psyced here and now, keep reading.

[edit]

psyced friend of friend surfing

Friendsnets functions in PSYC1: We have a web-based profile view. It allows you to surf along your social network of friends and friends of friends without ever leaving the built-in web server of your home server, because the profiles are transferred by the PSYC protocol.

Unless you have a native PSYC client that enables you to just click on psyc: uniforms, you need to issue /surf in order to actually see your own and your friends' pages, then follow the link. This only works if you have the web server enabled in your psyced. (There's also the /login command which will generate a new token to make sure older surf sessions are obsoleted.)

The server also allows people a public view of your profile using the home server's https: or http: address and ~nickname as the path, but the public view will hardly grant information to anonymous people and search engines.

You can expose your friends in your profile, but still control it the way you want it, using the new commands /expose, /trust, /set friendsexpose and /set groupsexpose. Specify who gets to see what, if you want.

You can specify your own style sheet and profile photos using /set stylefile and /set photofile. Make your web profile look really nifty. You can also link the photo to a /set photopage, which then is a regular web page for now.

It's not that PSYC is about nifty profile pages, but we're heading towards providing an open, decentralized and privacy enhanced alternative to the big centralistic social network companies, while also trying to be the best chat technology in the universe.  ;-)

Of course all of these slash commands are only waiting for a nifty client programmer to implement them thru flashy buttons, wizards and menues. PsycZilla does some of that.

See also the trust document for an explanation of what happens behind the scenes when you surf your friend-of-friend network.

[edit]

Decentralized microblogging

psyced has code that allows for microblogging. It shows up on your profile together with comment boxes, so your friends can comment on your updates — even though they are HTTP-wise on their own server, not yours. You can even choose which updates to send in copy to existing non-private services using the Twitter API.

[edit]

Related work

the Gradman Paper is a sketchy but broad introduction to the topic. he gives hints to almost all interesting aspects including essential links to dig further.
  • Jon Kleinberg's paper on decentralized algorithms in social networks ("The Small-World Phenomenon: An Algorithmic Perspective", [1]), linked from the above
very interesting read. the proposed class of networks and the algorithms he uses to deliver messages from a source to a target (unknown to the source) within those networks does not work for social networks in the internet. the main assumptions made by Kleinberg are that (1) to every node all local contacts are known (i.e. the global structure) and that (2) every node knows the location of the target. depending on how to define local contacts in our case (could be same homeserver) we end up having a strongly clustered network (totally different problem) or having to drop assumption (1) (in case friendships are local connections, the mesh is only known locally, i.e. up to distance one). assumption (2) is true only if we assume the clustered case, because it possible to find the cluster someone is in. in the second case of an unknown mesh structure the location is known if and only if someone is a local contact (trivial case). conclusion: the paper may work fine for real world applications on planet earth where nodes are located geographically (as in Stanley Milgrams original paper) but makes no sense in case of online social networks. I dont see why Gradman used it as a reference.
  • Adina Levin wondering on decentralized social networks.
[edit]

Why not XMPP?

Jabber is a better choice for networking social networks than HTTP, from a technical point of view. But XMPP has a scalability issue with any information that needs to go from one point to several (see Jabber for details).

Imagine a Myspace or Facebook number of people, decentralized over thousands of servers, all subscribed to each other by friendships. They typically have subscriptions in the hundreds. Each of them. Each time one person uploads a photo or changes his mood, using XMPP he will trigger hundreds of connections to inform hundreds of friends of these events. Not talking about friendcasting your latest radio show.

XMPP subscriptions, be it using presence, pubsub, PEP or MUC - none of these technologies solve the problem of distributing the information in a strategically intelligent way. Not only aren't multicast trees available for topological routing, the same message is even copied to every server in n copies - a copy for each recipient. The reasons why this is so and is not going to change anytime soon (we tried to change that!!) is discussed on the Jabber page.

The amount of many-of-many messaging for this application is so large, that it absolutely requires true multicast capabilities, not just protocols that use that word. Otherwise it will break down in the middle of growing popular.

Another reason not to use XMPP is that it isn't a pseudonymous routing system, so the metadata of who is talking to whom is impossible to hide. With XMPP the nation state agencies still know your entire social graph as before. Yet, projects like buddycloud insist on this trajectory.

If you don't agree, please let's discuss details in the welcome room. I am happy to fill in any gaps of information that leads me to this conclusion, or to fix my knowledge on new developments.
[edit]

the GNU Social

On http://groups.fsf.org/wiki/Group:GNU_Social a group of developers discusses the wish for a free facebook-like platform, but in a decentralized way. We agree with most that is said on that page, except for the PHP. We believe such a platform needs a truly interactive protocol and should not be built on top of HTTP which makes PHP a less optimal platform for implementing those functions. We like how far psyced has already gotten in providing such a decentralized social network.

[edit]

XFN: XHTML Friends Networks

XFN is a simple distributed friendship microformat built on top of the world wide web. XFN represents relationships by using the rel= attribute within html links. The XFN meta data profile defines meaningful values that can be seamlessly applied to documents without departing from web standards. It could be useful to provide a way for psyc user profiles to represent the same meaningful relationship information that is expressed by XFN.

Fore more on XFN, see Relationship Classification

How does this relate to PSYC? Well.. in PSYC we use the PSYC protocol to exchange this information. Wrapping it up into XML documents would make it an unnecessary hassle. Exporting information into microformats wouldn't be hard to do at all, but the whole point of microformats is to make things accessible in web pages - that means throw away privacy - we don't want that. Of course one could figure out ways to do a social trust based HTTP authentication to make only the right people access that data, but since OpenID isn't enough to do that, you'd need authentication (OAuth seems to fill that gap). Also you would need to generate different web pages depending on who's asking. All in all you are re-inventing PSYC's trust and profiles with a more complicated syntax and less efficient transport protocols. See below for details on that.

[edit]

But.. why microformats?

(Part of a discussion going on in http://microformats.org/wiki/social-network-portability)

I took some time reading into http://groups.google.com/group/social-network-portability/topics ... I notice the principles making sense, and then I sometimes read about the technology you intend to use and find myself raising eyebrows..

According to http://microformats.org/wiki/social-network-portability we all agree that our goals are:

So nice how you put them together and interesting how each of these already has a page on our wiki, as we consider them all features of PSYC. But what I really can't understand:

  • If privacy is a goal, why do you think in microformats that only make sense in published content on the web? Isn't the web just the completely wrong technology here?
  • If notification is a goal, why do you try to use HTTP? A protocol profoundly not designed to that purpose and not suited for that?

May be impractical to ask such a question on the microformats wiki, but I expect you can deal with it.. right?

... in the meantime I got an answer. The choice of HTTP is not for efficiency but out of mere commodity: A PHP server is a cheap thing to rent. A server capable of running real software thus real protocols is more expensive. That's why HTTP abuse is so popular. The fact that has more latency and makes simple things in a really complicated way is also secondary to how simple things look from a programmer's perspective. If the API hides away all the complexity in generating XML documents, these posting them by HTTP somewhere after completing a TCP handshake, then that operations become apparently simple.

Whereas a real messaging protocol which sends a handful of quickly assembled bytes over a stable TCP circuit is considered complicated, because you first need to have a framework that offers it, and it should be integrated into commodity rental servers. We have a chicken/egg problem here, that reminds me of the general problem of net neutrality: If everyone thinks HTTP is the good guy and all other protocols are bad and need to be firewalled, then the Internet is slowly perverted into the World Wide Web without Internet. The people who used to see these two things as equal.. are winning.

[edit]

the Private Web

The idea is to apply the friendsnets' web of trust and PSYC authentication to HTTP and come up with entire websites that are socially aware and unavailable to the general public. See the Authentication page for more on this. The web of trust also applies to encryption, allowing for TLS-encrypted communications without having to trust third-party authorities (the traditional X.509 model). With PSYC2 this becomes even more interesting since such websites can stay updated by pubsub multicast on the recipients computers, ensuring that only your computer knows when or how you are making use of such website.

[edit]

Crypto sharing

lynX has written up a plan for a crypto sharing technology encompassing social file transfer (friendcasting an mp3 for instance) and CryptoChat (having an end-to-end encrypted chat with friends in a shared chatroom). This has evolved into secushare.

[edit]

Public discourse

Some articles on future decentralized social networking and microblogging:

[edit]

the Fitzpatrick Manifesto

On http://bradfitz.com/social-graph-problem/ Mr. Brad Fitzpatrick writes a public manifesto for just this sort of technology. And yes, we agree with it to large extent.

  • Developing "Social Applications" is too much work.
And developing a decentralized one is even worse.
  • People are getting sick of registering and re-declaring their friends on every site.
In fact their patience is greater than any expert would ever have expected.
  • any one of these sites shouldn't own it; nobody/everybody should. It should just exist.
  • Establish a non-profit and open source software
We gotta work on that non-profit thing... Right now we are living off developer idealism which is actually more valuable than a non-profit organization, but probably less transparent.
  • While the non-profit's servers and databases will initially be centralized, ensure that the design is such that others can run their own instances, sharing data with each other.
Since we already have a decentralized technology to do the job, we don't need to pick an initial intermediate solution, we can go straight for the real thing.
  • Node Equivalence is not necessary, we only have one set of data - but we have algorithms that decide who gets to see what, and we can have data replication for safety. The applications only have a subscription to your data, you never need to go get your data from there. It is you pushing your data to them whenever you think it is appropriate.
  • Find nodes, edges, aggregates: The necessary data is not centralized, but thanks to the distributed push state you have all the data that you are entitled to have ready for computation. So you will be able to make those computations, if everyone agrees with you doing them.
  • You should never need to look for missing edges and sync your social networks, because by pushing that information to them, it is already in sync (Of course a server may be down, but that problem is delegated to a lower layer - reliable message transportation, no matter whether it is social network or any other important information).
  • End-user tools.. yeah.. portable graph documents.. probably not feasible, as by becoming static they can quickly go out of sync with what your friends are doing.
  • Non-Goals. Well, you or your friends may find yourself not wanting to trust such large sized applications after a while, and applications will become smaller and more wide-spread, like everyone running his own little facebook-like engine.. but even then a large portion of public will love to stick to the big players. It is not our goal to exclude any such big player.
  • Only public data is an unnecessary restriction.
  • Friend data should not be public, and there is no need to not handle profile data.
  • XML and whatever other formats are formats suitable for transmitting complex data, but the modifications happening to the social tree are single leaf events. They don't need complex data structures, they need an efficient event notification protocol.
  • End users can work on the stuff using a web interface, but you need people to install back-end software - and you don't want to keep it centralistic - it would always be an object of desire and position of power, no matter how nice the non-profit organization.
  • users don't always want to auto-sync their social networks. That's why a programmable technology running on your own machine is a very trustworthy and flexible solution.
  • Funny you mention OpenID so often. Decentralized authentication in PSYC is a lot easier to do than OpenID, because we no longer use the inappropriate HTTP protocol.
[edit]

2010: A Call For an Open, Distributed Alternative To Facebook

More and more voices calling for the solution, some asking for a website to deploy yourself that will somehow magically attract the attention of your peers away from Facebook – Some others asking for a new social P2P infrastructure that actually brings so much more than just Facebook-like activity streams and event calendars that people will have a reason to move ahead not just because it's better for our collective privacy.

[edit]

Towards a real distributed social network protocol

The Seldo Weblog comes to similar conclusions as ours. Reading through the article with the PSYC goggles on shows how much of it is already in our hands and few things are missing:

Our group communication technology goes way beyond what this article requires. Search is just another friendcast, although I don't believe it needs to be so essential.

The things missing are:

and most of all.. a user interface.

[edit]

Further Reading

Companies won’t own your “friend” list; you will, he said.