Skip to content

Instantly share code, notes, and snippets.


Verify encrypted A/V calls with OMEMO

Audio and Video calls in XMPP are encrypted end-to-end with DTLS-SRTP as per XEP-0320: Use of DTLS-SRTP in Jingle Sessions.

This protocol replaces XEP-0320 with something that is encrypted with and verified by OMEMO.

Disclaimer: The proper solution is to use OMEMO version 0.5+ and Stanza Content Encryption and encrypt the entire Jingle handshake. However we are still a long road away from having OMEMO 0.5+ in general and any implementational experience with SCE for IQ based protocols in particular. The protocol proposed here is a hack that is hopefully not too dirty.

Extension of XEP-0353: Jingle Message Initiation

export JAVA_HOME=/usr/lib/jvm/java-8-openjdk/
export ANDROID_HOME=/opt/android-sdk
git clone
disorderfs --sort-dirents=yes --reverse-dirents=no lttrs-android $BUILD_DIRECTORY
./gradlew assembleRelease
sha256sum app/build/outputs/apk/release/
View 10-keyboard.conf
Section "InputClass"
Identifier "system-keyboard"
MatchIsKeyboard "on"
Option "XkbModel" "pc105"
Option "XkbLayout" "de"
Option "XkbVariant" "neo"

OMEMO encryption in group chats works basically like it works in 1:1 chats as well. Instead of encrypting using all of your contacts‘ sessions and all of your other devices’ sessions you encrypt using all of the the participants’ devices sesions (plus all of your other devices).


It is recommended to use the very same sessions you’d be using for 1:1 chats as well. So messages going to someone directly are encrypted using the same session as messages going to a group chat with that someone in it.

For this to work we need to be able to discover the real XMPP address of all participants. Therefor it is a fundamental requirement for all OMEMO enabled group chats to be non-anonymous. On top of that Conversations (and probably other clients) limit OMEMO to members-only groups. Encrypting messages in a chat where everyone can join and potentially has the expection to be able to read the backlog does not make much sense. However this is an artificial limitation and not a technical requirement.



Using PEP with a different access model

PubSub—and by inheritence PEP—supports five access models for a node. This document describes an algorithm for setting the access model of a PEP node savely and securely with minimal round trip times. Especially in a scenario where a node is supposed to be private, a publish first and configure access model later approach must be avoided as this could leak information in between those requests.

Publish with publish-options

Assuming we want to publish <content xmlns="com.example.dummy"/> to a node called com.example.dummy that should be available to everyone and not just our contacts.

Warning: We must ensure that the server annouces the namespace on the account jid. Otherwise we risk the server just ignoring the publish-options in the following request which would be especially dang

View blocking.xml
<iq to="" id="blockspam01" type="set">
<block xmlns='urn:xmpp:blocking'>
<item jid=""/>
<item jid=""/>
<item jid=""/>
<item jid=""/>
<item jid=""/>
<item jid=""/>
</block >

Getting started with OMEMO

This is a short tutorial on how to get started with OMEMO. This is not to replace the XEP but to extend it and give you some clear steps to follow instead of a having to read through a formal specification.


Until OMEMO becomes an official XEP all current implemenations use the namespace eu.siacs.conversations.axolotl instead of urn:xmpp:omemo:0. Sub-namespaces are seperated by a . instead of a :. The device id however is sperated by :. So the namespace for a PEP device bundle for example will look like this: eu.siacs.conversations.axolotl.bundles:1234. You might want to define some constants in your code to have a central place to configure them later. Compare that to how Conversations does this.

The official XEP will also be based on Olm instead of Axolotl which means

View invite.php
$url_parts = preg_split('/@|\//',$_SERVER["REQUEST_URI"]);
if (count($url_parts) < 4 || empty($url_parts[3])) {
} else {
$localpart = strtolower(urldecode($url_parts[2]));
$domainpart = strtolower(urldecode($url_parts[3]));
$jid = $localpart.'@'.$domainpart;
$muc = $url_parts[1] === 'j';

Title: Settling the IM war

Subtitle: Creating an open and federated protocol for instant messaging

Abstract: The world of Instant Messaging is populated with hundreds of providers - all incompatible with each other though history has shown that walled gardens are not sustainable. Why are we unable to agree upon a standard to communicate with each other?

Description: Imagine you would need a separate web browser for every website you visit. Want to shop on Amazon? Download the Amazon browser. Want to surf Reddit? Download the Reddit browser. What seems completely ridiculous in the context of the World Wide Web is a sad reality for instant messaging. The recent years have spawned a sheer number of incompatible instant messaging solutions and forced the user to have multiple accounts with different providers that all do pretty much the same thing. Slack for work, Skype for your parents and Whatsapp for your friends. Wouldn't it be great if they were some kind of standard that would make all th