> Unlike just about every other thing I have loved, it will be there, and I will not have to think about it much. It is awful nice to have something be that way.

Well said. Email is the universal killer app for perpetuity.

And the lesson here is that it is so because nobody owns it, we all own it. It can't go bankrupt, it can't pivot to be something else, it can't lose all its best features when a new product manager is promoted and wants to make a statement. Things that every proprietary system will do and eventually disappear.

I have all email I've wanted to preserve back into about 1990 and I can read it just the same as back then. I will, guaranteed, be able to continue to access it with no change for as long as I live. No proprietary app will ever come close to matching this longevity.

Because it is an open standard I own my entire pipeline. I can receive, send, filter, script, trigger on content, automate.. there are no limits. It's my data.

I centralize everything to email. RSS goes to email, sites I scrape go to email, signal goes to email. If I can't pipe it to email somehow, I don't really have the time to deal with that kind of special snowflake. Email me.

Email is the unix pipe of communication, infinitely flexible to taste.

Email is async, distributed, offline first, nobody controls the complete platform.

What is needed to fix email is to have structured messages, which can better be automated. Either on the MUA or MDA. But exactly this standardization of message structures is something that won't happen anymore... It's not the '90s anymore

> What is needed to fix email is to have structured messages [...] something that won't happen

You're right in a way that this "won't happen", because Google Wave already tried it, but I think what's really needed is a killer client that supports unstructured email and gets into a position whereby they can add structure (and get adoption thereof).

Take for example Fastmail's JMAP. They started by supporting IMAP, and they'll continue to support it for a long time. But, despite Fastmail not being the biggest provider in the world, we're still seeing adoption of JMAP by others.

I could see the same happening with a really well-made open client. It would have to be "modern" (a GUI that handles & sends HTML mail well), and it would have to have good UX to deal with the awful idiosyncrasies of closed providers (e.g. Gmail's broken IMAP, Google Accounts' non-standard auth measures, etc.). Once those work well, one could create a new Content-Type for structured metadata and start sending it as part of multipart mails: most clients would ignore it at first and render plaintext.

This might be less efficient (bandwidth-wise) than traditional email at first, but could improve on that with adoption.

"Fix"

Fix what again?

One "fix" could be an opt-in key, which you can revoke. A new sender will enter your inbox, and can be more easily identified as spam. You can send an opt-in key, which skips the filters, or at least puts the message in your inbox.

If you notice unwanted emails (maybe from another sender), you'll know: - the sender is misusing the key - if the key had been compromised / sold / stolen, the new sender is a misbehaving party (maybe can't use the key if it's linked to the sender address or domain)

You can then revoke the key, and block the sender. The MTAs can use this information to blacklist abusers.

When the key is revoked, the sender will need to re-request a new one.

The 'solution' here is that the key is now something valuable and linked to their operations, so they won't resell this. It also becomes apparent when keys have been stolen. It would also be possible to add automatic key rotation (key update when sending an email).

I just put these "keys" into the local part of the email address, no additional protocol "fixes" needed. I can make up keys on the fly then add the filter for them later whenever I get home. It is very obvious when a sender has sold or shared an address and I blackhole accordingly (this is actually extremely rare).

hey.com supports exactly what described.

hey.com doesn't support much else of email

Fix the constant desire of everyone to re-invent/move away from & generally denounce email as a platform.

If you think email is perfect as it is, you're living in a bubble and are ignoring the pains of countless people. You may have an email setup that works perfectly for your needs, but if it was easy for everyone to have the same, no-one would be trying to re-invent it.

Oh, and lets be clear:

I do not believe for a minute all this wanting to replace email is about the pain of countless people. There is pain, no doubt. I have some myself.

It is all about massive adoption being equated to massive dollars. That tends to amplify these things.

Right. When a company says "let's fix email with a better solution", it is very clear what they really mean is "we want to lock people into our proprietary channel and profit". What's good for the user long term is not a factor to them.

