Email is basically the worst-common-denominator for communications and data transfer. It's going to keep existing forever because it's the one thing that basically everybody has and everything can support, but from the perspective of security, usability, and especially structured data transfer it's terrible.
I can't think of a reason I'd want a decentralized system to use email as the message bus. I do want the message bus to be backed by something standardized, but there's plenty of standard ways to transmit data that aren't SMTP. If some users want to interact with the system via email, supporting email as a notification / response mechanism is totally viable without using that as the backplane for the service itself.
I blaming tech overload at the moment, but I'm trying to remember some of the "supporting email as a notification / response mechanism" that I have seen / used in the past that took those emails and put them into a threaded responses kind of graphical hierarchy.
I kind of get this with searches in thunderbird email client, but I can't quite remember if phpbb or vbulletin does that. I am guessing slack, rocket chat and similar have some kind of bots or bouncers kind of things that could re-insert replies and group by threads.
Maybe it's just having a new view layer added into into some of the systems and giving the option to get notified and reply by email, as well as other methods that others may prefer.
I think we need to remind people posting in forums and other softwares that others may be getting plaintext-viewable-by-the-world emails of the posts and replies - that's a security gap I think many would not consider if they do not use those methods, so a reminder would be good.
Of course adding an option to get pgp encypted emails only and blocking plaintext for example might be a step up and in the better direction for adaptability and moving towards future better.
Still can't pinpoint where I have seen similar things used in the past or what it was called at the moment.
Erm, maybe I am misunderstanding what you are saying, but threading is a built-in feature of the email RFCs. Mutt can do it perfectly, and has been doing it forever. If at all, it's a feature that was lost with some "modern" clients in the name of usability or something idiotic like that.
> from the perspective of security, usability, and especially structured data transfer it's terrible.
Email is basically free, works well for up to 5 megabytes of data, and data security isn't much of an issue for open source work. The post suggests quite a few tools that improve the Git-email workflow, and I think some do prefer those to certain web-hosted Git interfaces.
> there's plenty of standard ways to transmit data that aren't SMTP
Are they free, federated, and as reliable as email? It may be inferior in some technical ways, but it's still a rational choice for small non-private data transfers, such as a Git patch or any another text.
> data security isn't much of an issue for open source work
Is that the case? It seems like you may be focusing on specifically the privacy aspect of "security". I'd say that email is equally bad at ensuring integrity and authenticity, which are crucial aspects of security for open source work that's consumed by others. We can attempt to backfill those gaps in email using GPG and other tools, but we're trying to put a bandaid over a mortal wound in a lot of ways. Recent vulns have highlighted what has been known for a while: trying to ensure the authenticity and integrity of a protocol as broad as email with as much client-side complexity is a losing battle.
But then, that applies ten-fold for anything that uses HTTP, or god forbid, browsers. Just look at how even the matrix spec manages to be incompatible with the HTTP spec.
I can't think of a reason I'd want a decentralized system to use email as the message bus. I do want the message bus to be backed by something standardized, but there's plenty of standard ways to transmit data that aren't SMTP. If some users want to interact with the system via email, supporting email as a notification / response mechanism is totally viable without using that as the backplane for the service itself.