Yeah, so this session is, since we had a free slot coming up, and so we decided, since we have
a lot of interesting jamad people around here, which is so jamad as a successor protocol
to IMAP, and we thought it might be worse having a panel discussion where we maybe share
some experiences, first-hand experiences from implementers, I think most of the guys here
on the stage have been involved with jamad since quite a while, and can give quite some
interesting insights. So yeah, that's the plan for the next 25-30 minutes. I think we
will do some rounds. I think we can also do this a little more interactive if there's questions
from the audience. And yeah, I would suggest we start with the first brief round, and I'll
also sit down for that. I hope everybody can still see it. And I would like everybody to maybe
surely introduce himself, so what's like the project you're working on this jamad, and maybe
very short note about what was your first touch point with jamad, so how did you come across it,
what made you aware of it? Yeah, and maybe we start with. Okay. I made a set project in my
client, and in the past I did a lot of protocols, I'm up, map it from MS Exchange, and similar
protocols, and 2019 here, there was a lightning talk, by one of the bakers from past Mel
Brongunvana. So I immediately saw it will be very easy to implement and to make a good
female client for mobile, and the selling point was jamad push, so I just after the watching
talk went to him just to talk about, and how he will see when we will come, and that's my starting
point to jamad. Okay. Thank you. Benoit. Benoit, I'm working with jamad since 2015, at the time
it was a draft, not even RFC, working for French company, and we wanted to have
new email solution, and completely redesigned the way emails of the works, so both on the
architecture side and also on the protocol side, and what attracted us with jamad was to not have
to redefine HTTP protocols, so that we could connect the webmail directly to the mail server,
using something standard rather than reinventing the wheel was the sending point.
Since then, I was part of the team that contributed the jamad back in to the Apache jam server,
and in 2020, I bootstrapped an effort around twake mail so that's a multi platform
jamad client, so we support iOS and Android and also webmail.
Okay, I'm a model general, the developer of a store work main server, and since I was
starting an mail server from scratch, I said I'm not going to base it on the iMac for the
finish, or the database, or that database schema that would fit iMac because it would be quite
limiting, so I started the other way around, started with a modern protocol jamad, and then
implemented iMac, and the yeah, it was a good choice because of their different things,
like since I would have made it harder to start with iMac and then implement jamad, such as
like emails can be multiple folders, and also blobs can be referenced from different accounts,
and yeah, it was a good experience, it was my opinion easier to implement that iMac,
so it's yeah, that's it, I'm Ben Book, I implemented a lot of the parola mankind that you saw this
morning, I hope you saw the talk, and we implemented iMac last week, so a few things that I
can talk about is how that worked for the implementation, and what I like about iMac, a jamad,
what's better about jamad than iMac, but how did I get in contact with jamad? I was going to the
ITF meetings for the standardization of some auto-config protocols, and there's like only
fastman people there, and two or three others, and it's all about jamad, so that was curious,
and then I saw a lot of interest in jamad in the discussion yesterday, everybody was interested in
jamad, I said, okay, I have to see what is all about, and it was right, it's really cool.
All right, thank you for the first round, so in the second round, I think we had some small
teasers about it already, I would like to hear from you, what do you see on this theoretical level?
So, not necessarily for your own implementation, but when you look back now after you implement
the jamad, what would be maybe, if you would like to have convince a friend doing a similar
tool like why to implement jamad, so what is the main benefit you would see in doing that?
For others, and yeah, in general. Okay, first of all, there was many iMac extensions,
so when you connect to iMac server, you have to take these informations, and to know
some protocols like using constor, other stuff, UIG was, so in jamad, everything of this is mandatory,
so you have faster sync, and you can get all the information with just one call and just
batching to get all the emails, and for example, if the user have many folders, in iMac, you
have to select each folder, take the information, this a lot of network hops, with jamad, you just
make one, and all the folders like mailbox IDs, so you get information from scratch for entire
mailbox of the users, and we just want to call instead of again select all the folders,
you can rethink that information, so it's screaming with fast compared to iMac, especially if you
have a lot of folders and messages, and the other stuff is you do not need to implement iMac
parsers, other stuff, which are there squirks between the different servers, it just JSON,
take the data, so the benefits or to continue with the negatives, or what is missing.
Okay, so i perfectly agree with you, me and the main catch is a jamad is very performant protocol,
I used to be doing a demo, where on one side I would have my jamad application connect to
3G load, and it's like half of a second, you have your 20 last emails in your mailbox,
and I do the same with Samsung email client, and it would load forever, and maybe after 20
second I would get the last like 20 mails, another example is in production, iMac client fetching
all the flags of the messages in the inbox in order to re-synchronize changes,
because not all clients support a quick pressing, and it's something that just don't exist in
in a jamad, and I had to aggressively optimize it with iMac, I'd say that server load is
full time lower on the jamad server for similar loads, so performance, it's also a big big thing.
Yeah, mostly what they've said, also one benefit is that perhaps some developer
implement in jamad gets care by the complexity, but I would argue that it's the way you can
query the database, it has more options, like with the query changes, and you can reference other
queries within the same request, but that minor complexity compensates for it's nothing compared
to the complexity of implementing all the iMac parses, all the dozens of different, sorry,
the iMac parsers and all the iMac extensions, I differentiate the complexity from the server
point of view, where you get like all those methods to implement and that really makes a lot
from the client complexity, and it's actually trivial to write a client with jamad.
Yeah, to write a basic client is super fast, I mean if you just want to display an email
and list what you have in your folder that's super fast, it's a bit more complex when you want to
synchronize your local store with a remote store because you need to run queries, and then also
if you want to optimize the way you reach the server, you can be also chain queries and
a bit more complex, but the base use case which is listing and showing email delete,
deleting, getting follow is super simple, you could write it in a few hours if you want it.
Another benefit I realized when I was traveling at an airport that I was, I wanted to check my
email over iMac and they were blocking anything that was not HTTP, so with the jim of you
will be able to access your email from anywhere where they have firewalls that are only allowing
HTTP. So from a theoretical standpoint, jimad is so much better than iMac, when I saw the iMac
syntax is really complicated, there's some attempts to allow multiple commands to run a
parallel, but then if you actually try to do that, you get in all kinds of race conditions,
so you can actually do this. This is concept of a current folder in iMac, which really
means that I can only do one thing at a time. If I try to do multiple things and I get race conditions,
I get the data from the phone folder, so if I want to operate with multiple folders, I have
to create multiple connections, and then if I do that, then Google blocks me in a second,
if I open all the folders, so it's really difficult, and then the iMac service, since
notifications to me, without me asking for it, and I need to process them in, it doesn't end.
And jimad has really things done right in my opinion. It's clean, it's straightforward,
and you can really see there's somebody behind it who A has a lot of experience, they've already
implemented this, they have already built a client, they've thought of everything that you need
for a client because it's all in there, and it happened a number of times to me that when
I implemented this and I think, okay, so how do I do that? I need to ask the people and I just
read on the specs, and I was written right there, this is how you do this and this. So even
details like push notifications, like if you want to run a mail client on a mobile phone,
you don't want to keep open the TCP connection because it drains the battery, and iOS kills you
after a second. So I really need to push notifications, but I cannot tell the iMac server to please
call a web hub in order to, for me, to wake up. So how do I do that? And I'm with the question
was there, and they're right there, in the specification, put a map, there is two different ways
to trigger a push notification, one phone mobile one for desktop, they're thought of everything.
And this one little complexity is, they're trying really, really hard to avoid
server-round tips, they're trying really hard that you can do everything in a single command,
to get all the data, whatever you want in a single command, because this is written for a web
client in mind, so that adds a little bit complexity that it can chain commands and all that,
but it can be really useful, it can make things more efficient, because I can do everything in my
in one command, and I combine them how I want, this is very modulized, I have a little complexity
but it's really good, so it's really well thought of protocol.
One other is about security, I think all of the iMac client that I see use basic authentication
with jame up, because it's based on HTTP, you can actually use single sign-on,
that's quite easy to add single sign-on in your suit and be more secure.
Well, sorry question, I forgot one thing synchronization, there is not really this
feature in iMac that I can synchronize things to my local mail pool,
it is there, for example, AWS, it is an active thing, but not an iMac, so I can't even watch
multiple folders, if I want to use, if I want to put things in nicely in folders, like I do
both my file system, I put things nicely in folders, so if I want to do that in email, I don't
want to constantly manually move things, so I want to use filters, I want to use service
filters because I want them to work in all my clients, but if I use service side filters,
now the email client doesn't know anymore that the new email arrived, because it arrived in one of
the subfolders, and in iMac I cannot watch all the folders, I have to do hacks like opening
multiple connections with idle, I can watch only one mailbox, and that's just notify extension
which apparently nobody implements, so by default I'm implement enabled, okay, good, well then
thank you, but not all servers do that, so I have to deal with that somehow in jmeb, it's just part
of the protocol, I just watch the whole thing and whenever any email anywhere comes in,
okay, so thanks, next I would like to go a little bit higher level, so I mean it's,
jmeb is still, I mean in terms of, especially in compared to this, so if we email it's quite a
young standard still, right, and especially also I think maybe most most of all of you probably
not you implemented in parallel still also with iMac, because there's a lot of tools and everything
around, so what I would like to know from you is your perspective a little bit on the jmeb ecosystem,
so I mean it's, it's, it's jmeb at some moment like, you're, yeah, but what is your perspective
how it is moving, yeah, so is it ready for primetime, let's say, right, so also maybe related to
that what is your testing, interoperability testing set up, so what is your impression about also
other tools, which are not here in the round implementing jmeb, I mean it's, it's a choice somehow,
and so on, yeah, okay, I think for initial synchronization and rest synchronization,
all the three servers, cyrus, sour, patch james are ready, but there's a little
quicks that need to test with each server, for example, when you query the server, you need to
test with each server, the filters, because some servers doesn't support some features,
and this is not in the standard, you have to find it by yourself, so initially, past mail as
first mover, they have very rich filters, and I have some filters that doesn't work with
the other server, so you need to figure out the common denominator, the other stuff, is that push
is still not there, this was the selling point in the beginning, yeah, actually the patch james and
stowers supported it, but the bakers from past mail with cyrus, you do not offer it for third
part coins, and this one that is missing also is missing, you don't need to set and get in cyrus,
also is missing query change for patch james, in my opinion it's not needed for the jmeb protocol,
because it's enhancement for a really cheap webcoins, and this is how they
the past mail implement coins, but for example, for tenderboard kind or canine such
email coins that have only in the exist, this is not needed, so it's make a lot of
probably more difficult implement the server, and it's here for webcoin, but I'm not sure,
because I do not implement webcoins, and the stuff is moving very slowly because of the iHF,
I'm waiting for some standards since 2019, and still not there, push, and contacts,
yeah, so I'll try to be quick, for me jameb is ready, it's very shine for vertical integrated
solution, like fast mail, twack mail, possibly also people at at mail, where you own at the same
time for front end of the back end, and the reason for that big black spots in interoperability
is the lack of specification on authentication for email, which I mean, like the choice is
okay, then we default basic off, but then it's not better than iMAP, and so people turn it off,
it creates loads of problem with interoperating and connecting to new system, and for me that's
the other big problem with jameb is for a wide adoption, not just in the stack of a single vendor,
it's we actually lack a good big reference client, like let's say, from the bird,
or parola, yeah, hopefully we have one now, that would convince FAA and over email provider,
or to also provide jameb, and they won't do that, one side would not do that until the other one
do it, sometimes looks like a deadlock, okay, regarding the available tools, I'm not sure
about other programming languages, but for Rust, the one for jameb, there's a jameb crate
that implements the entire jameb core, jameb mail, also the jameb web sockets,
so I mean the API needs to be polished a bit, but it's fully functional, and I don't know
on the jameb.io, there is a list of support, sorry, not supported, a list of libraries,
for different languages, but I don't do not know the state in other places, but also if you're
implementing something, also if your use case is quite simple, you don't even need a library,
you can just send a JSON request that complies with the specification, and that's it,
yeah, I would agree with that, you don't actually, as a client, you don't need any license,
because the protocol is so straightforward, you can just write it straight out, I would probably
guess that the client gets my library is more in my way than it's helping me, it was really,
really nice to implement jameb, so just for comparison, I needed like six months to implement
iMab, despite a fantastic library, thank you, Andre, because the concepts are so difficult,
and jameb is just straightforward, it took me literally three days to implement it, and the whole
client, not thinking yet, but all of them operations, moving males, lagging, moving folders,
and Amy folders, everything in three days, so it gives you, it's really nice, what's wrong with the
ecosystem, if you have a vertical integration like you are the holster and you provide the client,
it's fine, just use stalwart, use parola as client, everything is good, but what's missing
is we need somebody to implement it on the server side, a very common iMab client who's in the room
and not listening, a very common email server, and I would like Google to implement it, I would
like Microsoft Office 365 to implement it, and I would like to have got to implement it and roll it
out that would be fantastic, and then I would love Apple male to implement it as well,
that's a little push for the providers, that would be my wish for the ecosystem, and then we
would move forward, but the protocol itself is ready, you can use it right now, it's working well.
Thank you, so we are in the wishing face already here, so yeah, I think we had or around a little bit,
and we are slowly moving also into the end of the session, so I would like also probably to open
up a little bit if there is input or questions from the audience, and I see oh yeah, okay, so first on the
it's a bottom right, it's behind you, all right, okay, and understand that the question
to the servers, like if there are metrics, compared to the server load, iMab clients versus
general clients, right, so who wants to, sorry, yeah, yeah, actual empirical data, yeah,
I can, so actually I do end up to have two very identical clients in terms of size
and email usage in terms of volume, but one of them uses massively iMab clients, and the other one
uses only the web mail that we provide that is jamab based, so that's the metric that I did use
factor free of all area, we did do also study on network usage, comparing our application on mobile
with one or two iMab application, I don't remember exactly the numbers of those tests, but it was
significantly lower in terms of bandwidth, and absolutely dramatic in terms of wrong trip,
did that answer a question?
I thought we'd push, yeah, personally, I don't have any, I heard measure, compared
both protocols, but I just wanted to say that there are different ways to do that comparison,
because you could keep sending multiple jamab requests each time you do something or you can keep
open a web socket connection, or a mix of those two, which is sending requests and then
keep an open an event stream for the data. I know so there is some of this new standard
called jamab for blood management, that also goes to reduce the bandwidth, so there
is somewhere that could be measured simply by looking at the logs and comparing two clients
accessing the same data and adding up, or if you have open telemetry, adding up the size,
parameters of the raw requests, and you get an exact measure of what's going on.
But yeah, there's a lot of stuff to measure, like with what's socket with the jamab for
blood extension and so on. So, I think there was another question.
In drops, you mean, like the binary, yeah, it's a mean in comparison, sorry, or
which, beyond the event, so okay, I just repeat the question for the camera, so the question is,
while it also has jamab males, there's now a couple of other things like jamab for
blobs, jamab for calendars contact, so is there any, yeah, I can point at the, um,
well, I have implemented the in addition to the jamab core jamab male, also the jamab for
blood management, which is not web-dive, it's just a quick way to manage the blobs in the server
that could be emails or whatever else. They also jamab for sieve, which is like a, it's a replacement
for the managed sieve protocol, and then there's also, I think, and forgetting, wow, jamab for
but then there is a new, what, the, as you mentioned, the jamab for calendars, for tasks,
and contacts, and there's a new one coming for a file management, like to use your server as a
file storage, but I don't have, I have not started working on those, but yeah, they look promising
and more efficient, I web-dive and card-out, yeah. Any final note from some of you, as a wife,
very, very short one, yeah, okay. Okay, if you implement a jamab for male with the same
engine in theory, you can sync the calendars and the contacts, just apply different saving
metals to emails and contacts and others, so synchronization, initial synchronization,
risk synchronization is the same whole of that. All right, so thank you very much, my
panelists here, and fortunately, especially for the short notice, you know, readiness to hold
this panel, unfortunately, I don't have presents prepared, like usually you do from panelists,
but I think the audience will give you a warm applause, thank you very much.