LWN: Comments on "Toward federated services"

Toward federated services

raven667 — Wed, 24 Sep 2014 00:43:55 +0000

> Installing by means of gem, npm, pip etc. is not an alternative: First, it does not integrate with the native package management.

Either runtime-specific or system-wide package management is a valid way to manage applications but you cannot mix the two, whatever system you use needs to have a complete dependency graph so you can either have a separate runtime dedicated to your application or spend a lot of time building OS-specific packages for your dependancies. What would be interesting is to compare deb/rpm vs. cpan/gem/pip and see what special features one has that the other doesn't and see if there is any way to integrate the two universes, you can almost mechanically translate one package system into the other, for example cpan2rpm or python setuputils can make OS packages using the runtime-specific metadata.

Toward federated services

mpr22 — Tue, 23 Sep 2014 12:04:19 +0000

Might be cutting it a bit fine for Jessie; the freeze is scheduled for Gunpowder Night.

Toward federated services

debacle — Mon, 22 Sep 2014 22:23:26 +0000

AFAIK, all social network services are written in one or other dynamic language: Diaspora in Ruby (rails), Friendica in PHP, MediaGoblin in Python (Django), pump.io in JavaScript (node). So either write your own one in C or try to live with what others did.

It looks like not much is missing to get MediaGoblin running on Debian, maybe 0.7 will make it into Jessie. Let's see...

(Installing by means of gem, npm, pip etc. is not an alternative: First, it does not integrate with the native package management. Second, it does not solve the underlying problems Debian faces when packaging stuff, i.e. license problems.)

Toward federated services

mpr22 — Mon, 22 Sep 2014 12:30:55 +0000

... and thus I conclude that no, I will probably not be installing diaspora on my systems, because someone trying to package it for Debian has just successfully painted it as very nearly a perfect stereotype of what's wrong with the ecosystems of dynamic languages and the projects that are written in them.

Toward federated services

pravi — Mon, 22 Sep 2014 09:53:46 +0000

TextSecure is as easy as whatsapp with end to encryption and federated server, but getting people out of whatsapp or other services are harder than making easier competitor. It is a social problem and needs a big campaign to succeed.

Toward federated services

pravi — Mon, 22 Sep 2014 09:48:49 +0000

