iNPUTmice

<message to="romeo@montague.tld" from="juilet@whateverthenamewas.tld">
  <encryption xmlns="eu.siacs.conversations.axolotl">
    <header sid="42"> <!-- can be reused -->
      <key rid="345"></key>
      <key rid="23"></key>
      <iv>04af38cd4d</iv>
    </header>
    <payload>cipher text</payload>
  </encryption>
</message>

iNPUTmice

#!/bin/zsh
set -e
XML="$1"
BASE=${1%.xml}
xsltproc --path . xep.xsl "$1" > "$BASE".html;

iNPUTmice

# HG changeset patch
# User Daniel Gultsch <daniel@gultsch.de>
# Date 1455361701 -3600
#      Sat Feb 13 12:08:21 2016 +0100
# Node ID 980e5f5bd62ccfcc127cc0928011e10c58709e2e
# Parent  0aa8aa6cdb1b06045dd5e40f38874af8306ed6d7
mod_cloud_notify: put publish-options into <pubsub> not into <publish>

diff -r 0aa8aa6cdb1b -r 980e5f5bd62c mod_cloud_notify/mod_cloud_notify.lua
--- a/mod_cloud_notify/mod_cloud_notify.lua	Fri Feb 05 11:37:47 2016 +0100

iNPUTmice

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

iNPUTmice

#!/bin/bash
URL=$1
BROWSER=firefox
JAVA=/usr/lib/jvm/java-8-openjdk/bin/java
IMAGE_DOWNLOADER=/home/daniel/Projects/ImageDownloader/t
if [ ${URL: -97:1} == "#" ]; then
	$JAVA -jar $IMAGE_DOWNLOADER $URL | feh -. -
else
   $BROWSER $URL

iNPUTmice

<iq to="you@conversations.im" id="blockspam01" type="set">
  <block xmlns='urn:xmpp:blocking'>
    <item jid="kdetalk.net"/>
    <item jid="swissjabber.li"/>
    <item jid="swissjabber.eu"/>
    <item jid="swissjabber.ch"/>
    <item jid="swissjabber.org"/>
    <item jid="swissjabber.de"/>
  </block >
</iq>

iNPUTmice

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 http://jabber.org/protocol/pubsub#publish-options on the account jid. Otherwise we risk the server just ignoring the publish-options in the following request which would be especially dang

iNPUTmice

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).

General

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.

Sidenote:

iNPUTmice

Section "InputClass"
	Identifier "system-keyboard"
	MatchIsKeyboard "on"
	Option      "XkbModel" "pc105"
	Option      "XkbLayout" "de"
	Option      "XkbVariant" "neo"
EndSection

iNPUTmice

#!/bin/sh
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk/
export ANDROID_HOME=/opt/android-sdk
BUILD_DIRECTORY="lttrs-android-build"
git clone https://github.com/iNPUTmice/lttrs-android.git
mkdir $BUILD_DIRECTORY
disorderfs --sort-dirents=yes --reverse-dirents=no lttrs-android $BUILD_DIRECTORY
cd $BUILD_DIRECTORY
./gradlew assembleRelease
sha256sum app/build/outputs/apk/release/Ltt.rs-0.1.0-release-unsigned.apk