WEBVTT 00:00.000 --> 00:12.680 Yeah, so this session is, since we had a free slot coming up, and so we decided, since we have 00:12.680 --> 00:18.800 a lot of interesting jamad people around here, which is so jamad as a successor protocol 00:18.800 --> 00:24.000 to IMAP, and we thought it might be worse having a panel discussion where we maybe share 00:24.000 --> 00:28.240 some experiences, first-hand experiences from implementers, I think most of the guys here 00:28.240 --> 00:32.320 on the stage have been involved with jamad since quite a while, and can give quite some 00:32.320 --> 00:39.040 interesting insights. So yeah, that's the plan for the next 25-30 minutes. I think we 00:39.040 --> 00:43.200 will do some rounds. I think we can also do this a little more interactive if there's questions 00:43.200 --> 00:50.080 from the audience. And yeah, I would suggest we start with the first brief round, and I'll 00:50.080 --> 00:56.080 also sit down for that. I hope everybody can still see it. And I would like everybody to maybe 00:56.080 --> 01:02.400 surely introduce himself, so what's like the project you're working on this jamad, and maybe 01:02.400 --> 01:06.800 very short note about what was your first touch point with jamad, so how did you come across it, 01:06.800 --> 01:18.480 what made you aware of it? Yeah, and maybe we start with. Okay. I made a set project in my 01:18.480 --> 01:27.600 client, and in the past I did a lot of protocols, I'm up, map it from MS Exchange, and similar 01:27.600 --> 01:38.480 protocols, and 2019 here, there was a lightning talk, by one of the bakers from past Mel 01:38.480 --> 01:46.640 Brongunvana. So I immediately saw it will be very easy to implement and to make a good 01:46.720 --> 01:55.280 female client for mobile, and the selling point was jamad push, so I just after the watching 01:55.280 --> 02:05.280 talk went to him just to talk about, and how he will see when we will come, and that's my starting 02:05.280 --> 02:15.920 point to jamad. Okay. Thank you. Benoit. Benoit, I'm working with jamad since 2015, at the time 02:15.920 --> 02:24.720 it was a draft, not even RFC, working for French company, and we wanted to have 02:27.600 --> 02:34.800 new email solution, and completely redesigned the way emails of the works, so both on the 02:34.800 --> 02:45.440 architecture side and also on the protocol side, and what attracted us with jamad was to not have 02:45.440 --> 02:54.960 to redefine HTTP protocols, so that we could connect the webmail directly to the mail server, 02:55.600 --> 03:01.040 using something standard rather than reinventing the wheel was the sending point. 03:02.080 --> 03:10.160 Since then, I was part of the team that contributed the jamad back in to the Apache jam server, 03:10.720 --> 03:19.280 and in 2020, I bootstrapped an effort around twake mail so that's a multi platform 03:20.480 --> 03:26.080 jamad client, so we support iOS and Android and also webmail. 03:31.760 --> 03:38.000 Okay, I'm a model general, the developer of a store work main server, and since I was 03:38.640 --> 03:43.120 starting an mail server from scratch, I said I'm not going to base it on the iMac for the 03:43.120 --> 03:51.520 finish, or the database, or that database schema that would fit iMac because it would be quite 03:51.520 --> 03:58.800 limiting, so I started the other way around, started with a modern protocol jamad, and then 03:58.880 --> 04:08.240 implemented iMac, and the yeah, it was a good choice because of their different things, 04:08.240 --> 04:16.080 like since I would have made it harder to start with iMac and then implement jamad, such as 04:16.080 --> 04:24.400 like emails can be multiple folders, and also blobs can be referenced from different accounts, 04:25.120 --> 04:34.880 and yeah, it was a good experience, it was my opinion easier to implement that iMac, 04:34.880 --> 04:47.360 so it's yeah, that's it, I'm Ben Book, I implemented a lot of the parola mankind that you saw this 04:47.440 --> 04:56.000 morning, I hope you saw the talk, and we implemented iMac last week, so a few things that I 04:56.000 --> 05:01.280 can talk about is how that worked for the implementation, and what I like about iMac, a jamad, 05:01.280 --> 05:09.040 what's better about jamad than iMac, but how did I get in contact with jamad? I was going to the 05:09.040 --> 05:14.480 ITF meetings for the standardization of some auto-config protocols, and there's like only 05:14.480 --> 05:19.280 fastman people there, and two or three others, and it's all about jamad, so that was curious, 05:19.280 --> 05:24.080 and then I saw a lot of interest in jamad in the discussion yesterday, everybody was interested in 05:24.080 --> 05:28.560 jamad, I said, okay, I have to see what is all about, and it was right, it's really cool. 05:30.560 --> 05:35.280 All right, thank you for the first round, so in the second round, I think we had some small 05:35.280 --> 05:40.480 teasers about it already, I would like to hear from you, what do you see on this theoretical level? 05:40.480 --> 05:45.920 So, not necessarily for your own implementation, but when you look back now after you implement 05:45.920 --> 05:52.640 the jamad, what would be maybe, if you would like to have convince a friend doing a similar 05:52.640 --> 05:58.080 tool like why to implement jamad, so what is the main benefit you would see in doing that? 05:59.440 --> 06:08.720 For others, and yeah, in general. Okay, first of all, there was many iMac extensions, 06:08.800 --> 06:14.000 so when you connect to iMac server, you have to take these informations, and to know 06:15.840 --> 06:29.040 some protocols like using constor, other stuff, UIG was, so in jamad, everything of this is mandatory, 06:29.040 --> 06:37.040 so you have faster sync, and you can get all the information with just one call and just 06:37.040 --> 06:46.480 batching to get all the emails, and for example, if the user have many folders, in iMac, you 06:46.480 --> 06:54.080 have to select each folder, take the information, this a lot of network hops, with jamad, you just 06:54.080 --> 07:02.560 make one, and all the folders like mailbox IDs, so you get information from scratch for entire 07:02.720 --> 07:09.840 mailbox of the users, and we just want to call instead of again select all the folders, 07:11.120 --> 07:20.080 you can rethink that information, so it's screaming with fast compared to iMac, especially if you 07:20.080 --> 07:28.320 have a lot of folders and messages, and the other stuff is you do not need to implement iMac 07:28.400 --> 07:36.560 parsers, other stuff, which are there squirks between the different servers, it just JSON, 07:37.280 --> 07:45.360 take the data, so the benefits or to continue with the negatives, or what is missing. 07:45.600 --> 07:59.920 Okay, so i perfectly agree with you, me and the main catch is a jamad is very performant protocol, 07:59.920 --> 08:07.280 I used to be doing a demo, where on one side I would have my jamad application connect to 08:07.360 --> 08:14.320 3G load, and it's like half of a second, you have your 20 last emails in your mailbox, 08:14.880 --> 08:20.960 and I do the same with Samsung email client, and it would load forever, and maybe after 20 08:20.960 --> 08:32.240 second I would get the last like 20 mails, another example is in production, iMac client fetching 08:32.240 --> 08:37.760 all the flags of the messages in the inbox in order to re-synchronize changes, 08:37.760 --> 08:45.360 because not all clients support a quick pressing, and it's something that just don't exist in 08:46.960 --> 08:55.680 in a jamad, and I had to aggressively optimize it with iMac, I'd say that server load is 08:55.760 --> 09:06.080 full time lower on the jamad server for similar loads, so performance, it's also a big big thing. 09:10.960 --> 09:19.680 Yeah, mostly what they've said, also one benefit is that perhaps some developer 09:19.680 --> 09:27.040 implement in jamad gets care by the complexity, but I would argue that it's the way you can 09:27.040 --> 09:33.920 query the database, it has more options, like with the query changes, and you can reference other 09:33.920 --> 09:42.240 queries within the same request, but that minor complexity compensates for it's nothing compared 09:42.240 --> 09:48.160 to the complexity of implementing all the iMac parses, all the dozens of different, sorry, 09:48.400 --> 10:00.080 the iMac parsers and all the iMac extensions, I differentiate the complexity from the server 10:00.080 --> 10:06.960 point of view, where you get like all those methods to implement and that really makes a lot 10:06.960 --> 10:12.640 from the client complexity, and it's actually trivial to write a client with jamad. 10:12.720 --> 10:22.720 Yeah, to write a basic client is super fast, I mean if you just want to display an email 10:23.280 --> 10:28.480 and list what you have in your folder that's super fast, it's a bit more complex when you want to 10:28.480 --> 10:34.320 synchronize your local store with a remote store because you need to run queries, and then also 10:34.320 --> 10:41.760 if you want to optimize the way you reach the server, you can be also chain queries and 10:43.360 --> 10:48.160 a bit more complex, but the base use case which is listing and showing email delete, 10:48.160 --> 10:53.760 deleting, getting follow is super simple, you could write it in a few hours if you want it. 10:55.600 --> 11:00.960 Another benefit I realized when I was traveling at an airport that I was, I wanted to check my 11:00.960 --> 11:07.920 email over iMac and they were blocking anything that was not HTTP, so with the jim of you 11:07.920 --> 11:15.120 will be able to access your email from anywhere where they have firewalls that are only allowing 11:15.120 --> 11:28.800 HTTP. So from a theoretical standpoint, jimad is so much better than iMac, when I saw the iMac 11:29.760 --> 11:37.440 syntax is really complicated, there's some attempts to allow multiple commands to run a 11:37.440 --> 11:42.000 parallel, but then if you actually try to do that, you get in all kinds of race conditions, 11:42.000 --> 11:48.000 so you can actually do this. This is concept of a current folder in iMac, which really 11:48.000 --> 11:53.520 means that I can only do one thing at a time. If I try to do multiple things and I get race conditions, 11:53.520 --> 11:58.720 I get the data from the phone folder, so if I want to operate with multiple folders, I have 11:58.720 --> 12:04.480 to create multiple connections, and then if I do that, then Google blocks me in a second, 12:05.280 --> 12:11.280 if I open all the folders, so it's really difficult, and then the iMac service, since 12:12.320 --> 12:19.600 notifications to me, without me asking for it, and I need to process them in, it doesn't end. 12:19.680 --> 12:26.960 And jimad has really things done right in my opinion. It's clean, it's straightforward, 12:26.960 --> 12:32.960 and you can really see there's somebody behind it who A has a lot of experience, they've already 12:32.960 --> 12:37.920 implemented this, they have already built a client, they've thought of everything that you need 12:37.920 --> 12:42.480 for a client because it's all in there, and it happened a number of times to me that when 12:42.480 --> 12:46.880 I implemented this and I think, okay, so how do I do that? I need to ask the people and I just 12:46.880 --> 12:52.080 read on the specs, and I was written right there, this is how you do this and this. So even 12:52.080 --> 12:56.960 details like push notifications, like if you want to run a mail client on a mobile phone, 12:56.960 --> 13:02.480 you don't want to keep open the TCP connection because it drains the battery, and iOS kills you 13:02.480 --> 13:09.040 after a second. So I really need to push notifications, but I cannot tell the iMac server to please 13:09.040 --> 13:15.120 call a web hub in order to, for me, to wake up. So how do I do that? And I'm with the question 13:15.120 --> 13:19.840 was there, and they're right there, in the specification, put a map, there is two different ways 13:19.840 --> 13:24.000 to trigger a push notification, one phone mobile one for desktop, they're thought of everything. 13:24.000 --> 13:29.760 And this one little complexity is, they're trying really, really hard to avoid 13:29.760 --> 13:34.000 server-round tips, they're trying really hard that you can do everything in a single command, 13:34.000 --> 13:38.960 to get all the data, whatever you want in a single command, because this is written for a web 13:38.960 --> 13:43.920 client in mind, so that adds a little bit complexity that it can chain commands and all that, 13:44.880 --> 13:49.600 but it can be really useful, it can make things more efficient, because I can do everything in my 13:49.600 --> 13:54.480 in one command, and I combine them how I want, this is very modulized, I have a little complexity 13:54.480 --> 13:58.000 but it's really good, so it's really well thought of protocol. 14:00.000 --> 14:09.360 One other is about security, I think all of the iMac client that I see use basic authentication 14:10.320 --> 14:16.960 with jame up, because it's based on HTTP, you can actually use single sign-on, 14:16.960 --> 14:21.360 that's quite easy to add single sign-on in your suit and be more secure. 14:22.400 --> 14:31.280 Well, sorry question, I forgot one thing synchronization, there is not really this 14:31.280 --> 14:36.400 feature in iMac that I can synchronize things to my local mail pool, 14:37.120 --> 14:45.840 it is there, for example, AWS, it is an active thing, but not an iMac, so I can't even watch 14:45.840 --> 14:51.520 multiple folders, if I want to use, if I want to put things in nicely in folders, like I do 14:51.520 --> 14:57.200 both my file system, I put things nicely in folders, so if I want to do that in email, I don't 14:57.200 --> 15:02.160 want to constantly manually move things, so I want to use filters, I want to use service 15:02.160 --> 15:06.720 filters because I want them to work in all my clients, but if I use service side filters, 15:06.720 --> 15:11.280 now the email client doesn't know anymore that the new email arrived, because it arrived in one of 15:11.280 --> 15:17.840 the subfolders, and in iMac I cannot watch all the folders, I have to do hacks like opening 15:17.840 --> 15:24.160 multiple connections with idle, I can watch only one mailbox, and that's just notify extension 15:24.160 --> 15:32.560 which apparently nobody implements, so by default I'm implement enabled, okay, good, well then 15:32.560 --> 15:40.960 thank you, but not all servers do that, so I have to deal with that somehow in jmeb, it's just part 15:40.960 --> 15:44.880 of the protocol, I just watch the whole thing and whenever any email anywhere comes in, 15:45.120 --> 15:52.880 okay, so thanks, next I would like to go a little bit higher level, so I mean it's, 15:52.880 --> 15:58.800 jmeb is still, I mean in terms of, especially in compared to this, so if we email it's quite a 15:58.800 --> 16:04.640 young standard still, right, and especially also I think maybe most most of all of you probably 16:04.640 --> 16:09.360 not you implemented in parallel still also with iMac, because there's a lot of tools and everything 16:10.240 --> 16:15.440 around, so what I would like to know from you is your perspective a little bit on the jmeb ecosystem, 16:15.440 --> 16:22.400 so I mean it's, it's, it's jmeb at some moment like, you're, yeah, but what is your perspective 16:22.400 --> 16:29.440 how it is moving, yeah, so is it ready for primetime, let's say, right, so also maybe related to 16:29.440 --> 16:35.920 that what is your testing, interoperability testing set up, so what is your impression about also 16:36.000 --> 16:41.200 other tools, which are not here in the round implementing jmeb, I mean it's, it's a choice somehow, 16:41.200 --> 16:48.160 and so on, yeah, okay, I think for initial synchronization and rest synchronization, 16:48.880 --> 16:57.120 all the three servers, cyrus, sour, patch james are ready, but there's a little 16:57.200 --> 17:04.880 quicks that need to test with each server, for example, when you query the server, you need to 17:06.640 --> 17:13.840 test with each server, the filters, because some servers doesn't support some features, 17:13.840 --> 17:21.840 and this is not in the standard, you have to find it by yourself, so initially, past mail as 17:22.480 --> 17:30.240 first mover, they have very rich filters, and I have some filters that doesn't work with 17:31.200 --> 17:41.440 the other server, so you need to figure out the common denominator, the other stuff, is that push 17:41.440 --> 17:49.600 is still not there, this was the selling point in the beginning, yeah, actually the patch james and 17:49.680 --> 17:57.040 stowers supported it, but the bakers from past mail with cyrus, you do not offer it for third 17:57.040 --> 18:07.440 part coins, and this one that is missing also is missing, you don't need to set and get in cyrus, 18:09.360 --> 18:18.000 also is missing query change for patch james, in my opinion it's not needed for the jmeb protocol, 18:18.000 --> 18:24.960 because it's enhancement for a really cheap webcoins, and this is how they 18:24.960 --> 18:34.000 the past mail implement coins, but for example, for tenderboard kind or canine such 18:34.000 --> 18:40.400 email coins that have only in the exist, this is not needed, so it's make a lot of 18:41.040 --> 18:46.720 probably more difficult implement the server, and it's here for webcoin, but I'm not sure, 18:46.800 --> 18:57.840 because I do not implement webcoins, and the stuff is moving very slowly because of the iHF, 18:58.960 --> 19:11.040 I'm waiting for some standards since 2019, and still not there, push, and contacts, 19:11.360 --> 19:22.000 yeah, so I'll try to be quick, for me jameb is ready, it's very shine for vertical integrated 19:22.000 --> 19:28.800 solution, like fast mail, twack mail, possibly also people at at mail, where you own at the same 19:28.800 --> 19:35.920 time for front end of the back end, and the reason for that big black spots in interoperability 19:36.000 --> 19:43.840 is the lack of specification on authentication for email, which I mean, like the choice is 19:43.840 --> 19:50.000 okay, then we default basic off, but then it's not better than iMAP, and so people turn it off, 19:51.840 --> 20:00.960 it creates loads of problem with interoperating and connecting to new system, and for me that's 20:01.920 --> 20:10.000 the other big problem with jameb is for a wide adoption, not just in the stack of a single vendor, 20:11.280 --> 20:21.600 it's we actually lack a good big reference client, like let's say, from the bird, 20:22.160 --> 20:32.240 or parola, yeah, hopefully we have one now, that would convince FAA and over email provider, 20:32.240 --> 20:39.360 or to also provide jameb, and they won't do that, one side would not do that until the other one 20:39.360 --> 20:50.720 do it, sometimes looks like a deadlock, okay, regarding the available tools, I'm not sure 20:50.800 --> 21:01.120 about other programming languages, but for Rust, the one for jameb, there's a jameb crate 21:02.560 --> 21:10.240 that implements the entire jameb core, jameb mail, also the jameb web sockets, 21:11.120 --> 21:22.240 so I mean the API needs to be polished a bit, but it's fully functional, and I don't know 21:22.240 --> 21:28.480 on the jameb.io, there is a list of support, sorry, not supported, a list of libraries, 21:28.480 --> 21:34.640 for different languages, but I don't do not know the state in other places, but also if you're 21:35.360 --> 21:43.440 implementing something, also if your use case is quite simple, you don't even need a library, 21:43.440 --> 21:50.800 you can just send a JSON request that complies with the specification, and that's it, 21:53.840 --> 22:00.000 yeah, I would agree with that, you don't actually, as a client, you don't need any license, 22:00.000 --> 22:05.280 because the protocol is so straightforward, you can just write it straight out, I would probably 22:05.280 --> 22:11.760 guess that the client gets my library is more in my way than it's helping me, it was really, 22:11.760 --> 22:18.960 really nice to implement jameb, so just for comparison, I needed like six months to implement 22:18.960 --> 22:27.360 iMab, despite a fantastic library, thank you, Andre, because the concepts are so difficult, 22:27.360 --> 22:32.960 and jameb is just straightforward, it took me literally three days to implement it, and the whole 22:32.960 --> 22:38.880 client, not thinking yet, but all of them operations, moving males, lagging, moving folders, 22:38.880 --> 22:45.840 and Amy folders, everything in three days, so it gives you, it's really nice, what's wrong with the 22:45.840 --> 22:51.520 ecosystem, if you have a vertical integration like you are the holster and you provide the client, 22:51.600 --> 22:58.240 it's fine, just use stalwart, use parola as client, everything is good, but what's missing 22:58.240 --> 23:07.200 is we need somebody to implement it on the server side, a very common iMab client who's in the room 23:07.200 --> 23:14.320 and not listening, a very common email server, and I would like Google to implement it, I would 23:14.320 --> 23:20.000 like Microsoft Office 365 to implement it, and I would like to have got to implement it and roll it 23:20.080 --> 23:24.960 out that would be fantastic, and then I would love Apple male to implement it as well, 23:24.960 --> 23:29.600 that's a little push for the providers, that would be my wish for the ecosystem, and then we 23:29.600 --> 23:34.640 would move forward, but the protocol itself is ready, you can use it right now, it's working well. 23:35.920 --> 23:43.680 Thank you, so we are in the wishing face already here, so yeah, I think we had or around a little bit, 23:43.680 --> 23:50.080 and we are slowly moving also into the end of the session, so I would like also probably to open 23:50.080 --> 24:00.560 up a little bit if there is input or questions from the audience, and I see oh yeah, okay, so first on the 24:00.640 --> 24:12.800 it's a bottom right, it's behind you, all right, okay, and understand that the question 24:12.800 --> 24:18.000 to the servers, like if there are metrics, compared to the server load, iMab clients versus 24:18.080 --> 24:29.680 general clients, right, so who wants to, sorry, yeah, yeah, actual empirical data, yeah, 24:31.920 --> 24:38.560 I can, so actually I do end up to have two very identical clients in terms of size 24:38.640 --> 24:48.000 and email usage in terms of volume, but one of them uses massively iMab clients, and the other one 24:48.000 --> 24:56.480 uses only the web mail that we provide that is jamab based, so that's the metric that I did use 24:57.440 --> 25:08.960 factor free of all area, we did do also study on network usage, comparing our application on mobile 25:09.600 --> 25:21.760 with one or two iMab application, I don't remember exactly the numbers of those tests, but it was 25:21.840 --> 25:28.720 significantly lower in terms of bandwidth, and absolutely dramatic in terms of wrong trip, 25:29.840 --> 25:31.200 did that answer a question? 25:36.320 --> 25:44.320 I thought we'd push, yeah, personally, I don't have any, I heard measure, compared 25:45.280 --> 25:51.600 both protocols, but I just wanted to say that there are different ways to do that comparison, 25:51.600 --> 25:57.840 because you could keep sending multiple jamab requests each time you do something or you can keep 25:57.840 --> 26:05.280 open a web socket connection, or a mix of those two, which is sending requests and then 26:05.280 --> 26:14.720 keep an open an event stream for the data. I know so there is some of this new standard 26:14.720 --> 26:18.640 called jamab for blood management, that also goes to reduce the bandwidth, so there 26:21.200 --> 26:27.520 is somewhere that could be measured simply by looking at the logs and comparing two clients 26:27.520 --> 26:34.240 accessing the same data and adding up, or if you have open telemetry, adding up the size, 26:34.800 --> 26:40.800 parameters of the raw requests, and you get an exact measure of what's going on. 26:40.800 --> 26:46.400 But yeah, there's a lot of stuff to measure, like with what's socket with the jamab for 26:46.400 --> 26:52.080 blood extension and so on. So, I think there was another question. 27:04.320 --> 27:09.040 In drops, you mean, like the binary, yeah, it's a mean in comparison, sorry, or 27:13.840 --> 27:19.680 which, beyond the event, so okay, I just repeat the question for the camera, so the question is, 27:19.680 --> 27:23.920 while it also has jamab males, there's now a couple of other things like jamab for 27:23.920 --> 27:29.680 blobs, jamab for calendars contact, so is there any, yeah, I can point at the, um, 27:30.640 --> 27:35.920 well, I have implemented the in addition to the jamab core jamab male, also the jamab for 27:35.920 --> 27:40.720 blood management, which is not web-dive, it's just a quick way to manage the blobs in the server 27:40.720 --> 27:46.960 that could be emails or whatever else. They also jamab for sieve, which is like a, it's a replacement 27:46.960 --> 27:54.480 for the managed sieve protocol, and then there's also, I think, and forgetting, wow, jamab for 27:55.440 --> 28:01.440 but then there is a new, what, the, as you mentioned, the jamab for calendars, for tasks, 28:02.480 --> 28:08.960 and contacts, and there's a new one coming for a file management, like to use your server as a 28:08.960 --> 28:15.520 file storage, but I don't have, I have not started working on those, but yeah, they look promising 28:15.520 --> 28:22.960 and more efficient, I web-dive and card-out, yeah. Any final note from some of you, as a wife, 28:23.920 --> 28:30.240 very, very short one, yeah, okay. Okay, if you implement a jamab for male with the same 28:30.240 --> 28:38.000 engine in theory, you can sync the calendars and the contacts, just apply different saving 28:38.000 --> 28:44.400 metals to emails and contacts and others, so synchronization, initial synchronization, 28:44.400 --> 28:50.080 risk synchronization is the same whole of that. All right, so thank you very much, my 28:50.080 --> 28:55.360 panelists here, and fortunately, especially for the short notice, you know, readiness to hold 28:55.360 --> 29:00.400 this panel, unfortunately, I don't have presents prepared, like usually you do from panelists, 29:00.400 --> 29:04.800 but I think the audience will give you a warm applause, thank you very much.