We have been working on apt-get install diaspora for last 3 years and we have come pretty close to completion (see https://people.debian.org/~praveen/diasbar/) Since it is a rails project, it has 183 direct dependencies and many more build dependencies (especially for running tests). Many times tests don't pass because their dependencies are changed in debian. By the time we finish 80% of it, we have to redo already packaged gems because their dependencies got updated. Any help (most needed help is to get tests pass for all dependencies, which needs more of ruby skills than packaging) in getting us cross the finish line is welcome.

Toward federated services

debacle — Sun, 21 Sep 2014 16:09:09 +0000

Unfortunately, at Debian we live still in dark ages:

$ sudo apt-get install diaspora friendica mediagoblin pump.io
...
E: Unable to locate package diaspora
E: Unable to locate package friendica
E: Unable to locate package mediagoblin
E: Unable to locate package pump.io

People are working on all of them but Friendica (see Debian bugs #597093, #651944, #657405, #726486), but at the moment it is not easy to run one of the federated services on your own Debian machine.

I'm sure, that federated services would attract more people, if actually running them were easy. As long as I have to use an unstrusted, 3rd party server, there is no big difference to centralised ones.

Toward federated services

BeS — Sun, 21 Sep 2014 16:00:29 +0000

I see the "chicken and egg problem" mentioned Prodromou as one of the main problem. To be successful we would need to reach a critical nunber of users. But this is not going to happen because even we, who advocate for such networks, don't agree about one direction. Some are on Diaspora, some are on Friendica, some on GNU Social, some are on pump.io. And then there are many even smaller solutions, e.g. the distributed networks based on xmpp. If we all would agree on one network or at least one protocol the chance would be much higher to get enough users together to become interesting for others.

Personally I think the old identi.ca aka Status.Net had the chance to reach this critical number of users. Further it wasn't just a Twitter clone but added some extra value like groups. With the switch to pump.io the situation become much worse.

Toward federated services

zack — Sun, 21 Sep 2014 14:18:06 +0000

> See the DebConf 14 keynote "Debian in the Dark Ages of Free Software", by Stefano Zacchiroli

Thanks for mentioning this, josh.

For people interested, here are the relevant links:

- slides: https://upsilon.cc/~zack/talks/2014/20140823-dc14-darkage...
- video: http://meetings-archive.debian.net/pub/debian-meetings/20...

Toward federated services

elanthis — Wed, 17 Sep 2014 07:53:34 +0000

> The idea is to find people according to their email address or a similar identifier (aka webfinger http://en.wikipedia.org/wiki/WebFinger) and connect to the right server then...

Which is terrible. Sometimes I remember someone's first name only. Searching Facebook prioritizes people with mutual contacts which we're likely to have and hence I can find the person. If I had to use an email or some arcane Grognard-y identifier, my contacts list on Facebook (or LinkedIn, Twitter, etc.) would be quite a bit smaller.

I've searched people by company they work for, first name spelled right, first name spelled wrongly, and various other qualities. That needs to work with any new federated system. Otherwise the federated system is a step down in social functionality compared to the current systems.

This doesn't mean that the federated system has to support this search feature but rather that there needs to be a search engine that collects data from any public federated server, same as how Google isn't the sole provider of the Internet but Google.com tends to be pretty key in actually using the Internet for many of us. I'm not sure how'd you would implement privacy features like "only friends and friends," though.

Toward federated services

spaetz — Thu, 11 Sep 2014 12:22:46 +0000

The idea is to find people according to their email address or a similar identifier (aka webfinger http://en.wikipedia.org/wiki/WebFinger) and connect to the right server then...

Toward federated services

callegar — Thu, 11 Sep 2014 08:23:18 +0000

In my experience (modest, I must say) with federated systems, the biggest issues is searching people.

One of the biggest selling points of social networks is finding people. People use facebook to find old schoolmates, someone they got in contact during work the year before or the people they have just met at the party. "Standard" social networks give you a single universal pool of people to search (in the billion order of magnitude). "Standard" social networks also make searching people very easy and actually pro-actively suggest people to connect to by looking at connection graphs.

So far, the federated systems that I looked at could only search users within the local basin of the individual server. You will could not use them to find someone who you met the year before while on holiday even if such user was on a node of the federated system. Furthermore no individual server could have a view of the connection graph around you to be able to suggest connections. This is a big obstacle to the growth of large connection graphs and a userbase sufficient to reach a critical mass.

Has this changed recently or since I tested?

Toward federated services

petur — Sun, 07 Sep 2014 18:15:29 +0000

Given that more and more users are installing a NAS at home, and that NAS vendors are pulling the private cloud cart, maybe they are the way to gain some traction...

Just look at the success of whatsapp on mobile; create something that is easy to set up and connect, and users follow. Might need some interesting advantage to pull them over.

Toward federated services

Cyberax — Sun, 07 Sep 2014 11:47:48 +0000

Yes, I know a company that sells proprietary phone system with Jabber inside for signaling. It turns out that SIP is even worse pile of crap than XMPP and even large companies are despairing that it'll ever work.

Toward federated services

TRS-80 — Sun, 07 Sep 2014 11:06:45 +0000

Oddly Cisco is pushing XMPP hard in their recent versions of their PBX (CUCM) - the device (PC/phone) client is even called "Cisco Jabber". I think however that this is more about traditional VoIP protocols like SIP/H.323 being too hard outside of a corporate LAN/WAN.

Toward federated services

Cyberax — Sun, 07 Sep 2014 10:06:30 +0000

> I run my own XMPP server, and I can interact with Google Business users who haven't been automatically "upgraded" to Hangouts. Tons of people and corporations still use XMPP.
Sure, I still run my own ejabberd server. One of my desktop products used XMPP for an in-app chat system.

But none of my contact list uses XMPP.

> Are you kidding me? You're saying proprietary, HTML-based chat clients are better than clients like Adium?
Yes, they are. Try Slack Chat and then tell me if there's anything better.

Let's start from the beginning:
1) XMPP is hard to use and implement (Incremental XML parsing? Really?). Pure HTTP tunneling was added very late in protocol's life, so there were tons of problems with fascist corporate firewalls.

2) XMPP has very poor discovery and search services.

3) No server-side message archiving and searching.

4) Group chat rooms are STILL unusable and unsupported in most of client software.

