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…
Slack is Down
41–48 of 48 posts
Re: Slack is Down
#42This is starting to become a common theme...
Re: Slack is Down
#43It'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.
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
#44It'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?
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
#45Earlier 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.
Re: Slack is Down
#46I 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.
We detached this subthread from https://news.ycombinator.com/item?id=13812246 and marked it off-topic.
Re: Slack is Down
#47It'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.
Re: Slack is Down
#48It'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?
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.