Re:Why kernel development still uses email
by dredmorbius on Monday October 03, 2016 @07:17AM
(#12626516)
The directory issue ties in with several of the other problems of email, and how you want to address them.
If we're assuming pervasive use of mobile devices, with no fixed static IP addresses, and quite possibly dynamic IPs even for stationary devices, several of the avenues to establishing reputation, identity, and routing get difficult.
If the idea is to offer a very large number, rather than a small number, of messaging hubs (equivalent to, though offering more services than, an email server), then issues of reputation, configuration, and administration come into play. You want something that's simple, bulletproof (not in the spam-friendly sense), robust, and useful.
Many erstwhile email replacements are premised on a single global directory. I don't think this can work, nor is it on the whole desireable, though it's certainly simpler to get started.
For point-to-point messaging, especially if we're including realtime protocols (chat and voice/video, not just text/files), you need a system in which either scheduled contacts can be made, or in which at least certain trusted/whitelisted parties can reach a given device, regardless of location, within seconds, or at the outside, a few minutes, so long as both parties are online.
Avoiding central peering and routing structures should be part of the system, for privacy and resilience reasons.
Addressing a few of the other issues I mentioned above, including standards for comms and the like, should also be supportable.
If we're assuming pervasive use of mobile devices, with no fixed static IP addresses, and quite possibly dynamic IPs even for stationary devices, several of the avenues to establishing reputation, identity, and routing get difficult.
If the idea is to offer a very large number, rather than a small number, of messaging hubs (equivalent to, though offering more services than, an email server), then issues of reputation, configuration, and administration come into play. You want something that's simple, bulletproof (not in the spam-friendly sense), robust, and useful.
Many erstwhile email replacements are premised on a single global directory. I don't think this can work, nor is it on the whole desireable, though it's certainly simpler to get started.
For point-to-point messaging, especially if we're including realtime protocols (chat and voice/video, not just text/files), you need a system in which either scheduled contacts can be made, or in which at least certain trusted/whitelisted parties can reach a given device, regardless of location, within seconds, or at the outside, a few minutes, so long as both parties are online.
Avoiding central peering and routing structures should be part of the system, for privacy and resilience reasons.
Addressing a few of the other issues I mentioned above, including standards for comms and the like, should also be supportable.