5) Death by a thousand XEPs - there are about 400 proposals for enhancement. Most of them are either completely unimplemented or implemented exactly once.

>Skype and, to some extent, Facetime dominate the real-time AV space. And while Skype also has IM, have you noticed that it's nowhere near as ubiquitous as Microsoft's or Google's IM usage?
Uhm, I hate to break it to you, but Microsoft's IM has finally died last week. Everybody had been moved to Skype, and I'm actually using it for ALL my IMs now outside of our company (we use Slack internally).

Toward federated services

ghane — Sat, 06 Sep 2014 05:45:43 +0000

> People already maintain so many social media profiles that a federated service which allowed one collection of data to be used in different profiles would provide added value, but it would also just be "one more profile to create", which would lower the bar to trying it.

In my case, that may be "a bad thing". My LinkedIn profile is public, and I interact with people I meet professionally, at work or conferences. My Facebook profile is private, and my "friends" include only those who were me at University in the late 80's.

For all practical purposes, the two "me"s are different people.

Ditto for Google+: My circles are people I know socially today. Having separate profiles allows me to try a service, and experiment, without committing all my profile data.

You probably have multiple email accounts, as well.

Toward federated services

wahern — Fri, 05 Sep 2014 22:39:26 +0000

"no independent support for XMPP really materialized "

I run my own XMPP server, and I can interact with Google Business users who haven't been automatically "upgraded" to Hangouts. Tons of people and corporations still use XMPP.

I was never a fan of XMPP, even before it was standardized. But I've been running my own server Jabber/XMPP server for a long time, because not only is it widely supported by FOSS, it's the only non-proprietary game in town.

Perhaps you meant that neither Microsoft nor Apple adopted XMPP. Well, they're certainly not going to interoperate with Hangouts, either.

"third-party XMPP clients are shit"

Are you kidding me? You're saying proprietary, HTML-based chat clients are better than clients like Adium?

libjingle never took off because people, especially early adopters like developers, aren't particularly interested in voice and video with their IM. Skype and, to some extent, Facetime dominate the real-time AV space. And while Skype also has IM, have you noticed that it's nowhere near as ubiquitous as Microsoft's or Google's IM usage? For whatever reason, AV and IM are like water and oil at the moment. The fact that the tide has turned toward SMS suggests that this isn't going to change anytime soon.

Heck, even Google Voice is being abandoned as a separate product. Neither decision had anything to do with technical deficiencies. It's a product management decision. Google simply decided to double-down on their walled garden, hoping to leverage the success of Android and the ubiquity of GTalk to solidify their lead in the messaging (IM, voice, video) space, partly as a strategy to compete with Facebook. It is, after all, being done under the Google+ umbrella.

I'm not saying Google is evil. I love lots of Google products, especially Android, Chrome, and Chromebook. I just also enjoy my freedom, at least as much freedom as I can manage to defend. I've run my own web and mail servers for nearly 15 years now, and I'd be horrified of any world where I had no choice but to entrust those things to some third-party.

