It's fine.
Anyway, good morning everyone.
My name is Daniel.
Today I'm going to take a few minutes to tell you a little
bit about a JMAP only client for Android that I've been
working on for a while.
But first a few quick notes about myself.
I usually work in instant messaging.
I'm an XMPP developer.
I am on the Council of the XMPP Standards Foundation.
I develop an XMPP client for Android called Conversations.
And yeah, JMAP is a long-term side project of mine.
I checked yesterday that I registered the LTT.RS domain in
2017.
And I think I've been working on that for even longer than
that, somewhere on my hard drive.
There's an implementation for the pre-RFC JMAP thing.
That's at Fastmail Road.
And yeah, these days I develop a aforementioned Java
library and the Android client for letters.
So why JMAP?
So as someone who's starting from scratch, I think you
already got the sales pitch for JMAP.
You have a same set of extensions.
You can do sent and receive over the same protocol.
JSON parsers are readily available.
You don't have to do whatever IMAP is.
On top of that, you don't have to do any mind parsing.
If you ever wrote a mind parser, you know how much of a
relief that is not having to do that.
It has built-in push support.
So especially if you're targeting web or modern
mobile phone operating systems, it's good to have
vendor push.
And yeah, essentially just see Ricardo's maybe omitted
slides on how bad or how weird IMAP is.
And yeah, you pretty much know why I way to JMAP.
So a little bit of the architecture.
The way applications have changed or how Android
applications are developed have changed quite a lot.
In the last 10 years, Google has released a set of
libraries they call Jetpack that make application
development a lot easier.
And Lettuce tries to use a lot of them.
For example, there's Room, which is a database
abstraction layer where you basically define how your
UI displays the information in the database.
And then whenever you write to the database, your UI
automatically gets updated.
And only those things that have changed.
So the way I implemented is that my JMAP library has a
generic search backend that's then implemented by Room.
We write data to Room.
And then magically, our UI gets updated.
And we don't have to do anything.
And also because my main job, again, is developing
conversations, which by now is like 10 years old and quite
legacy.
Lettuce also has a sort of playground for me to work
with new Android APIs, such as Material.U, which is the new
design language, or predictive things like that.
So you already heard that both IMAP and JMAP are
essentially like cache management protocols.
And that allows us to have great offline capabilities in
Lettuce.
So all queries, whether you view a certain mailbox or even
if you do a search, those are all cached.
So if you retry a search or redo a search, when you're
offline, you still see all search results.
And then all user actions are handled by another Jetpack
library called WorkManager that automatically retries those
actions when the user comes back online.
Yeah, while the app is in the foreground, we use web
sockets and event source to listen for server side
changes and refresh the UI.
And we also, when the app is in the background, we have a
fully open source web push implementation.
We don't actually use LIC Play Services library, but we talk
directly.
We are open source code too.
So Firebase, or the Google Play Services to retrieve a
web push URL, you can actually trick Firebase into giving
you a web push URL instead of doing the application
server thing that you might be familiar with from other
Android apps.
But that requires like Vapet, like a voluntary application
server identification, which JMAP currently does not
support.
And I'm in the process of writing in RFC for that.
And yeah, because we have native web push, we can also hook
in other push implementations that are not bound by Google.
For example, like Unified Push.
And the way that works is, for example, that the JMAP server
can tell my XPP server to tell conversations to wake up
letters.
And then Google is not involved at all.
And I can like self-force every part of that.
We also have native enabled by default order
crypt support.
No plug-in required.
It just works.
You see a lock icon on your compose screen.
If the other part supports it too.
During account setup, we ask for key import.
If we previously used setup messages, just refer to the
auto crypt spec on how that works.
But server devs, please allow us to search for arbitrary
email headers, because we need that to discover the setup
message.
That's it.
Thank you for your attention.
You will find the code of the JMAP library on Codebook, the
Android client.
If you want, follow me on message.
I'm Daniel at Google.Social.
The source code for my slides is also online.
Yeah, thank you.
Any questions?
Thank you.
Any conversation about letters or JMAP?
Come on.
So you said there's no need for a MIME parser.
Is there really no, never any reason to have a MIME
parser yourself?
Yeah, I didn't want to put that on the slides.
But as soon as you do like PGP encryption, you do have to do
a MIME parser.
That's what it was.
Oh, damn, now I have to deal with my parsing.
But the MIME that is in most PGP messages that I encountered
is a lot saner than what you might encounter on
wild email servers.
So yeah, that's a relief.
All right.
Any further question?
For the boost, I want to know.
Do you use Udify?
You can receive the notification or all the Zmaps over?
Yes.
Yeah, so JMAP has built in web push support, which is like
an RFC as well.
And then you can either speak web push towards Google and let
Google relay your messages or use Unified Push.
And you best go to UnifiedPush.org if you want to
learn more about the self-hosted version of Unified
Push, because that's too complicated of a topic to
have in a five-minute Q&A session.
All right.
Any further question?
Otherwise, thanks again to Daniel.
Thank you.