Re: [Endymail] Restart Endymail to discuss the Mathematical Mesh?

[Mark Rousell <[e-mail]>]

On 10/04/2019 18:53, Phillip Hallam-Baker wrote:
>
> That is exactly my strategy in the short term. I have an SMTP proxy
> but it applies a much older approach.
>
> After that, Outlook and TBird.
>
> It is quite possible that Microsoft Windows Mail would be the easiest
> though.

Seems like a good plan.

Surprises me about Windows Mail, though. I've not looked at Windows Mail
but I would never have thought it was designed to be open to extension.

>  I totally agree. For some of the messages sent, 64KB is enough. But
> for an SMTP replacement, the scheme has to be send everything as a
> control message and detachments unless the message is short enough to
> fit in the control message
>
> The reason to allow content in the message at all is that the
> overwhelming number of messages are really small, a few lines at most.
> So unless there is a really long stream of included messages in the
> thread, we can avoid the need for a detachment.. 
>
> The reason for picking 64KB is that the Ethernet MTU will get up to
> the IP max packet size at some point but it is really unlikely we will
> increase IP packet size. Processing a 64KB message as 8 9001 byte
> Jumbo frames is entirely practical.
>
> I suspect that while we would set 64KB as the MUST ACCEPT size, most
> UDP clients would likely send a message as a detachment if it was
> going to hit the 9001 MTU. It doesn't make much difference on a TCP
> transport of course..

Ah I see, that makes sense, thanks for this further explanation.

>
> Total agreement modulo a few small details when we get to managing
> huge detachments.
>
> If I wanted to send a video to this list, I couldn't. Too big. But I
> want to be able to send files of 100GB without having to switch
> applications like I do today. But when we deal with really large
> chunks of data, well, the recipient might not want them and certainly
> not on their Apple Watch, Android cufflinks etc.
>
> So If I send an email that is 300KB to you and I am in your contacts
> directory, your Mesh Service would perform access control on the
> inbound message and decide something like
>
> * Its from PHB, its authentic
> * PHB in contacts accept the message
> * Detachment is less than 1MB, PHB is a friend, account is not short
> of space, prefetch it and stage.
> If the detachment was larger, handling would likely be different.
> Instead of staging it, the clients might pull it directly. For 1TB
> files we would probably want the transfer to be direct. 
>

That all makes sense.

> The key thing here is establishing some sort of expectation that you
> deliver the data in a certain length of time most of the time.
>
> The situation we have today with SMTP is that most email senders have
> to hire an email deliverability specialist or use one of less than a
> hundred MSPs or their email won't get delivered because it is
> considered to be spam. I would rather have a published expectation
> than have it left to random policies at random sites..

I do note that you started this thread by suggesting (if I understood
correctly) that the protocol would initially be promoted for corporate
internal email-style use and so my concerns about potentially limited
bandwidth in the world at large would likely not apply in that scenario.
Nevertheless, it seems to me that the standard needs to be got right
from the beginning for both internal and broad external usage scenarios,
otherwise it risks not being able to catch on and grow outside of a niche.

(As an aside: It seems to me that for corporate scenarios your new
protocol will effectively compete against the combination of
Exchange/O365/Outlook/Sharepoint. In particular in my opinion, O365 is a
specially powerful tool for ecosystem lock in for Microsoft).

In general I can agree with documenting
reasonable/recommended/non-normative values as a kind of statement of
ideals but if you specify too much bandwidth as being a hard requirement
then I feel certain that it will kill broad uptake of a very innovative
new protocol like this one.

In a protocol that is (eventually, as I understand it) intended to
connect together heterogeneous nodes (heterogeneous in terms of
ownership, bandwidth and quality of connectivity) then I think it is
virtually impossible for the designer of the protocol to realistically
specify delivery time expectations. Surely the protocol (in order to (a)
work in the real world and (b) to be attractive to a wide range of
users) must work as well as possible over a wide range of connection
type and speeds (which means, in very common scenarios, considerably
less than 10Mb/s).

Despite my concerns, it seems to me that your concept has great
potential. We're in a time of considerable innovation amongst messaging
protocols but almost all of it is (a) within walled, non-standard
gardens, and (b) designed with a focus on instant messaging-style
applications, and so it would be very good indeed to see a new
standard-driven protocol that can provide the traditional benefits of
email in a more modern way (something which walled garden instant
messaging-style protocols and apps fail to do).

I had previously noticed discussion of your Mathematical Mesh drafts and
I've just gone to look at them, as well as mathmesh.com. I had not
realised until just now how expansive a concept you have. I realise now
that it's about far more than just a modernised form of email. It seems
to be very exciting indeed. It's so broad that focussing on a
potentially achievable goal such as email-style usage seems like it
might be a good way to proceed.

-- 
Mark Rousell