ralphm

Besides what MattJ100 wrote above, by itself this is also not true. You can tell Android to not optimize Conversations and allow it to run in the background. It will work just fine with a (usually idle) TCP connection. But for the typical user, having to instruct them to do this is cumbersome, and integrating with Firebase is easier. It does come with its own concerns w.r.t. privacy, both for the payload as well as metadata exchanged.

I expect it is 27W to support 9V 3V, not because of tolerances per se. (Source https://www.sparkfun.com/products/23583)

Because wages are non-Gaussian, standard deviation doesn't mean anything in this context.

Hence the suggestion for PagerDuty. It handles all this, because responders set their notification methods (phone, SMS, e-mail, and app) in their profiles, so that when in trouble nobody has to ask those questions and just add a person as a responder to the incident.

Why every time? Isn't this a user config that overrides whatever default there is?

Except that Luna in Slavic and Latin just share the same ancestor in PIE.

As far as I know, Facebook Messenger's XMPP support was only exposed to clients (c2s), not to other XMPP servers (s2s). Microsoft's Lync (now known as Skype for Business) supported XMPP federation until 2019. WhatsApp's client protocol was originally based on XMPP. I'm reasonably sure that both AIM and Yahoo had XMPP server-to-server support ready around 2008, but can offer no proof.

In this Dutch article (https://www.rtlnieuws.nl/nieuws/buitenland/artikel/5191916/d...) it is suggested that they didn't use two-step verification because it would be cumbersome for his campaign team.

Whether or not this is true, Twitter definitely needs to start having multi-user functionality. Beyond TweetDeck Teams.

If services are indeed doing, or moving to, end-to-end encrypted media, there's nothing the server can do here.

Yup, and the old bridge will keep working locally, still has an open API, and there was an upgrade program when v2 was introduced, with a 33% discount. Four or so years ago.

Google Search used to have such a feature. I used it to blacklist w3schools. Of course, the feature is no longer there.

How so? That page says Marseille Soap is made from vegetable oils, whereas the recipe in the article uses animal fat.

Earlier:

https://news.ycombinator.com/item?id=16964112

https://news.ycombinator.com/item?id=16802079

Blendle has stopped pay-per-article, moving to subscriptions entirely.

The original article (https://www.washingtonpost.com/nation/2019/07/26/it-snuck-up...) includes links to some interesting background information, including the event leveling a huge forest area. And it correctly uses square km/miles instead of "square acres".

Yeah, I considered this a feature. As mentioned elsewhere in these comments, we should have a way to limit the scope of corporate certs.

I hope they pin on the key, not the certificate. For a mobile app I worked on, I had it pin the public key on the leaf certificate and indeed it would fail to connect in this scenario.

For mobile apps, though, you can bootstrap HPKP with a key built into the app. I worked on an app doing this, and it would certainly fail to connect in this scenario.

I think the point here is that if you use semantic elements, you don't need to use classes to differentiate.

For U2F there's nothing to be in sync: each key is added individually, and you don't have to add all of them at once. I.e. if you register the key on your keychain at work, you could later add the backup key in your home vault.

For storing TOTP keys on your YubiKeys, those must be the same, so you probably have to add them at the same time, or take a picture of the QR-code before you complete the registration.

The desktop version of Yubico Authenticator (yubioath-desktop) allows for storing TOTPs on YubiKeys in Linux and OS X, too.

I like having TOTPs stored this way, as you can use them with any device, including over NFC on Android, just by installing the Authenticator app.

Is this not a valid approach then? The issues of ossification and strict allowance for just known protocols appear to be big enough to cause things like SCTP to not have a viable, widespread use in their future.

You misunderstood what's happening here. A rogue server can request the client to read any file on the client's file system, and the client will comply without validation that the client actually requested this.

Back in the early 90s, I learned the vi movement keys through hunt(6) from the BSD Games collection. Can't find a good link for the package, but here is the man page: https://www.unix.com/man-page/bsd/6/hunt/

RCS is a standard on which development started in 2008 and was built upon the core of another standard called IMS, which started development in 1999. The same year the jabber.org project was announced.

The battery argument is just misinformed. The real reason Google dropped XMPP was not a technical one. Yes, Google claimed it was not "cloud ready" at that GoogleIO. The same one where they announced Google Cloud Messaging, based on, wait for it, XMPP.

A great keynote by Jacob Kaplan-Moss at PyCon 2015 along similar lines: https://www.youtube.com/watch?v=hIJdFxYlEKE

Let me first turn this around. I actually personally tried to interact with the Slack team on how they implemented their XMPP gateway, early on. I pointed out how a relatively small missing protocol feature (server-side group chat bookmarking) was severely impacting the usability of the gateway, as it caused caused you to have to explicitly join the group chat room representing a Slack channel on every client (re)connect. In fact they violated protocol in case a client requested the list of bookmarks, causing clients to hang while connecting. It took them a year to start responding, and the problem was not fixed.

Additionally I had pointed that their statements on XMPP security were factually wrong. No useful response or changes were made.

That all said, I really like a bunch of things about Slack and have repeatedly pointed out in discussions in the XMPP community that there is a lot to be learned from Slack in terms of features (and how they work technically), UI consistency, and usability. As JC points out, this is surprisingly hard to achieve in open source projects. Even harder to pull off for a very diverse community around a set of protocols, rather than a single software product.

There are also things in Slack that I think would be a lot better if they were modelled after recent protocol proposals in XMPP. For example we are working on something called MIX, an evolution on group chat, based on Publish-Subscribe. This allows for orthogonal streams of information bound to a channel, besides just chat and presence, like merge request notifications, Twitter mentions, etc. that could be displayed in a side-bar or ticker, instead of (annoyingly) interleaved with chat messages.

I would have welcomed Slack interacting with the community, but they didn't.

MailGun has been spun out of Rackspace almost a year ago.

Article is from 2016. Previous discussion: https://news.ycombinator.com/item?id=11570606