Loosely speaking, it's like the difference between renting and owning a home. Renting makes a lot of sense for many people, but there's more to the equation than money or convenience. For example, not only a sense of privacy and autonomy, but actual privacy and autonomy (even if it's less than it seems).

Toward federated services

josh — Fri, 05 Sep 2014 22:28:43 +0000

See the DebConf 14 keynote "Debian in the Dark Ages of Free Software", by Stefano Zacchiroli, for more thoughts on the service model and how we might move towards a more FOSS-friendly future.

Toward federated services

pizza — Fri, 05 Sep 2014 22:10:13 +0000

> XMPP failures were multiple. Google honestly tried adopting it with Google Chat and even release their voice communications library (libjingle) as OpenSource.

... and they abandoned it almost as soon as they released it, or at least the official google clients didn't actually use libjingle as released.

> Yet no independent support for XMPP really materialized and all the third-party XMPP clients are shit. So Google after 10 years or so simply decided to drop XMPP.

Google dropped XMPP because a federated IM system no longer fit their goals of building a walled garden (ie Google+) to compete with Apple and Facebook, and even before that they didn't actually care about adhering to the standards they themselves helped define. (ie libjingle) It was an entirely political decision; there was no technical basis for what they did.

As for "no independent support" -- by this you mean the other big IM players, that had a vested interest in maintaining their own walled gardens and lock-in? Especially when several of them (most notably facebook) actually used bog-standard XMPP on the client side.

Meanwhile, if by "all third-party clients are shit" you mean that said third-party clients not properly implementing (ie reverse-engineering) the nonstandard quirks of said first-party clients and services... and by non-standard I mean deliberately ignoring stuff that was already well-defined and rolling their own. (push notifications are the main thing that come to mind; Both Google and Facebook rolled their own that happened to map to their backends rather than shimming their backends to deal with the actual standard)

Toward federated services

Cyberax — Fri, 05 Sep 2014 21:47:33 +0000

XMPP failures were multiple. Google honestly tried adopting it with Google Chat and even release their voice communications library (libjingle) as OpenSource.

Yet no independent support for XMPP really materialized and all the third-party XMPP clients are shit. So Google after 10 years or so simply decided to drop XMPP.

Toward federated services

pizza — Fri, 05 Sep 2014 21:44:36 +0000

> XMPP was an RFC, extensible, and federated (as far as I understand), but XML fell out of fashion so it wasn't good anymore.

XMPP's failures weren't technical -- From an F/OSS perspective, XMPP has never been more popular. However, the big commercial players abandoned (or never adopted) it for political reasons.

Solving problems

jhhaller — Fri, 05 Sep 2014 20:16:00 +0000

Most people will not set up services, and if they did, they would be unlikely to keep up with patches, and become security problems. Most people are willing to allow their information to be sold just so they don't have to deal with this, as long as they get a free app to share their cat videos. This is what drives centralization. They don't have very high speed uplinks, so if multiple want to look at their cat videos stored in their home server, quality will be poor.

Given these issues, centralized servers are the only solution (without deploying Google Fiber ubiquitously). But, end users are not willing to pay much, if anything, for privacy, so it's unclear how one pays for the centralized servers, their power, space, net bandwidth, and operations costs. Solving problems is difficult as an approach, because commercial services are likely to quickly implement any problem that an open source project solves.

Toward federated services

vmj — Fri, 05 Sep 2014 18:14:39 +0000

When it comes to protocols, I have a feeling that "FLOSS people" are suffering from NIH. XMPP was an RFC, extensible, and federated (as far as I understand), but XML fell out of fashion so it wasn't good anymore.

Toward federated services

mjthayer — Fri, 05 Sep 2014 14:17:44 +0000

People already maintain so many social media profiles that a federated service which allowed one collection of data to be used in different profiles would provide added value, but it would also just be "one more profile to create", which would lower the bar to trying it.

My feeling is that an RFC with a reference implementation would fly better than just a FLOSS client.