he4et/oddsquat
1
0
Fork 0
mirror of https://github.com/He4eT/oddsquat.git synced 2026-05-04 12:27:23 +00:00
Code Issues Projects Releases Packages Wiki Activity

posts: encrypted_XMPP: linting

Browse source
This commit is contained in:
He4eT 2026-04-16 01:18:42 +02:00 • committed by Alexey
commit e53110547d
1 changed files with 270 additions and 223 deletions
Download patch file Download diff file Expand all files Collapse all files

477
src/pages/posts/2026/encrypted_XMPP.md
View file

@ -11,346 +11,392 @@ description: 'Secure and private messaging with XMPP and OMEMO encryption.'
---
# End-to-End Encryption in XMPP with OMEMO
# End-to-End Encryption in XMPP with OMEMO
I find it funny that twenty years ago I was already trying
to get people to switch to XMPP.
I find it funny that twenty years ago I was already trying
to get people to switch to XMPP.
For a long time, ICQ was extremely popular around me,
For a long time, ICQ was extremely popular around me,
but the proprietary messenger kept breaking things for people
using alternative clients, which was quite annoying.
After yet another round of this pointless battle
I realized clearly that I prefer protocols over services.
After yet another round of this pointless battle
I realized clearly that I prefer protocols over services.
I didn't have much success back then,
but fortunately, XMPP (and I hope I have too)
I didn’t have much success back then,
but fortunately, XMPP (and I hope I have too)
has continued moving forward over the past two decades.
It has developed slowly, sometimes awkwardly, but steadily.
It has developed slowly, sometimes awkwardly, but steadily.
Here, I won't talk about why XMPP is great or how it works.
Here, I won’t talk about why XMPP is great or how it works.
You can check
<a
href='https://contrapunctus.codeberg.page/the-quick-and-easy-guide-to-xmpp.html'
target='_blank'>
this guide</a>
(one of many) and I'd rather not write another one.
In this post, I want to focus specifically on end-to-end encryption
and the practical aspects of using it.
(one of&nbsp;many) and I’d rather not write another one.
In&nbsp;this post,
I&nbsp;want to&nbsp;focus specifically on&nbsp;end-to-end encryption
and the practical aspects of&nbsp;using it.
## Short Glossary
**End-to-end encryption** is a way to keep your chats truly private.<br>
Only you and the person you're messaging can read the messages.
Not even the server owner has the keys needed to decrypt or modify them.
**End-to-end encryption** is&nbsp;a&nbsp;way
to&nbsp;keep your chats truly private.<br>
Only you and the person you’re messaging can read the messages.
Not even the server owner has the keys
needed to&nbsp;decrypt or&nbsp;modify them.
**XMPP** is an extensible protocol for instant messaging.
It's open, decentralized, and mature.
**XMPP** is&nbsp;an&nbsp;extensible protocol for instant messaging.
It’s open, decentralized, and mature.
**OMEMO** is a&nbsp;<a
**OMEMO** is&nbsp;a&nbsp;<a
href='https://omemo.top/'
target='_blank'>widely supported</a>
XMPP Extension Protocol (XEP)
for secure multi-client end-to-end encryption.
You can read more about
it on a&nbsp;<a
it&nbsp;on&nbsp;a&nbsp;<a
href='https://contrapunctus.codeberg.page/the-quick-and-easy-guide-to-xmpp.html'
target='_blank'>dedicated page by Daniel Gultsch</a>.
target='_blank'>dedicated page by&nbsp;Daniel Gultsch</a>.
**Client**, in this post,
means a specific instance of an XMPP application on a user device.
**Client**, in&nbsp;this post,
means a&nbsp;specific instance
of&nbsp;an&nbsp;XMPP application on&nbsp;a&nbsp;user device.
<br>OMEMO-related documentation uses the term Device,
but I find it potentially confusing:
in practice, a single physical device can run multiple independent clients.
but I&nbsp;find it&nbsp;potentially confusing:
in&nbsp;practice, a&nbsp;single physical device
can run multiple independent clients.
## Basic Concepts
This section introduces some basics of end-to-end encryption.
This section introduces some basics of&nbsp;end-to-end encryption.
If you're already familiar with the concepts and terminology,
If&nbsp;you’re already familiar with the concepts and terminology,
you can skip ahead to&nbsp;<a
href='#practical-aspects-of-omemo-and-xmpp'>how end-to-end encryption affects the XMPP user experience</a>
or jump straight to the <a
href='#step-by-step-guide'>step-by-step workflow</a>&nbsp;I personally use.
href='#practical-aspects-of-omemo-and-xmpp'>how end-to-end encryption
affects the XMPP user experience</a>,
or&nbsp;jump straight to&nbsp;the <a
href='#step-by-step-guide'>step-by-step workflow</a> I&nbsp;personally use.
### Trade-offs Between Safety and Convenience
Unfortunately, things that are truly secure are rarely convenient.
They often require some initial efforts and a bit of ongoing attention.
They often require some initial efforts
and a&nbsp;bit of&nbsp;ongoing attention.
Telegram, which used to be a benchmark for messenger usability
Telegram, which used to&nbsp;be&nbsp;a&nbsp;benchmark for messenger usability
before its long dive into enshitification,
really draws the line between convenience and security.
Regular chats are easy and flexible,
but "secret" chats come with a full set of limitations:
they're one-on-one only,
can't be synced to another device,
aren't available on desktop at all,
and so on.
but “secret” chats come with a&nbsp;full set of&nbsp;limitations:
they’re one-on-one only,
can’t be&nbsp;synced to&nbsp;another device,
aren’t available on&nbsp;desktop at&nbsp;all,
and so&nbsp;on.
All commercial so-called "secure" messengers, like Signal or WhatsApp,
end up with pretty similar limitations,
because it's tricky to make end-to-end encrypted chats
All commercial so-called “secure” messengers, like Signal or&nbsp;WhatsApp,
end up&nbsp;with pretty similar limitations,
because it’s tricky to&nbsp;make end-to-end encrypted chats
work the way users expect.
Luckily, protocols and cryptography don't care about
convenience or user expectations.
Many XMPP clients let you do almost anything you're trying to do.
Sometimes it's clunky and unintuitive,
sometimes it's the kind of freedom that lets you shoot yourself in the foot.
At the end of the day, you'd better understand what you're doing.
Luckily, protocols and cryptography don’t care about
convenience or&nbsp;user expectations.
Many XMPP clients let you do&nbsp;almost anything you’re trying to&nbsp;do.
Sometimes it’s clunky and unintuitive,
sometimes it’s the kind of&nbsp;freedom
that lets you shoot yourself in&nbsp;the foot.
At&nbsp;the end of&nbsp;the day, you’d better understand what you’re doing.
It might sound messy, but for that price, XMPP actually
gives you a lot of handy features:
It&nbsp;might sound messy, but for that price, XMPP actually
gives you a&nbsp;lot of&nbsp;handy features:
your chats are secured with Signal-grade end-to-end encryption,
and you can use as many devices as you want,
all at the same time,
without being tied to any proprietary service.
and you can use as&nbsp;many devices as&nbsp;you want,
all at&nbsp;the same time,
without being tied to&nbsp;any proprietary service.
In general, the XMPP experience today
could be described as a "WhatsApp with benefits and frictions".
It's kinda ironic, considering that WhatsApp's protocol
is actually based on XMPP, but incompatibly altered and defederated.
In&nbsp;general, the XMPP experience today
could be&nbsp;described as&nbsp;a&nbsp;“WhatsApp with benefits and frictions”.
It’s kinda ironic, considering that WhatsApp’s protocol
is&nbsp;actually based on&nbsp;XMPP, but incompatibly altered and defederated.
### Keys, Fingerprints and Trust
OMEMO is based on the
<a href='https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm' target='_blank'>
OMEMO is&nbsp;based on&nbsp;the <a
href='https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm'
target='_blank'>
Double Ratchet Algorithm</a>.
While the internal details are quite interesting,
for practical purposes it's enough to know that
for practical purposes it’s enough to&nbsp;know that
each client stores some cryptographic keys
and can derive a hash from them, commonly called a fingerprint.
and can derive a&nbsp;hash from them, commonly called a&nbsp;fingerprint.
Keys are usually managed automatically by the XMPP client,
and in normal use you should never need to handle them manually.
In fact, you probably don't even need to know what they look like.
Keys are usually managed automatically by&nbsp;the XMPP client,
and in&nbsp;normal use you should never need to&nbsp;handle them manually.
In&nbsp;fact, you probably don’t even need to&nbsp;know what they look like.
A fingerprint lets you identify a specific client of your contact
and verify that it hasn't been spoofed.
Fingerprints for an account are not secret:
clients publish their own fingerprints to the XMPP server
and automatically receive the fingerprints of others.
Only fingerprints you explicitly mark as trusted are relevant.
A&nbsp;fingerprint lets you identify
a&nbsp;specific client of&nbsp;your contact
and verify that it&nbsp;hasn’t been spoofed.
Fingerprints for an&nbsp;account are not secret:
clients publish their own fingerprints to&nbsp;the XMPP server
and automatically receive the fingerprints of&nbsp;others.
Only fingerprints you explicitly mark as&nbsp;trusted are relevant.
In an ideal scenario, the contact should confirm in person
or through an already trusted and secure communication channel
that the fingerprint belongs to their device,
and only then you mark it as trusted.
In most XMPP clients this is simply done by ticking a checkbox
or by scanning a QR code.
In&nbsp;an&nbsp;ideal scenario, the contact should confirm in&nbsp;person
or&nbsp;through an&nbsp;already trusted and secure communication channel
that the fingerprint belongs to&nbsp;their device,
and only then you mark it&nbsp;as&nbsp;trusted.
In&nbsp;most XMPP clients this is&nbsp;simply done
by&nbsp;ticking a&nbsp;checkbox
or&nbsp;by&nbsp;scanning a&nbsp;QR&nbsp;code.
The list of trusted fingerprints is used at the moment a message is sent.
Behind the scenes, OMEMO performs a certain amount of key management,
and only the clients that are present in the trusted list
at the time of encryption will be able to decrypt the message later.
The list of&nbsp;trusted fingerprints
is&nbsp;used at&nbsp;the moment a&nbsp;message is&nbsp;sent.
Behind the scenes,
OMEMO performs a&nbsp;certain amount of&nbsp;key management,
and only the clients that are present in&nbsp;the trusted list
at&nbsp;the time of&nbsp;encryption
will be&nbsp;able to&nbsp;decrypt the message later.
It's important to understand that trust cannot be applied retroactively:
it's not possible to "extend" trust to new clients
after a message has already been encrypted and sent.
It’s important to&nbsp;understand
that trust cannot be&nbsp;applied retroactively:
it’s not possible to&nbsp;“extend” trust to&nbsp;new clients
after a&nbsp;message has already been encrypted and sent.
## Practical Aspects of OMEMO and XMPP
## Practical Aspects of&nbsp;OMEMO and XMPP
### Chat History
In theory, XMPP supports server-side message history storage via
In&nbsp;theory, XMPP supports server-side message history storage via
**XEP-0313: Message Archive Management**.
In practice, support for this XEP,
as well as retention policies and message lifetime,
depends on the specific server.
In&nbsp;practice, support for this XEP,
as&nbsp;well as&nbsp;retention policies and message lifetime,
depends on&nbsp;the specific server.
You should never assume that all conversations are stored
indefinitely by default.
From a practical standpoint,
the server-side MAM archive is better considered a cache:
it can help you handle recent messages after a short period offline
or synchronize conversations across multiple devices.
indefinitely by&nbsp;default.
From a&nbsp;practical standpoint,
the server-side MAM archive is&nbsp;better considered a&nbsp;cache:
it&nbsp;can help you handle recent messages after a&nbsp;short period offline
or&nbsp;synchronize conversations across multiple devices.
At the end of the day, keeping your chat history is your responsibility,
and this is a good place to apply a local-first approach.
At&nbsp;the end of&nbsp;the day,
keeping your chat history is&nbsp;your responsibility,
and this is&nbsp;a&nbsp;good place to&nbsp;apply a&nbsp;local-first approach.
### Synchronisation
Seamless switching between clients is handled by
Seamless switching between clients is&nbsp;handled by
**XEP-0280: Message Carbons**.
Before its introduction, only incoming messages were synced between devices,
while your own outgoing messages were not.
Protocol-level mirroring of your own messages
is a rather non-obvious feature :D
Protocol-level mirroring of&nbsp;your own messages
is&nbsp;a&nbsp;rather non-obvious feature :D
It's important to note that with end-to-end encryption,
the concept of trusted fingerprints also applies to your own clients.
For seamless synchronisation of outgoing messages,
all your clients must trust each other's fingerprints.
A new client,
or an old one that was not trusted at the time messages were sent,
will receive the full history from MAM but will not be able to decrypt it.
It’s important to&nbsp;note that with end-to-end encryption,
the concept of&nbsp;trusted fingerprints also applies to&nbsp;your own clients.
For seamless synchronisation of&nbsp;outgoing messages,
all your clients must trust each other’s fingerprints.
A&nbsp;new client,
or&nbsp;an&nbsp;old one that was not trusted
at&nbsp;the time messages were sent,
will receive the full history from MAM
but will not be&nbsp;able to&nbsp;decrypt it.
<br>Yes, even your own messages.
In theory, re-encrypting messages on already trusted clients
could solve this issue, but no XMPP client implements it yet.
So in practice you may need to manually resend
some data to a new device.
In&nbsp;theory, re-encrypting messages on&nbsp;already trusted clients
could solve this issue, but no&nbsp;XMPP client implements it&nbsp;yet.
So&nbsp;in&nbsp;practice you may need to&nbsp;manually resend
some data to&nbsp;a&nbsp;new device.
### Message Correction
It's worth keeping in mind that
features that seem simple and straightforward at first glance,
such as message editing and deletion,
actually rely on client-side implementation
It’s worth keeping in&nbsp;mind that
features that seem simple and straightforward at&nbsp;first glance,
such as&nbsp;message editing and deletion,
actually rely on&nbsp;client-side implementation
and may not behave for your recipient the way you expect.
They're fine to use and are well supported in some clients,
but you shouldn't rely on them to hide anything.
They’re fine to&nbsp;use and are well supported in&nbsp;some clients,
but you shouldn’t rely on&nbsp;them to&nbsp;hide anything.
### Maintenance
OMEMO was designed as a set-it-and-forget-it solution,
and it mostly succeeds in that goal.
If you have a basic understanding of how the protocol works
and check in online from time to time,
there shouldn't be any surprises.
OMEMO was designed as&nbsp;a&nbsp;set-it-and-forget-it solution,
and it&nbsp;mostly succeeds in&nbsp;that goal.
If&nbsp;you have a&nbsp;basic understanding of&nbsp;how the protocol works
and check in&nbsp;online from time to&nbsp;time,
there shouldn’t be&nbsp;any surprises.
All maintenance comes down to making regular backups
All maintenance comes down to&nbsp;making regular backups
and notifying your contacts
when fingerprints are added or no longer valid
so they can keep their trust list up to date.
when fingerprints are added or&nbsp;no&nbsp;longer valid
so&nbsp;they can keep their trust list up&nbsp;to&nbsp;date.
## Step-by-Step Guide
Let's say I have a XMPP account, `me@some.server`,
and a few devices: a phone, a laptop, and a desktop computer.
First I'll describe my mindset at a high level,
then I'll add some notes about specific clients.
Let’s say I&nbsp;have a&nbsp;XMPP account, `me@some.server`,
and a&nbsp;few devices:
a&nbsp;phone, a&nbsp;laptop, and a&nbsp;desktop computer.
First I’ll describe my&nbsp;mindset at&nbsp;a&nbsp;high level,
then I’ll add some notes about specific clients.
### Client Roles
On the one hand, I have my phone.
It's almost always with me and almost always online.
That's where I keep the full chat history and get real-time notifications.
On&nbsp;the one hand, I&nbsp;have my&nbsp;phone.
It’s almost always with me&nbsp;and almost always online.
That’s where I&nbsp;keep the full chat history
and get real-time notifications.
On the other hand, I have a couple of desktop applications.
I only open them when I need to discuss something using my keyboard
or share some text between devices.
I like to think of them as satellite clients.
On&nbsp;the other hand, I&nbsp;have a&nbsp;couple of&nbsp;desktop applications.
I&nbsp;only open them
when I&nbsp;need to&nbsp;discuss something using my&nbsp;keyboard
or&nbsp;share some text between devices.
I&nbsp;like to&nbsp;think of&nbsp;them as&nbsp;satellite clients.
### Before the Start
First, enable OMEMO encryption on every client if it isn't enabled by default.
First, enable OMEMO encryption
on&nbsp;every client if&nbsp;it&nbsp;isn’t enabled by&nbsp;default.
The next step is to add all clients to the trust list on each device:
my phone should trust all my computers,
and my computers should trust each other as well as my phone.
The next step is&nbsp;to&nbsp;add
all clients to&nbsp;the trust list on&nbsp;each device:
my&nbsp;phone should trust all my&nbsp;computers,
and my&nbsp;computers should trust each other
as&nbsp;well as&nbsp;my&nbsp;phone.
Fingerprints do not have to be secret, so they can be published on
your website or even on social media profiles.
Here is my page with the fingerprints, for example:
Fingerprints do&nbsp;not have to&nbsp;be&nbsp;secret,
so&nbsp;they can be&nbsp;published on
your website or&nbsp;even on&nbsp;social media profiles.
Here is&nbsp;my&nbsp;page with the fingerprints, for example:
<br><a href='https://oddsquat.org/about/keys/' target='_blank'>
https://oddsquat.org/about/keys/
</a>
### Start the Conversation in Person
### Start the Conversation in&nbsp;Person
Let's say I meet Alice,
we start talking, and then decide to continue the conversation online.
Let’s say I&nbsp;meet Alice,
we&nbsp;start talking,
and then decide to&nbsp;continue the conversation online.
I open a special QR code on my phone, and Alice scans it with her client.
This QR code already contains the fingerprints of all my devices,
so no extra steps are needed on her phone.
After that, I do the same and scan her QR code as well.
I&nbsp;open a&nbsp;special QR&nbsp;code on&nbsp;my&nbsp;phone,
and Alice scans it&nbsp;with her client.
This QR&nbsp;code already contains
the fingerprints of&nbsp;all my&nbsp;devices,
so&nbsp;no&nbsp;extra steps are needed on&nbsp;her phone.
After that, I&nbsp;do&nbsp;the same
and scan her QR&nbsp;code as&nbsp;well.
Later at home, I manually mark her devices as trusted on my computers
using the trusted list on my phone, and she does the same.
Later at&nbsp;home,
I&nbsp;manually mark her devices as&nbsp;trusted on&nbsp;my&nbsp;computers
using the trusted list on&nbsp;my&nbsp;phone, and she does the same.
Now we are both sure that it is really us in the conversation,
and that all messages will be available on all our devices and only on them.
Now we&nbsp;are both sure
that it&nbsp;is&nbsp;really us&nbsp;in&nbsp;the conversation,
and that all messages will be&nbsp;available
on&nbsp;all our devices and only on&nbsp;them.
### Start the Conversation Online
Let's say Bob and I start discussing something
on a forum or in the Fediverse,
and then decide to continue the discussion on XMPP.
Let’s say Bob and I&nbsp;start discussing something
on&nbsp;a&nbsp;forum or&nbsp;in&nbsp;the Fediverse,
and then decide to&nbsp;continue the discussion on&nbsp;XMPP.
Bob starts the chat. I trust the first device he messages me from,
and then we exchange fingerprints for our other devices, if we have any.
This approach is called TOFU (Trust On First Use).
Bob starts the chat.
I&nbsp;trust the first device he&nbsp;messages me&nbsp;from,
and then we&nbsp;exchange fingerprints for our other devices,
if&nbsp;we&nbsp;have any.
This approach is&nbsp;called TOFU (Trust On&nbsp;First Use).
Bob can confirm it's really me using my page with fingerprints.
I can confirm it's really him by asking him to send his fingerprints
in a private message on the same forum or via email.
Bob can confirm it’s really me&nbsp;using my&nbsp;page with fingerprints.
I&nbsp;can confirm it’s really him
by&nbsp;asking him to&nbsp;send his fingerprints
in&nbsp;a&nbsp;private message on&nbsp;the same forum or&nbsp;via email.
Ideally, Bob also has a public page with his fingerprints.
That way, we can both independently verify
that we are who we say we are.
Ideally, Bob also has a&nbsp;public page with his fingerprints.
That way, we&nbsp;can both independently verify
that we&nbsp;are who we&nbsp;say we&nbsp;are.
### New or Lost Devices
### New or&nbsp;Lost Devices
If I start using a new device or install another client application,
the first thing I do is add it to the list of trusted clients
on my existing devices.
If&nbsp;I&nbsp;start using a&nbsp;new device
or&nbsp;install another client application,
the first thing I&nbsp;do&nbsp;is&nbsp;add it&nbsp;to&nbsp;the list
of&nbsp;trusted clients on&nbsp;my&nbsp;existing devices.
If I lose one of my devices or delete any private keys,
the first thing I do is remove the corresponding client
from the trusted list on my other devices.
If&nbsp;I&nbsp;lose one of&nbsp;my&nbsp;devices
or&nbsp;delete any private keys,
the first thing I&nbsp;do&nbsp;is&nbsp;remove the corresponding client
from the trusted list on&nbsp;my&nbsp;other devices.
Once I've updated all my personal lists,
I should inform my contacts about changes via trusted channels.
Once I’ve updated all my&nbsp;personal lists,
I&nbsp;should inform my&nbsp;contacts about changes via trusted channels.
I can simply ask Alice to scan my new QR code the next time we meet,
and send Bob a message introducing my new client or letting him know
that the lost device is no longer trusted
and that no real messages will ever come from it again.
I&nbsp;can simply ask Alice to&nbsp;scan
my&nbsp;new QR&nbsp;code the next time we&nbsp;meet,
and send Bob a&nbsp;message introducing
my&nbsp;new client or&nbsp;letting him know
that the lost device is&nbsp;no&nbsp;longer trusted
and that no&nbsp;real messages will ever come from it&nbsp;again.
## Client Applications
This section describes how OMEMO is used in specific client applications
that I personally use.
This section describes
how OMEMO is&nbsp;used in&nbsp;specific client applications
that I&nbsp;personally use.
### Conversations and Forks
Conversations is a modern, fully featured chat application for Android.
It supports everything a messaging app should support:
chats, voice calls, video calls, and sharing files of any kind.
Conversations is&nbsp;a&nbsp;modern,
fully featured chat application for Android.
It&nbsp;supports everything a&nbsp;messaging app should support:
chats, voice calls, video calls, and sharing files of&nbsp;any kind.
There are several forks of it where the UI or UX may differ,
There are several forks of&nbsp;it&nbsp;where
the UI&nbsp;or&nbsp;UX&nbsp;may differ,
but the core features work exactly the same.
I personally use Monocles Chat.
I&nbsp;personally use Monocles Chat.
On the Contact Details screen (including your own account),
you can see a list of published fingerprints
and manually mark them as trusted or revoke trust.
On&nbsp;the Contact Details screen (including your own account),
you can see a&nbsp;list of&nbsp;published fingerprints
and manually mark them as&nbsp;trusted or&nbsp;revoke trust.
To simplify all these routine operations, a QR-code-based system is used:
you can show your own QR code or scan other people's codes
To&nbsp;simplify all these routine operations,
a&nbsp;QR-code-based system is&nbsp;used:
you can show your own QR&nbsp;code or&nbsp;scan other people’s codes
directly from the main screen.
This makes device verification during in-person meetings simple and effortless.
This makes device verification during in-person meetings
simple and effortless.
### Dino
Dino is a lightweight GTK-based GUI client.
Dino is&nbsp;a&nbsp;lightweight GTK-based GUI client.
It can be considered a fully functional one,
It&nbsp;can be&nbsp;considered a&nbsp;fully functional one,
although some non-essential features are still not implemented.
For example,
it is not possible to clear local chat history using built-in methods :D
it&nbsp;is&nbsp;not possible to&nbsp;clear local chat history
using built-in methods :D
Trust and untrust decisions can be easily managed
in the Encryption tab of the Conversation Details window.
Trust and untrust decisions can be&nbsp;easily managed
in&nbsp;the Encryption tab of&nbsp;the Conversation Details window.
It is important to note that, by default, Dino is configured
to automatically trust new fingerprints.
I recommend disabling this feature.
It&nbsp;is&nbsp;important to&nbsp;note that,
by&nbsp;default, Dino is&nbsp;configured
to&nbsp;automatically trust new fingerprints.
I&nbsp;recommend disabling this feature.
### Profanity
Profanity is a powerful TUI client
where everything is controlled through a built-in command system.
Profanity is&nbsp;a&nbsp;powerful TUI client
where everything is&nbsp;controlled through a&nbsp;built-in command system.
If you somehow intend to use it,
you can find a small cheat sheet for the `/omemo` command below.
However, I strongly recommend reading the full documentation.
If&nbsp;you somehow intend to&nbsp;use it,
you can find a&nbsp;small cheat sheet for the `/omemo` command below.
However, I&nbsp;strongly recommend reading the full documentation.
- Generate a key and add your other clients:
- Generate a&nbsp;key and add your other clients:
```text
/omemo gen
/omemo trust me@some.server some-cool-fingerprint-01
@ -358,41 +404,42 @@ However, I strongly recommend reading the full documentation.
/omemo qrcode
```
- View the list of your own or someone else's fingerprints:
- View the list of&nbsp;your own or&nbsp;someone else’s fingerprints:
```text
/omemo fingerprint me@some.server
/omemo fingerprint alice@another.server
```
Trusted ones will be marked as `trusted`.
Trusted ones will be&nbsp;marked as&nbsp;`trusted`.
- Start an encrypted conversation:
- Start an&nbsp;encrypted conversation:
```text
/omemo start alice@another.server
```
- Add fingerprints to the trusted list:
- Add fingerprints to&nbsp;the trusted list:
```text
/omemo trust alice@another.server some-cool-fingerprint-02
/omemo trust alice@another.server some-cool-fingerprint-03
/omemo trust bob@another.server some-cool-fingerprint-04
```
- Revoke trust for a specific client:
- Revoke trust for a&nbsp;specific client:
```text
/omemo untrust alice@another.server some-cool-fingerprint-02
```
## Late Disclaimer
This post was originally intended as a collection of answers to questions
I had when I first started using XMPP with OMEMO.
This post was originally intended
as&nbsp;a&nbsp;collection of&nbsp;answers to&nbsp;questions
I&nbsp;had when I&nbsp;first started using XMPP with OMEMO.
It isn't meant to be exhaustive or formal,
but rather to clarify the practical side of things
and reduce that initial feeling of being lost
It&nbsp;isn’t meant to&nbsp;be&nbsp;exhaustive or&nbsp;formal,
but rather to&nbsp;clarify the practical side of&nbsp;things
and reduce that initial feeling of&nbsp;being lost
when you keep running into
"The message was not encrypted for this device"
“The message was not encrypted for this device”
over and over again.
From now on, I hope you won't encounter errors like this
or any other issues with end-to-end encryption in XMPP.
From now on, I&nbsp;hope you won’t encounter errors like this
or&nbsp;any other issues with end-to-end encryption in&nbsp;XMPP.