> I do not believe for a minute all this wanting to replace email is about the pain of countless people. There is pain, no doubt. I have some myself.

To clarify my point: I think people try to replace email because they're frustrated with email and believe it can't meet their needs. Personally, I believe email could meet some of their needs were it improved to alleviate some of their frustrations. And I wish some people would direct their efforts toward improving email rather than trying to replace it.

Then again, maybe I should be taking my own advice.

And I question needs vs wants.

Many people are all about how they want to work. They may or may not be about how others work, working together, or willing to adapt how they work.

And we all have reasons, no worries, no judgement.

That said, I have seen many wants framed as needs. Have done that myself. Have also adapted how I work to see those things evaporate away too.

What is worth what?

Sometimes working differently is lower risk, friction for higher value than attempting to work in a specific way can be.

Cheers!

There is making something new, that reinvention, and there is making better use of what is there now.

What you want is not email.

So make what you want, and if it really does reduce the pain of countless people, it will see broad use, right?

And if it does not?

Send me an email, we can talk about it.

Maybe what you want to do can ride in an email?

Great, do that. And again, if countless people feel better, they can run clients that help them feel better.

> What you want is not email.

What I want is email, with the pains ironed out. I do not want anything fundamentally new. I just want to use what I'm currently using, and have it work as it currently works, minus current frustrations.

