Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Slack is down

status.slack.com

Post reply on HN
Print view View original

751–760 of 840 posts

Re: Slack is down

#751

Post by u801e »

networkimprov wrote: post #689
MattJ100 wrote: post #665

Earlier quoted context omitted.

The problem is that XMPP and Matrix are protocols, not products. Element (the primary Matrix software) definitely has Slack and Discord in its sights. I don't think there are any serious "self-hosted Slack-like" contenders that are XMPP-based right now. You can piece components together (yay, standards!) and I did exactly this for the IETF's XMPP deployment recently. But it's far from being a cohesive easy-to-deploy…

It's largely overlooked that the success of Slack & MS Teams is partly due to the cybercrime portal that email has become. IOW, you don't get phished in your org's Slack chats. To prevent phishing, any chat service will suffice; an open protocol isn't necessary, as you don't intend to engage with ppl outside your org. The essential problem IMO is how to replace SMTP. No one has proposed and implemented an alternative…

> To prevent phishing, any chat service will suffice; an open protocol isn't necessary, as you don't intend to engage with ppl outside your org.

The same could be accomplished with email if you only allow connections to the SMTP and IMAP server from within the corporate network. That is, nothing external can connect to those servers, which is fine if it's only used for internal communication.

Re: Slack is down

#752

Post by u801e »

layer8 wrote: post #744
networkimprov wrote: post #689

Earlier quoted context omitted.

It's largely overlooked that the success of Slack & MS Teams is partly due to the cybercrime portal that email has become. IOW, you don't get phished in your org's Slack chats. To prevent phishing, any chat service will suffice; an open protocol isn't necessary, as you don't intend to engage with ppl outside your org. The essential problem IMO is how to replace SMTP. No one has proposed and implemented an alternative…

Email is not a chat system, and chat systems are unsuitable for asynchronous long-form threadful discussions. There is some overlap, but combined they form a spectrum of communication modes so wide that it can‘t be covered by a single UI.

I would argue that email is not suitable for asynchronous long-form threadful discussions. The limitation that email has is that if you're not part of that conversation from the beginning, you'll have to piece it together from previous quoted material.

One email like protocol that properly handles this is NNTP.

Re: Slack is down

#753

Post by BlueTemplar »

bovermyer wrote: post #610
sytse wrote: post #258

At GitLab our fallback from Slack is Zoom https://about.gitlab.com/handbook/communication/#emergency-c... I'm posting this because I found a lot of people don't know that Zoom includes a complete chat client that includes channels. And #HugOps to the engineers at Slack working on this. I appreciate that they posted a periodic update even when there was no news to report: "There are no changes to report as of yet. We'…

As someone who has to use Zoom Chat to interact with a client on a daily basis, please, do not recommend Zoom Chat to anyone except as an example of how not to do chat software. -- Though, I do agree wholeheartedly with your sentiment that the Slack team needs all the positive vibes they can get right now.

Yeah, this is baffling. I'd rather run turn of the century ICQ than Zoom chat...

Re: Slack is down

#754

Post by networkimprov »

dathinab wrote: post #736
networkimprov wrote: post #689

Earlier quoted context omitted.

It's largely overlooked that the success of Slack & MS Teams is partly due to the cybercrime portal that email has become. IOW, you don't get phished in your org's Slack chats. To prevent phishing, any chat service will suffice; an open protocol isn't necessary, as you don't intend to engage with ppl outside your org. The essential problem IMO is how to replace SMTP. No one has proposed and implemented an alternative…

No, EMail has fundamentally bad UX for a lot of use case slack and similar are used for. > problem IMO is how to replace SMTP. Sadly SMTP is probably one of the parts of Mail which have aged best . Enforcing the usage of some (currently by design optional) features wrt. authentication and similar at the cost of backwards compatibility and you have all you need from the delivery protocol. BUT: - IMAP and similar is mu…

By "replace SMTP" I mean the whole email protocol stack, not only SMTP. I'm not proposing to replace it for all situations overnight; of course SMTP etc will be used for decades.

TMTP also covers most IMAP/POP use cases. And it allows short, plain-text messages (see Ping) to make first contact with others -- necessary when that server has less restrictive membership requirements.

Authenticity is a double-edged sword. For certain confidential content, you want the recipient to know that it originated with the sender, but you don't want anyone else to know that in the event the content is leaked or stolen.

I believe the extinction of email for person-to-person & app-to-person correspondence is a foregone conclusion, due principally to phishing. The question is what should we do now, and the answer is clearly not chatrooms (which are of course useful in certain circumstances).

Re: Slack is down

#755

Post by baudehlo »

networkimprov wrote: post #689
MattJ100 wrote: post #665

Earlier quoted context omitted.

