Comment by JepZ | Hacker News Reader

Comment by JepZ | Hacker News Reader

Parent Full thread

Well, while I dream the same dream, it feels awkward asking my family and friends to pay 5€ per year so that we can share the cost of running our XMPP-Server. Currently, I pay all the bills and manage the server myself (so no cost/effort for them), and they still keep using WhatsApp with most of their contacts.

I don't know what the root of that evil is, but there are undoubtedly multiple factors involved. First of all, most people have WhatsApp already.

Secondly, it is effortless to use. With federated systems, you always have to choose a provider. Once you have overcome that hurdle, the privacy-sensitive people like us do not want to share their address book with the server so finding your people is a manual setup for everyone (another hurdle).

Last but not least, the client landscape of XMPP is still far from perfect. If you want to use end-to-end encryption (e.g., OMEMO) there are finally some clients which work with each other (Android: Conversations, iOS: ChatSecure, Desktop: Gajim), but configuring all that stuff (Server + Clients), is not as easy as pushing a button. Other features like video calls are still very fragmented and rarely work if different clients are involved.

I think it would take ten dedicated developers about a year to fix all those problems (if they would agree on common goals and focus on those) and even after that, we would still have to sell the product.

This is all summed up in one word: friction.

What the big platforms have done is eliminate friction at all the critical parts, to make it easy for users to onboard, easy to share, easy to grow within the platform, and of course hard to leave.

I've been thinking about a low cost but not free platform too. If it ever happens, it will have to be AT LEAST as frictionless and enticing as the existing platforms. The table stakes are very high. Since cost in of itself is a source of friction, that means the rest of the platform needs to be even MORE frictionless.

I think this is exactly right. Users expect a really nice, contemporary-feeling UX. And for something that cost money it would have to be above and beyond.

That said, the fact is that the mainstream alternatives are handicapped by their own success and are afraid to change anything of their core features. Starting a new platform would be an opportunity to revisit many of the original design choices, and perhaps one could do surprising new things at that point.

I think the co-operative model is interesting economically as well because as far as I can tell, there are at least some cases where it does work out to be economically stable on a reasonably long term basis (decades anyway), and I presume it changes things a lot, organizationally, if the main goal isn't just "lowest common denominator software for the sake of maximal mass adoption and growth."

The angle we can exploit is to find all the places where UX is degraded by advertisement, and attack them. With increased competition and shareholder expectation, Facebook will have no choice but maximize the value they can extract out of each user. Right now they are doing a fairly good job at keeping things minimally intrusive, but I think that boundary is going to shift with time.

I'm curious, can anyone estimate the developer hours it would take to clone WhatsApp's UX, features and functionality? Would it be doable since it's already developed and they solved the hard problems for syncing messages across timezones and it may be feasible to follow their tech stack as a blueprint/starting point?

Facebook and Instagram had no trouble stealing the concept of 'stories' from Snapchat and Facebook also copied their augmented face masks.

Did WhatsApp use a lot of open source stuff under the covers that we could leverage in building our own secure person to person/ group chat platform?

WhatsApp was originally XMPP, and may still be some hacked up version of it.

There are many (open-source) solutions for building your own secure messaging system, XMPP and others.

I'm happily running (I should also disclose: developing) my own server and talking with friends and family who use e.g. Conversations as an alternative to WhatsApp.

WhatsApp's popularity originally came from how it ran on many WAP phone systems, not just iOS and Android but also all the feature phones. What they did looked crazy from the outside but they effectively re-implemented SMS at a lower cost, for nearly all phones. That was not a trivial amount of effort, but it produced a lower financial friction than competition.

A disrupter would have to have even less friction but would be competing against a product that already has a significant network effect and a very generous backing by Facebook. I'm speculating that FB will eventually nudge WhatsApp users to Messenger, or find a way to gradually merge the services to the point where they are identical, especially w.r.t. advertisement.

In that respect, it was brilliant of FB to acquire WhatsApp: not just for the users, but to make it hard for any newcommer to disrupt things (hard to compete againsts free and frictionless).

