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.
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'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).
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.
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.
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.
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.
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).
Why is it problematic when people hide their identity? I mean, if the criticism is valid, what does it matter who said it?
I think hiding the identity is not the real problem here. To me, it looks more problematic, that the critique is not very constructive, one-sided and loaded with imputations.
> I think hiding the identity is not the real problem here. To me, it looks more problematic, that the critique is not very constructive, one-sided and loaded with imputations.
And I think there is a strong correlation between those two things.
It definitely makes it impossible to enter in a productive discussion about how flatpak could work better. The way it stands now, this rant is useless, aimed to be destructive and simply unacceptable. IMHO.
> And I think there is a strong correlation between those two things.
There might be a correlation between those in this case.
But just because it - perhaps (I haven't actually read the "article") - applies in this case, that's a far cry from being a general rule.
Think of it in terms of - for example - a muslim speaking up against oppression in their home country, or a Tibetan speaking up against China. Should they not be allowed to do so anonymously?
It is possible in most cases to judge merit on content/argument alone.
It's very difficult to imply or deduce someones motive, whether you know who they are or not. In most cases, you would be mistaken.
I find it helpful to remind myself that most people do what they do out of love, even if their actions are/seem utterly insane, or are/seem destructive.
I think flatpak is probably the right choice for a phone. Assuming equal developer attention on both flatpak and deb repos, there's nothing inherently worse about flatpak.
The nice thing about flatpak for a phone is that it could in the future offer something like the Android/iOS permissions interface.
Yeah, maybe I am a bit too negative about the format itself. My problem with the Flatpak only approach was that it was kinda hard to get it to run at all and it didn't work particularly well, so I ended up with putting some work into it while ending up with an unsolved problem (stable Linux desktop SIP client).
So maybe this is not an inherent problem of this technology and will work better in the future.
Please don't. There is nothing wrong with interactive tools, but by default, they should not be. So instead of making non-interactive session possible via flags, the default should be to be non-interactive. If there is an option to start an interactive session, everything is fine.
Otherwise, you would never know when your script could run into some kind of interactive session (and therefore break; possibly after an update).
My interpretation was that the prompt is for required information. In the example graphic, "run demo" really does require that "stage" be specified. This is considered more user-friendly than simply crashing. If you don't want to see the prompt, provide that information as a flag or in a config file or whatever.
> This is considered more user-friendly than simply crashing
(I'm going to assume the passive voice means "the article considers this more user-friendly" rather than some sort of commonly accepted fact).
I disagree with this strongly and agree with the GP -- I would much rather have the command exit with a message saying that a required parameter is missing. For example, if I have a script using a command and the command becomes interactive, then my script is dead; but if it simply exits then my script has failed at a repeatable point.
You could say that I should pass a "--noninteractive" flag into everything just in case, but sometimes these things aren't supported. I would much rather have an application support a "--interactive" flag to support those who want to be able to interact with the tool.
I think the two sides of this are unlikely to be able to convince each other. At least the article presents a reasonable-ish middle ground of always offering help as to the way to circumvent the interaction at the point where interaction is required.
So you want the script to [EDIT:] exit with an error code rather than hanging around waiting for input? That seems possible, with some sort of generous (e.g. 5 minutes) exit timer on the prompt. Would that satisfy your concerns? If not, what else is needed here?
ps. the verb "considered" is a good sign that this is an opinion, and would be even in a more "active" sentence.
First of all I think "crash" is the wrong word here. Unix tools commonly exit gracefully with an error code when the argument requirements are not met. Often with an informative error message.
A five minute pause sounds ridiculous to me, absolutely not user friendly from either end. It's jus unpredictable and time wasting. If you absolutely must, you can use 'isatty' to check whether stdin/stdout/stderr are connected to a terminal and act accordingly.
There is some merit to having consistent and predictable behavior regardless of where and by whom the tool is invoked, though.
This is how Powershell treats mandatory arguments. Provide args via flag/position or be prompted for input. You can always break out with Ctrl+C if you'd rather modify the command.
The one thing missing from the example is a little more contextual help. Not only should it prompt you for the stage, it should say “use --stage [development|staging|production] on the command line to skip this prompt” or some such. (Could be as terse as the prompt reading “please specify --stage”.)
Like for the confirmation example? I agree. It would help clear this up. The points people are raising here with prompting are definitely not issues, they're just misunderstanding my point.
Well, this is not a cronjob that failed, it's just waiting for input.
Let's say that I did test the cronjob but that it starts "failing" after an update to the tool. My fault, I know, but at least I get mail when it fails while I won't if it's just waiting for input.
This scenario would only happen if a flag became required. Prompting or not it would still be an issue. (And it wouldn't prompt as this is a non-tty environment)
Yes, but in one case the issue would result in a mail because the cron job failed, and in the other case the issue would just cause the the process to hang indefinitely without notice
I think detecting whether stdin is a TTY is a huge antipattern. Most of the time, it works, but now and then, you either want to run an interactive session in a situation where stdin appears not to be a TTY, or a batch session in a situation where it appears to be. Plus, it means there's twice as much surface area to learn.
> you either want to run an interactive session in a situation where stdin appears not to be a TTY
Um... why? That is literally the situation for which the pseudotty device was created.
There is a spectrum between "interactive" and "scripted" utilities, and the command line interfaces we're talking about sit balanced on the interface. There's no way to make everyone happy, more or less by definition. So I think "huge antipattern" is maybe spinning a bit too hard.
You get false positives sometimes (where it claims to not be a tty but is going to the screen), but because the fall back is just reduced functionality it never causes any issues. We make hundreds of checks like this for tty in the CLI
I still miss Wave... In my opinion, Googles biggest failure was the missing real-world federation. They promised us, that there will be a server to run on your own hardware and yet it took them years to release anything that was usable. Even years after the open source release the software was quite unstable.
Paired with the missing backward compatibility with email those two are the most important aspects of why Wave failed IMHO.
Personally, visual clutter and poor performance were two major factors why Wave didn't work for me. Visually they were cramming too much stuff on the page, with loads of avatars / icons for participants and the like - IMO unnecessary information to have on the landing page. And performance wise it was just not good enough, maybe if they made it an optimized native app instead of a webapp.
At least they could incorporate the tech they developed and used for Wave in other products, notably Docs and G+.
> [...] no language barrier because so many people here speak English.
I wonder how you came up with that one. From my experience (I am German myself), Germans are not good at English. It is not so bad within the large cities but in the countryside, good luck. Just take any of the Scandinavian countries and you will find that they have a higher percentage of people speaking English.
Living in Germany without learning German is a hard challenge. However, speaking German with an American accent is sometimes considered cool ;-)
The "no language barrier" point was only for Berlin. I know that in the countryside almost nobody speaks English, but inside the city you will be able to get everything you need. As far as I know most of the government agency employees are required to speak at least basic English.
Windows 10 Licensing terms § 6 says "The software periodically checks for system and app updates, and downloads and installs them for you. You may obtain updates only from Microsoft or authorized sources, and Microsoft may need to update your system to provide you with those updates. By accepting this agreement, you agree to receive these types of automatic updates without any additional notice."
If you want to use Windows, just do it. But if you had to experience what it feels like when Windows thinks it is time for an automatic-forced-reboot-update which takes 4 hours the day you have to submit a thesis, then you might know why I am not so fond of Microsoft products anymore...
By the way, later that month I learned that I had been lucky as some people ended up being stuck within the update.
I am sorry, but that is no BS, just pure facts. Granted the PC is not very powerful (CPU: AMD E-350), but the story is true. When the update started, I thought 'Shit that thing didn't just reboot itself. Okay here we are, that will take one hour max.'. But in fact, it took about 4 hours.
https://news.ycombinator.com/item?id=14855347
Now it looks like I was wrong and we got just about 33% and the curve seems to flatten already:
https://www.google.com/intl/en/ipv6/statistics.html#20