A farewell to email

Posted Oct 17, 2018 1:08 UTC (Wed) by ebiederm (subscriber, #35028)
In reply to: A farewell to email by Cyberax
Parent article: A farewell to email

Having everything centralized on one server with no easy way to replicate it is a long term maintenance concern. The less data that needs to be stored the easier it is to replicate. So while people isolated to low bandwidth links may decreasing being efficient and distributed is still a good thing to be.

I recently had a trip and I really enjoyed the fact that I could quickly access all of my mail archives with public-inbox running on my laptop. So like being able to clone a git code repo locally, having a local repo of discussions has real value.

A farewell to email

Posted Oct 17, 2018 1:31 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

Discourse has an API that can be used for replication, so perhaps it makes sense to standardize it.

A farewell to email

Posted Oct 17, 2018 2:21 UTC (Wed) by wahern (subscriber, #37304) [Link] (2 responses)

It doesn't make economic sense for any dominate service provider to standardize--because competition, because move-fast-and-break-things, etc. Standardization, if its to happen at all, has to happen *before* there's a dominant market participant, and there need to be forces that necessitate continued, substantial compliance.

HTTP is so low-level as to be irrelevant in terms of leveling the playing field and permitting novel and useful composition of services and data. SMTP is really the last remaining protocol of its kind in terms of federated, structured content sharing.[1] If this generation *isses it way, then they'll deserve the future they get.

[1] SMTP is far from ideal and has plenty of problems, but that says more about the horrendous state of affairs than it does about its utility.

A farewell to email

Posted Oct 17, 2018 3:13 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

There’s no dominant player in the public collaborative software.

A farewell to email

Posted Oct 17, 2018 4:47 UTC (Wed) by mtaht (subscriber, #11087) [Link]

Email's death started with reverse dns being required and ipv4 space running low. In the 90s, your ISP still asked "do you need a /29 or /27 with that?"

Then, complexity, spam,

Then bufferbloat made async transfers bothersome.

Then the cloud.

Then the lack of working ipv6.

Now the lack of static ipv6 along the edge.

I thought with ipv6, everybody would get a /48 with their house. I was so wrong....

I still have a perfectly usable ipv4/29 here that I dare not use for fear of bloating the link...

A farewell to email

Posted Oct 17, 2018 8:01 UTC (Wed) by mjthayer (guest, #39183) [Link] (1 responses)

> Having everything centralized on one server with no easy way to replicate it is a long term maintenance concern. The less data that needs to be stored the easier it is to replicate. So while people isolated to low bandwidth links may decreasing being efficient and distributed is still a good thing to be.

> I recently had a trip and I really enjoyed the fact that I could quickly access all of my mail archives with public-inbox running on my laptop. So like being able to clone a git code repo locally, having a local repo of discussions has real value.

I vaguely imagine a protocol for storing discussions and other things as e.g. a git repository, and sets of tools for interacting with them (but a simple text editor being enough in a pinch). People who preferred the web way could use web tools on a server and never know it was git underneath, perhaps one could also also interact with it using an e-mail based server in a way which felt like mailing lists. As something git-based it would be easy to replicate and store locally.

I am sure that if it makes sense it will already exist somewhere. That said, what must have features of modern code hosting environments would definitely not fit into that model?

A farewell to email

Posted Oct 17, 2018 17:05 UTC (Wed) by me@jasonclinton.com (subscriber, #52701) [Link]

Yes, it does exist. This is SSB https://github.com/ssbc/secure-scuttlebutt but it has a long way to go in terms of managing the kinds of things that forums can currently do. There are a number of frontends for SSB now but it's still very hard to use and most of the protocol features for moderation tools mentioned in the article are absent.