Or enough differentiation and/or other enticing reasons to join the network.

The table stakes are another reason why this endeavour won't happen as a small effort.

What about a facebook clone with regular ads?

The only thing I could possibly see working for what you're envisioning is building it on top of the Neuralink if a version 1.0 ever comes out.

Craigslist is an interesting comparison for friction/UX. Still looks like it's from the early 00's, but has stayed just usable enough on all contemporary devices that it never went out of style.

The only friction to the end-user is the same email/password request every other service makes, but you want to use CL because it's the de facto place for listing your apartment or whatever.

I'm not sure if its true of every area, but in the cities where I've used craigslist it does not require a username or password to create or reply to a listing. It will confirm an email address when generating the listing. The link in the email contains the token allowing modification and deletion of the posting.

I don't know if I would build something from scratch that was based on XMPP or even on the idea of messaging. I keep thinking that the Twitter/FB/chat models of socializing is a very limited form of online sociability and that we could do better.

I think it would be better to build something that was sufficiently compelling and had enough new features/UX that people would want to use it all on its own, as something better than the existing ad-supported options, and then we would enable federated options as an alternative form of access. But I think the primary UX has to be "log in to web app" or "install mobile clients," not "fiddle with XMPP settings" (because that is too fiddly, like you're saying, and you have to meet people where they are).

This being said — it's excellent that you run your own server and managed to get some of your social network to actually use it!

I think the parent referred to fiddling with OMEMO fingerprints, that a) is automated in "good clients" (Conversations) b) can't be easy and paranoid-secure at the same time.

I also run XMPP server for friends and family and actually all of them are very happy with it. With Conversations this entire experience looks like any other modern messenger.

Network effects are of course a problem in any decentralized environments but looking at how quickly companies drop their solutions (Google?) or abuse the data you give them (Facebook?) I don't see any other reasonable option. Today Signal is nice and kind, tomorrow they are bought by Facebook and start "fiddling" with the app...

> I also run XMPP server for friends and family and actually all of them are very happy with it. With Conversations this entire experience looks like any other modern messenger.

Does Conversations do something extra to support sending messages to people who are offline? If so, how well does it work? Because that's what I find to be the biggest gripe people have (myself included) with XMPP.

The messages for offline users are stored on their servers and delivered when they connect. Interesting that you list this as a problem because this worked for ages (given server support for offline messages).

Conversations can display a "tick" on the sender's side so you know that a message has been delivered to the user (not just stored on a server).

I guess it works well as I've never heard about a lost message.

You can check the server with compliance tester: https://compliance.conversations.im

>I think it would take ten dedicated developers ... if they would agree on common goals and focus on those

Well, then it will never happen :D

Do you have a recommended guide for setting an XMPP server that supports end-to-end encryption?

Sadly I don't. I have mine running since a while, and some things might not be state-of-the-art anymore.

The server doesn't really have to support end-to-end encryption as that is part of the clients (in fact, there are some server-side extensions which have to be present, but those are mostly enabled by default).

Afaik, the default ejabberd configuration is very close to what you need, and there is just one part that you have to remove to enable OMEMO [1]. I don't understand why but recently the ejabberd devs introduced that part to their default configuration which makes it harder to use end-to-end encryption.

Nevertheless, if you are very interested in a detailed guide, I could write one as I am thinking about setting up a secondary server as a testing environment.

[1]: https://github.com/processone/ejabberd/blob/master/ejabberd....

Why would you want E2E if you run the server, and so can be trusted?

If you run a federated server, not all contacts might use the same server. With end-to-end encryption that doesn't really matter.

EDIT: Moreover, trust is not binary. So while your family might trust you, maybe your dad doesn't want you to be able to read everything he writes your mom or so (you get the idea).

Here is some discussion of how to easily use Let's Encrypt certificates with the prosody XMPP server. That gets you C2S and S2S encryption which is more or less mandatory these days. End to end (OMEMO) doesn't need the server to do anything special so there isn't any setup to do past just getting the server running.

* https://prosody.im/doc/letsencrypt

Reply on news.ycombinator.com