Live data from Hacker News

Slack is Down

status.slack.com

41–48 of 48 posts

Re: Slack is Down

#41
post #33
post #26

Earlier quoted context omitted.

The great e-mail collapse occurred in the late 1990s and early 2000s when spam made it prohibitively difficult for most users to actually run federated e-mail endpoints. At this point it's an amazing pain to the point that very few attempt it. The rest is moot. That's the problem with federated protocols. Without someone who owns the system and who has the resources and central authority to police it, if it becomes p…

Alternatively if other/future federated protocols are developed with spam and abuse avoidance in mind, then perhaps implementation of any associated tech stacks could be developed that would be easier for the lay person to stand up/rollout. I'm not saying protocol devs should by default be able to tell the future...but if they go in with abuse-avoidance AND ease of rollout in mind, then that would go a long way for f…

Strong spam/abuse prevention, useful and accessible for most people, decentralized. Pick two.

Re: Slack is Down

#42
>The status.slack.com was also overloaded during this time and it may have been inaccessible.

This is starting to become a common theme...

Re: Slack is Down

#43
post #11

It's harder (but not impossible) to have complete service lossage like this in a federated protocol. That's why you didn't hear about the great email collapse of 2006.

I wonder where the sweet spot is between a centralized service like Slack, and extremely decentralized scenarios where people just try to cope with a multitude of one-to-one channels?

Federation is a given for this hypothetical sweet spot of course, but how do you find the spot? Are there any HN readers who can point me to research in this area?

Re: Slack is Down

#44
post #11

It's harder (but not impossible) to have complete service lossage like this in a federated protocol. That's why you didn't hear about the great email collapse of 2006.

I wonder where the sweet spot is between a centralized service like Slack, and extremely decentralized scenarios where people just try to cope with a multitude of one-to-one channels? Federation is a given for this hypothetical sweet spot of course, but how do you find the spot? Are there any HN readers who can point me to research in this area?

Federation works just fine - the problem is getting "non-techies" to care enough to join in, discoverability, and ease of joining. So they almost all suffer from lack of a social network and are used by only a niche community.

People will use what most of their friends use. If their friends and people they want to follow all use Twitter, why would they use GNUSocial? Answer is they won't.

Re: Slack is Down

#45

Earlier quoted context omitted.

I don't disagree with you, but in what way do you think Discord will "disrupt" Slack with regards to collaboration?

Discord's a compelling alternative, but it's just another flavour of same. If you want distributed you need something more like IRC or at least federated XMPP.

I don't think making it distributed solves the productivity problem, though.

Re: Slack is Down

#46
post #12

I don't see that type of unprofessional behavior among the users I collaborate with. I guess that's the drawback to working with Millennials. Lazy and time-wasting and always think they are new or funny.

Please keep pointless generation wars off HN.

We detached this subthread from https://news.ycombinator.com/item?id=13812246 and marked it off-topic.

Re: Slack is Down

#48
post #11

It's harder (but not impossible) to have complete service lossage like this in a federated protocol. That's why you didn't hear about the great email collapse of 2006.

I wonder where the sweet spot is between a centralized service like Slack, and extremely decentralized scenarios where people just try to cope with a multitude of one-to-one channels? Federation is a given for this hypothetical sweet spot of course, but how do you find the spot? Are there any HN readers who can point me to research in this area?

djb half-proposed IM2000 as a replacement for SMTP and POP and IMAP.

Briefly: you send a message from your user agent (mail program) to your own mail server. Your mail server sends a notification to all the destination mail servers, a notification basically consisting of the headers.

The destination mail server lets the recipient know that the notification has arrived, possibly doing filtering and sorting and prioritization and stuff.

The recipient fetches the mail body from the originating mail server, and then does whatever.

The big change here is that the notifications are store-and-forward but the mail itself is not. The originating mail server needs to be up and functional in order to get a message body delivered.

Spammers are severely impeded: the message body can't be sent unless they have a reliable, traceable machine up when people get around to reading mail. Botnets won't work. Yet anybody who can run a reliable server can run their own mail server.

Mailing lists only send the full body to people who request it. Unsubscribe is actually worthwhile for any legitimate company to implement. Mailing list servers can easily implement archives by just keeping mail available.

And finally, the holy grail of Outlook users is actually implementable: you can cancel an email after you sent it and have that actually work, as long as people haven't pulled the body down yet.

Post reply on HN