Readit NewsEDIT: 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).
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....
Obviously this would probably never get the global reach of a no-fee Facebook, but I would use something like this in a second, many of my friends would too, and I sometimes daydream about what I would need to do to get it off the ground.
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.
The nice thing about flatpak for a phone is that it could in the future offer something like the Android/iOS permissions interface.
So maybe this is not an inherent problem of this technology and will work better in the future.
I strongly oppose these kind of attacks by people hiding their identity. No matter how valid the criticism might be, this goes against all the ethics of Open Source.
Just like the Devuan folks that vigorously attacked systemd and Lennart.
This must not be tolerated.
Yes, I’m very upset.
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.
[1]: http://www.linphone.org/technical-corner/linphone/downloads
This is in stark contrast to, for example, AWS S3. From the FAQ [0]:
> Amazon S3 [is] designed to provide 99.999999999% durability of objects over a given year. This durability level corresponds to an average annual expected loss of 0.000000001% of objects. For example, if you store 10,000,000 objects with Amazon S3, you can on average expect to incur a loss of a single object once every 10,000 years.
> Amazon S3 ... storage classes redundantly store your objects on multiple devices across a minimum of three Availability Zones (AZs) in an Amazon S3 Region before returning SUCCESS.
In AWS parlance, an AZ is a physical data center, and they're built far enough apart so a fire, flood or tornado will not affect all of them.
There's a reason S3 (and similar) cost so much more than "hard drive attached to a server" storage. If you don't need the durability than of course it is overpriced -- but on the other hand, if you try to provide that level of durability yourself you'll quickly see it's a bargain.
[0] https://aws.amazon.com/s3/faqs/#Durability_.26_Data_Protecti...
In fact, I don't know where AWS nor Hetzner stores the 'disk' of the VPS or even the backups. And while those are undoubtedly essential attributes for enterprise-level services, I think especially for side projects the usability of the service is quite relevant.
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).
Google+ was dead in the water from day one. You don’t beat Facebook at social by building a slightly different product with some cool ideas like Circles. Going for feature parity was a mistake. Instead they should have tried to identify a niche where Facebook was failing (say, intimate private sharing, or the antithesis of the narcissist fest) and build up a loyal core of rabidly passionate users, then slowly expanded from there. Kind of like how Facebook started out as a platform for elite universities, then high schools, then workplaces, then the world.
This approach would have been hard to sell internally at Google given the pressure to release a “Facebook killer.” But people always forget that the way to build a platform is to start by nailing a niche use case and then expanding. Even the Apple App Store only came to dominate because it was based on a hit product, the original iPhone.
Anyway, kudos to Google for finally admitting defeat. Hopefully management learned something and they hire some people who understand humans so that their brilliant engineering capacity doesn’t get wasted again.
Paired with the missing backward compatibility with email those two are the most important aspects of why Wave failed IMHO.
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