These frustrations vary from person-to-person (mine are numerous, some I'd be happy to live with, but others genuinely bother me daily), so fixing enough of them to appease a large portion of email users is no small task, but I think email is a good enough foundation that doing so is worth pursing.

I don't see much value in telling everyone their complaints re: email are invalid and they should accept it as is without improvements.

> So make what you want

That's a fair point, and maybe I should. It would certainly be better than posting aimlessly about it in internet comments. As mentioned above though, it's no small task.

I did not tell you those things. You inferred them.

And that is OK, no worries.

Do make that thing. I will look at it with interest like any new thing.

The wave of emails which are difficult to process automatically, and the fact that you can email anybody (which also is the great thing about it)

There are some standards for invoicing.

Another great application is Civilization over SMTP.

The opt-in key I use is a unique address for each vendor / organization. If their email database is "leaked" or otherwise sold out, I can delete the alias and they are dead to me. This makes email rules much easier for me.

I refuse to believe that most of our "unique" emails addresses and GMail suffixed email addresses are not already being collected and matched across the vast networks of fingerprinting data that companies can purchase.

I'm sure google do this, but I won't use gmail. I have some of my domains on fastmail for family members to use and the rest of them on a VM that I simply run postfix and read emails as text files. My own mail server supports infinite number of aliases and there is no tracking on my own mail server since every email is text and the server discards MDN's. If I need to read html, I pipe the email to a parsemime perl script from 2001.

Fastmail makes some attempt at blocking tracking, not perfect, depends on user preference and default is to allow remote images. [1] Another advantage to this method is that if I get annoyed with Fastmail, I can update DNS and they are out of the picture.

[1] - https://www.fastmail.help/hc/en-us/articles/1500000278102-Bl...

Google Reader made RSS feel just like Gmail (which isn't the same as email in general I will agree, but close enough for many people). It was fast, dense, and easy to scan days and weeks of content in a single sitting. I'm _still_ mad they gave it the axe so Vic Gundotra could juice the numbers on failing Google+.

Well, RSS stands against the entire Google’s business model, so the Reader was doomed from the start. Google later went all in to discredit and eliminate the entire idea of feeds and aggregators, as it was dangerous for its business, which required maximizing users engagement and removing their ability to skip ads.

In the past I’ve felt the opposite of your sentiment.

I’ve found my email to be unwieldy. I’ve felt like I have to apply constant hygiene and maintenance to keep it from becoming useless.

Checking out on an e-commerce site, trying out a new tool, registering a free trial...these are things I guess I do frequently enough that it seems to doom me to sort and sift through noise.

I know the common solutions are a good set of filtering rules or separate emails/aliases. I lean toward the latter and it’a definitely helped but I still find it all a bit of a pain and time sink.

That said, you make a nice case for it and I can definitely identify with some of the ‘zen’ of email you’re describing.

I feel like I’ve tried every email client out there, but is there some solution I haven’t thought of of where I get a friendly GUI but can configure mail filtering in code (i.e something I can keep in git) rather than clicking around?

I’ve toyed with ideas of bundling by sender - or quietly placing new senders into their own ‘message requests’ type bin for me to approve or deny.

Or some kind of intelligence for identifying, for example, a receipt or confirmation email (which I want indexed) vs a promotional email from the same vendor (which I do not).

> I feel like I’ve tried every email client out there, but is there some solution I haven’t thought of of where I get a friendly GUI but can configure mail filtering in code (i.e something I can keep in git) rather than clicking around?

A couple jobs ago, before I gave up on processing all my mail, I had a perl script that grabbed headers from IMAP (with caching, because Exchange is slooooow), and filtered with code (basically a list of pairs of code refs that took a message => what folder to move the message if the code returned something truthy (or maybe the code returned a folder... not sure anymore). This let me do things that are hard in server side filters like moving things only when it's read.

Not opting into marketing spam (or opting out immediately in the website's settings) takes care of 99% of it for me. On a set of ~250 accounts I will maybe receive one marketing e-mail per month (and they quickly get a complaint to their data protection officer to discourage that happening again).

For transactional stuff a set of rules to automatically read+archive stuff that you need to keep (invoices, receipts, order notifications, etc) but don't necessary need to action.

This leaves you with only the relevant stuff in the inbox and makes it much easier to do "inbox zero". I will typically get less than one email a day actually landing in my inbox using this technique.

> Or some kind of intelligence for identifying, for example, a receipt or confirmation email (which I want indexed) vs a promotional email from the same vendor (which I do not).

Yeah, one thing where even statistical filtering sucks. Usually there's not enough confirmation vs promo samples to train a filter and some senders tend to use the same templates for both.

It can only be done manually.

Sieve is a mail filtering language you can look into.

For Unix there are many tools with filtering as this is an old problem Fdm, procmail, maildrop

Unfortunately despite just being text, email has become a monolithic black box for most which limits what you can do with the text.

> quietly placing new senders into their own ‘message requests’ type bin for me to approve or deny.

New email services like Hey.com or Onmail.com are doing this. It looks like this kind of feature is getting some traction.

1. Mark them all as spam. I never accept newsletters so I will consider every newsletter email as spam. They don't last much in my inbox.

2. Try inbox zero and just archive emails aggressively directly from your phone’s notification without even opening email.

My inbox currently has 10 emails that one day I'll get to and the rest of spam and transactional email is just gone from view within the hour or day.

I wish I could have an "important" and a "transactional" email view, but that's not going to happen without a lot of work, so email search still sucks.

> so email search still sucks

Email is a standard set of protocols and wire formats. So it doesn't make sense to say email search sucks.

If your email client doesn't support satisfactory search, switch clients. Which you can do because it's a standard, not a proprietary app.

> it doesn't make sense to say email search sucks.

Yes it does, because in almost every case it sucks :) The only one where it doesn't is where it's all indexed by Google (the bad option) or where you index it all locally (e.g. with mu). The second is a slightly less bad option but not by much.

> Yes it does, because in almost every case it sucks :)

I mean I get it but fundamentally it's not true. Might seem like a nitpick but it's not. If slack search sucks, that's an absolute statement. It is what it is and there's nothing you can do about other than beg a product manager at slack to make it better but they'll likely ignore you.

With email, an open standard, you can just switch clients. Or bypass clients entirely and handle search separately. There are no limits to what you can do.

Well, I use "the bad option" for search when I need to perform a potentially painful one. Just a depot where every thing gets copied.

I find it, potentially forward something and then carry on.

No, it doesn't. :)

I happen to use an email client with better search and tagging than Gmail.

And it would be? :D

Cleaner, faster, ad-free :D

And... more secure, detecting zero-days Gmail won't :D

Care to share?

It sucks because transactional emails still show up next to important emails. What’s a client that separates this without me manually doing so (via filter or whatever)?

Gmail is good at this when splitting the inbox, but after that it’s all forgotten (unless, once again, you add a manual filter to exclude such emails)

The idea of Blackberry's unified list really resonates with me! And I strongly endorse your two tips, they really help.

About your important/transactional split: shameless self plug but I'm working on a project that's all about a unified list, and one part of that is splitting incoming into important and not important. If you check it out, feedback welcome! garrett@[productname].com

https://www.twobird.com/

> USENET is another one, but well out of favor. Fact is, someone could spiff USENET up and it could very easily come back.

Fwiw this does seem to work pretty well:

https://forum.dlang.org/help

> About

> This website is powered by DFeed, an NNTP / mailing list web frontend / forum software, news aggregator and IRC bot. DFeed was written mostly by Vladimir Panteleev. The source code is available under the GNU Affero General Public License on GitHub: https://github.com/CyberShadow/DFeed

> This DFeed instance (forum.dlang.org) is a frontend to the DigitalMars NNTP server and mailing lists. Portions of the web interface (including style and graphics) are Copyright © by Digital Mars.

I've looked at dfeed a couple of times, but it seems just a little bit convoluted to set up - and I wouldn't really want an irc integration.

But the web forum is snappy and the NNTP integration seems like a great idea.

I think sites like Reddit are the modern version of Usenet. The subreddits aren't hierarchical, but I'm not sure that matters.

The clear problem with that is the lack of federation, but I don't think users generally care about that.

> I think sites like Reddit are the modern version of Usenet.

Closed, propiatary, with separate ux/client for every silo? They are not usenet in any meaningful way.

They're more like bbs forums in a world were there was no improvements made, and the internet never happened.

The only thing (most) have, is that for traffic purposes they allow spiders like Google and Bing to enable federated search.

But there are variants like Instagram that allow search, but force login - and things like Facebook groups, that are opaque.

The ux of most forums (including hn) is terrible. HNs one saving grâce is that it's simple (as it should be).

I don't mean to jump on you; I get that things like reddit is a place were all people can exchange messages - but I don't think that makes it modern usenet. Just like mailing lists were/are not usenet.

I say it's the modern version of Usenet because anybody can create a subreddit and as a result a group exists for just about everything you can think of. Compare the process of creating a new subreddit to the process for creating a non-alt newsgroup[1]. In some ways, Reddit is arguably more open than Usenet.

The defining characteristics of Usenet was not the license or client (IMHO the UX of most NNTP clients was pretty terrible for casual users) but the content. There was a group for everything that anybody could access as long as their ISP provided access. If you asked me if there was some place on the internet that had a discussion group for everything I'd probably say Reddit is the closest thing. All you need is a connection to the internet and a browser and you can start reading. Posting requires an account but they are free.

I agree with you that forums, BBS message boards and mailing lists are nothing like Usenet.

[1]: https://www.savetz.com/yic/YIC05FI_26.html

The UX here is excellent!

Threaded discussion is best done simple, and that is what we have.

Hehe, I am a fan of hn, but it's very bare bones compared to something like mutt or (al)pine.

That said, there's a couple of decades of horrible web platforms from nuke/phpbb thorough reddit and Twitter. It's not exactly high price to be "not as stupid" as all the the ones taking pride in their convoluted stupidity...

Bare bones does not mean a poor UX.

What we have here is dead simple, works great, very lean, effective.

All excellent.

We could have more and that may or may not trend toward excellent.

DISCLAIMER: To all chat-app haters, my point is that the user experience of these newfangled services is just much better, o course I'm not taking into acct all the very real concerns stemming rom these apps.

Since your talking about user experience, (not mentioning privacy, security, etc.). How is email better in terms of usability than say Telegram or any other app.

Which keep every chat you've ever had.

You can "Save" chats for yourself for later.

You can have usenet-style conversations in huge mega-groups.

You can follow the latest news from channels just like RSS.

All without needing to keep the data downloaded on your device, and backed up in the cloud.

Basically all those separate services you mention (with separate software required to be downloaded to view them) are rolled into in any one-stop-shop chat app. Oh, and it also has phone and video calls too.

I like Telegram a lot. Has merit in the ways you mention, and it is pretty lean, not too much going on, not pushy either.

None of this replaces email.

A big one is I am not sure I will have every Telegram chat I received a decade or two from now, and I will have all my email.

Another is everyone uses email. Not everyone uses other apps. So far Telegram is entertainment only. That is fine.

Email can act like chat, chat is not email.

I very strongly disagree with better. Different? Yup. More experiences possible? Yup.

But not better. Email is killer. And it is not hard, is time tested, production proven, near ubiquitous.

UX is bang on simple, and I hardly ever think about it.

"Better" needs some reevaluation to be frank. I see a general failure to understand why email is great. That means a claim of better UX may make very little sense.

I agree about email. And the main thing, and what distinguishes it from Telegram, etc., is that it is a protocol, not an app. You can use any client you want, or write your own.

Telegram is one of the few messengers that actually enables you to use any Telegram client available, or write your own[1].

The protocol that is de facto Telegram is called MProto[2], and is publicly available.

§

[1]: https://telegram.org/apps

[2]: https://core.telegram.org/mtproto

§

edit: The main difference between email and Telegram, is that anyone can host email servers, while Telegram manages theirs.

edit2: MProto being widely available to study, one could perhaps reverse-engineer their own server - but that hasn't been a desire to accomplish this from what I can see. Much of the value-proposal of Telegram is their Service as a whole.

Telegram is centralised and siloed, where email isn't. You just can't compare the two.

> You just can't compare the two.

You just did.

I was responding to the claim that Telegram wasn't providing a protocol or ability for developers to author their own clients.

And point taken—I didn’t know about this, so Telegram was not an ideal example. But, as you point out, it still is not quite a decentralized as email, and, as a protocol, does not have email’s universal character. But thanks for the interesting information.

You can back up all Telegram chats including Media, of course this doesn't replace email, but the difference is just a client to parse the data and log it in a message style front end.

Overall, email is killer, I would love to move everything toward emails that I can filter, or as the OP posted, a Unified inbox.

I wonder if there is a patent on it.

> You can back up all Telegram chats including Media, of course this doesn't replace email, but the difference is just a client to parse the data and log it in a message style front end.

While this is true, there's no automatic process and it's limited to the desktop client. Email is much more convenient because of this. I can't "forget" to backup my emails for the past month or year. I know they'll be on my email server until I delete them.

I am not a chat app hater.

I am a workware app hater, unless I use it for specifics, like a meeting. For that case, I love "continue in browser" because I want to do it, and then when I am done, maybe never think about it again.

No states, other features. Just launch, have the meeting, next.

I like Skype still. I use it like I used to use IRC.

None of that is email though. If I want to send complex thoughts, I send an email. Async, robust, easy.

I really like my data in an open format, stored where I want, usable on what I want, when and how I want, and with whatever app I want.

You made it sound good except for the cloud bits. If you toss those out, it sounds like IRC, which I agree is great. However, the local logs I can dig through with `grep` and `less` very quickly are a huge part of what make IRC great for me, and why I've never felt quite as comfortable in newer stuff like XMPP and Matrix (although I do use all three regularly still).

If I have to search from within the program, I find that it's basically never as fast and as powerful as what I want. If the local logs use some sort of database instead of a plain text file, I feel my hands are tied behind my back.

This is more of a client problem than protocol problem, I think, but IRC just still has the best clients by far. I really hope some other things can come closer to matching irssi one of these days. Logging, keyboard shortcuts, scriptability and configuration, not automatically re-ordering my precious channels. So many things are worse than irssi.

Also, before someone says it, I know irssi has XMPP support, but lack of OMEMO made me not bother. Similarly, weechat has a Matrix plugin or two, which was the best Matrix experience I've had in a lot of ways, but it was super buggy and would break or constantly log me out, so I couldn't seem to stick with it.

> All without needing to keep the data downloaded on your device, and backed up in the cloud.

I'd call this a feature of email – I _can_ easily have all the stuff I need downloaded on my device. I can move email around without using a specific provider, back it up to an offline storage just like any other data, and use multiple clients without re-syncing all the emails.

Also it's perfectly possible to have email available over the Internet, only downloading things to your device when needed. Most modern email services work this way – either through webmail and/or using email protocols like IMAP.

(That's not to say that email is perfect. Far from. The content of email is a hot mess – broken HTML implementations, HTML email trying to do ungodly things, plaintext with hard line breaks, plaintext displayed with no line breaks whatsoever, RTF...)

>You can "Save" chats for yourself for later.

Can you, though? With Telegram, perhaps. But "chat" in general does not have this. Depends heavily on the service, in my experience.

Indeed. This varies widely, and the save does too.

Does not compare to email and all the options one has.

> How is email better in terms of usability than say Telegram or any other app.

> Which keep every chat you've ever had.

Telegram only promises to keep your messages for 6 months of inactivity. If you switch to something else, you're going to have to archive the messages yourself.

Sounds like you'll really like DeltaChat: https://news.ycombinator.com/item?id=25893626

>Ok, so what is there really to disrupt? Onboarding a new person into an existing discussion

I must say, that is a non problem in my experience.

Worst case, I talk to them, done, next.

What email clients are using that produce all these rainbows and lollipops?!

I need to get in on that!

Out of interest, what email client(s) do you use?

I want to love email (I do love the platform) but I've just struggled to find a UI that I don't battle with. Especially one/some that work similarly across different devices.

I use outlook and the gmail web interface mostly.

Having used so damn many UX'es, I do not generally struggle. They work how they work. Basics are not hard. I rarely use more than basics anyway.

I quit trying for that perfect fit years ago.

Thing is it will get changed. So why bother?

Much easier to adapt and become quick to grok whatever paradigm, flow is there and get back to whatever else I am thinking about.

I have used Thunderbird and would again in a pinch. Like that one.

I haven't used Outlook, and it was my next port of call. I've used Thunderbird but I've been frustrated by it's "core" handling of mail threading (there's an extension but it doesn't integrate well with any of Thunderbird's other features, largely because it's trying to do things not envisaged by Thunderbird's addons APIs).

> They work how they work. Basics are not hard. I rarely use more than basics anyway.

I would normally agree but I'm using macOS Mail currently and it brings new definition to the word "basics". It's missing some pretty obvious things.

> the gmail web interface

I'm in web interfaces pretty often and I really like Fastmail's: strongly considering switching to use it's web UI everywhere and forgo local clients completely. I've found Gmail's usable but sluggish, which gets painful if you receive a lot of mail.

I agree with gmail now sluggish. At one time, 800ms! Today? Seconds.

I use it for personal and to search my body of pro emails forwarded to an account for that purpose.

Too bad about macOS mail.

I need to look at FastMail.

Outlook, like the rest of the Microsoft Office programs, is craptastic! It will do what you want. You will enjoy doing it less than you want, and it will generally remain worth it to do what you want.

Web only email is killer. I did that for many years.

The big thing with Outlook and exchange is business calendar integration. MS has a good solution. Forward to gmail and I get Android calendar copies for essentially free and low hassle. I do enough sales related work to justify Outlook.

I do not like Microsoft mobile apps much at all. On Android at least.

Edit: I fought with / against Outlook for years.

When I finally said, "fuck it" and used it for business, I found when I do not invest much, I do not risk much and have been happy ever since.

I just don't want to think about it all that much. The contents of those emails are what I want to think about and so that's where my focus is.

I run KDE and KMail integrates nicely.

A while back it had problems with Gmail, but despite Google's best efforts to break compatibility it works pretty well today.

Unified inbox, fast search, highly configurable. It has a couple of rough edges around the UI (it's probably not for grandma), but it's still by far the best desktop mail client I've used.

Oh, and K9 mail for android!

Slack exploded on the scene with a refresh of IRC.

USENET could come back with a proper refresh.

> proper refresh.

If it gets a "refresh" the way slack murdered IRC for work, I hope it never does. While were at it, slack can go straight into a volcano. Any value it adds over IRC is A. marginal and B. not work-relevant (because you can't upload anything containing sensitive data there, bearing in mind what it is...).

How would work related IRC work in practice? Everyone running their own bots so you dont miss messages? You also need a bot for push notifications, as well as one for mirroring. Also a custom solution for file sharing. I know its part of the fun.

However it does not sound suitable for a work environment.

The only value of Slack is receiving messages independent of presence (no need for a bot to keep you online), providing server-backed message history, and providing a UI that allows modern creature comforts like emoji and native images. If those are baked into an IRC client/server combo that achieves broad adoption, we might well see IRC come back as a "poor man's Slack".

No need for chat history bots if you front-end your IRCD with a web interface that has chat history, persistence. [1][2]

[1] - https://github.com/thelounge/thelounge

[2] - https://github.com/convos-chat/convos

We used to have a centralised bouncer that both fixed push notifications as well as transparent history and presence (i.e. automatic away). File sharing has been part of literally every client for so long I don't know what you want me to say about that. It works, it's p2p. What more is there?

$oldjob had that too, and it worked really well for most people - tech and business alike. I like IRC because it makes you focus on what really matters instead of some sort of seamless Giphy or Wikipedia "rich"-content integration. It's sufficiently async to not bother me at all times, and I can interact with it programmatically very, very easily.

Also, due to its rigidly ephemeral nature (ultimately depending on your personal preference of course, but the default for most clients these days - and opposed to something like Teams, which seems to store everything forever), it nudges its users to use a more suitable, more permanent medium to capture information that is to be persisted. It's clearly a different kind of animal than a wiki or an email archive/mailing list, whereas new "alternatives to email"-tools like Slack, Teams and their ilk are anything and everything in-between, which causes "now where the hell did I read that thing about that other thing..."-syndrome for me.

Well, when someone does not respond on IRC, send them an email.

Still nothing?

SMS?

At this point, maybe they are not responding for damn good reasons?

I check my work email once every 4 days on a good week, and my personal email nearly once every 2 months. Email isn't really a good channel for urgently getting in touch for some people.

True. And when discussing generalities, it is a given people with specifics will stand out. I have mine, you have yours.

Personally, I deal with others on whatever terms they tend to present to me.

So, if someone does not respond quickly, fine. Or they want SMS, or whatever, that is fine too.

I figure they have reasons, seek low friction amd give consideration I am given.

https://www.irccloud.com/pricing see "Teams"

Usenet is more similar to a group mailing list, so hopefully they aren't talking about "refreshing" it to be like Slack.

I hate Slack. Unlike IRC, it is too much. And it is thick.

Many do not though, your point is good.

I love email because I rarely have to think about it. Thought is action. Same with IRC.

Like, to be fair: Many people don’t know how lean and thin IRC is, they are just happy that they get flexible channels for group communication.

But those who know, know.

I also feel like I dug in to the original code for Slack and it literally was an IRC client.

Totally.

Wouldn't USENET be Reddit?

Various subreddits, async communication, sharing of stuff. User accounts. Only major difference (and it is a big one) is voting.

I must admit I never realized Slack is IRC. It makes perfect sense.

In my opinion there is no need for voting on usenet. You can reply to anyone or ignore anyone. No global echo chambers, no global moderation beyond removing illegal content on a specific provider or filtering a usenet group on a specific provider. If you had a group of like-minded friends that wanted to ignore specific ways of thinking, then you could all contribute to your own group specific ignore-list. Corporations have no financial incentive to build around usenet for this reason, as they have zero control over the client.

The biggest issue with Usenet was spam. NNTP is an open protocol. It is supported in quite a few email clients. Have you tried Pan?

If the Usenet refresh is anything like slack I certainly won't use it.

Aren't Slack's threaded conversations basically a new take on usenet? It's not distributed, and silo'ed of course.. but it's the same idea if you squint.

> It's not distributed, and silo'ed of course..

But that's the key.

Can I write my own slack client to automate everything just the way I want to, relying only on standard APIs that cannot go away?

Same sort of flow, sort of. Not distributed and siloed are very big differences.

I agree, and I think there’s only one thing email lacks: end-to-end encryption. I’m unsettled by an unknown sysadmin accessing my life’s emails.

Decentralization was the key. There was no central server then. It was all data sync from one server to another on request and it worked well.

Email, as in the protocol, only appears robust because of all the qirks. Essentially you cant build email infrastructure 100% after RFC and expect it to work in the real world.

Is that because of RFC being incomplete or because other people started mangling messages?

second that.

today I'm no longer integrated into the workflow of a "modern dev team" but the last time I was they forced us to communicate on Slack. If I'd have to work in such a distraction-tread-mill I'd be one very unhappy camper. It's not that Slack alone is terrible but how orgs these days expect devs to use it. Some companies I've been at they made their teams announce in the main channel whenever somebody went for a break or when they got back. That's fun with 3 people but god forbid you're working with bigger groups and end up forgetting to enter that you've gone for a dump. I first thought it was only one place that has jumped the shark on common sense, but no, it's every other company since 2016 that thinks it's a great way to communicate.

email or nothing for me. Or pick up the phone (boomer!) or video call me if it's really that important. the 50 additional more ways to hassle me can F right off lol

> If I'd have to work in such a distraction-tread-mill I'd be one very unhappy camper.

Slack is quite the productivity destroyer if you let it.

I turn of all notifications and let it forward any direct mentions to email. Fortunately that works. So if anyone calls on me I'll see it in email.

Aside from that, I only read the slack channels twice a day, morning and evening and close the tab the rest of the day.

If the world is on fire, email me. Otherwise I'll see your slack chat tonight.

Slack can be truly overwhelming within some companies (ask me about it, I can go on for hours about it), but the very idea of ignoring reams of email signatures and no proper threading in email makes me shudder about using it in a work setting. I'd rather take Slack than that.

> USENET is another one, but well out of favor. Fact is, someone could spiff USENET up and it could very easily come back.

Reddit?

Usenet was decentralized.

Usenet didn't fight you if you wanted to scrape all of it. In fact, it encouraged that.

Usenet didn't require crappy "API tokens" in order to automate your interactions with it or bring your own user agent... in fact, you had to bring your own user agent; that was the only way to use it.

The only thing Reddit has in common with Usenet is good support for threaded discussions.

Reddit is not that bad with regards to scraping. You can append `.json` to any URL and it will return a JSON representation of this page: https://www.reddit.com/.json

As for API tokens, that's unfortunately just the current trend of basically every other site with user-generated content. It's unfair to single out Reddit in particular when nearly everyone else does this too.

> As for API tokens, that's unfortunately just the current trend of basically every other site with user-generated content.

Totally hilarious that you posted this on a discussion site whose API doesn't require tokens.

https://github.com/HackerNews/API