The problem is that XMPP and Matrix are protocols, not products. Element (the primary Matrix software) definitely has Slack and Discord in its sights. I don't think there are any serious "self-hosted Slack-like" contenders that are XMPP-based right now. You can piece components together (yay, standards!) and I did exactly this for the IETF's XMPP deployment recently. But it's far from being a cohesive easy-to-deploy…

It's largely overlooked that the success of Slack & MS Teams is partly due to the cybercrime portal that email has become. IOW, you don't get phished in your org's Slack chats. To prevent phishing, any chat service will suffice; an open protocol isn't necessary, as you don't intend to engage with ppl outside your org. The essential problem IMO is how to replace SMTP. No one has proposed and implemented an alternative…

I used to work in anti spam and we would call these FUSSPs.

https://www.rhyolite.com/anti-spam/you-might-be.html

Re: Slack is down

#756

Post by networkimprov »

u801e wrote: post #752
layer8 wrote: post #744

Earlier quoted context omitted.

Email is not a chat system, and chat systems are unsuitable for asynchronous long-form threadful discussions. There is some overlap, but combined they form a spectrum of communication modes so wide that it can‘t be covered by a single UI.

I would argue that email is not suitable for asynchronous long-form threadful discussions. The limitation that email has is that if you're not part of that conversation from the beginning, you'll have to piece it together from previous quoted material. One email like protocol that properly handles this is NNTP.

I agree with both of you, and TMTP supports adding people to a thread after it starts (see PostNotify).

Re: Slack is down

#757

Post by radlad »

gmmeyer wrote: post #708
radlad wrote: post #690

Earlier quoted context omitted.

IME, Slack is far more likely to lose my message than iMessage. I believe that's part of the point being made above.

I've never had slack lose a message when it's up

That's kind of the definition of a service being up. :) I've experienced numerous "soft" outages which result in messages not sending and getting lost - and even more double sends, sometimes very distant from where the message was originally sent.

ITT: Anecdotes

Re: Slack is down

#758

Post by pcl »

throwaway201103 wrote: post #710
exhaze wrote: post #136

Earlier quoted context omitted.

I haven't worked at Slack, so I can't speak with high confidence. A traffic spike is a possible reason, but I'm willing to bet that it's not the reason: > Doubt anyone releasing big changes Monday morning. This is definitely an engineering best practice, and by best practice, I mean something that Uber's, I mean Slack's SRE team strongly pushed for, and got politely overruled on. After a code freeze is lifted, it's q…

Interesting, I've never worked anywhere where engineers decide when to release changes. That's a product decision, and there is a process of review and approval at both the code level and the functional/end-user-experience level that has to happen first. Did you mean that literally? E.g. is it common at Uber that engineers can release changes to production on their own?

At Cisco (Webex team), the engineers decide when to release code, and most features are enabled by configs or feature flags independently of the deploys.

The engineering team is responsible for the mess caused by a bad deploy, so it's appropriate that those engineers should also choose the timing.

Our team typically deploys between 10am and 4ish, local time, since that's when we're at our desks and ready to click through the approvals and monitor the changes as they go through our pipelines.

The feature enablement happens through an EFT / beta process, and the final timing of GA enablement is a PM decision. But features are widely used by customers ahead of that time, as part of the rollout process.

Our team usually rolls out non-feature changes to services via dynamic configuration switches, so that we can get new bits in place, and then enable new behavior without a redeploy. This also enables us to roll back the dynamic config quickly if something unexpected happens.

(We generally don't do this for net new functionality; there's lower risk in adding a new REST endpoint etc. than in changing an existing query's behavior or implementation.)

Re: Slack is down

#759

Post by alfiedotwtf »

exhaze wrote: post #89

When I was at Uber, we noticed that most incidents are directly caused by human actions that modify the state of the system. Therefore, a large "backlog" of human actions that modify the system state have a much higher chance of causing an incident. My bet is that this incident is caused by a big release after a post-holiday "code freeze".

This is why Change Management is the main tenant of principles like ITIL

Re: Slack is down

#760

Post by layer8 »

u801e wrote: post #752
layer8 wrote: post #744

Earlier quoted context omitted.

Email is not a chat system, and chat systems are unsuitable for asynchronous long-form threadful discussions. There is some overlap, but combined they form a spectrum of communication modes so wide that it can‘t be covered by a single UI.

I would argue that email is not suitable for asynchronous long-form threadful discussions. The limitation that email has is that if you're not part of that conversation from the beginning, you'll have to piece it together from previous quoted material. One email like protocol that properly handles this is NNTP.

True regarding the late-comer aspect, although it is less of an issue when using mailing lists with an archive. In the past, when lacking an archive I also just asked another participant to send me the earlier discussion in mbox format, which was easily accomplished with the unix MUAs of the time.

Regarding the actual modes of discussion I was thinking of though, usenet and email are mostly the same.

Post reply on HN