Yes We're Config!™
      How to build a Low-Tech website: Software & Hardware

      Earlier this year we’ve been asked to help redesign the website of lowtechmagazine.com. The primary goal of the redesign was to radically reduce the energy use associated with accesing their web content. At the same time it is an attempt to find out what a low-tech website could be.

      In general the idea behind lowtechmagazine.com is to understand technologies and techniques of the past and combine them with the knowledge of today. Not in order to be able to ‘do more with the same’, but rather ‘to do the same with less’.

      In this particular case it means that all the optimizations and increases in efficiency do not go towards making a website which is faster at delivering even more megabytes. Rather it is a website which uses all the advances in technological efficiency, combined with specific hardware and software choices, to radically and drastically cut resource usage. At the same time for us a sustainable web site means ensuring support for older hardware, slower networks and improving the portability and archivability of the blog’s content.

      This meant making a website and server which could be hosted from the off-grid solar system used in the lowtechmagazine.com’s home-office in Barcelona.

      The article ‘How To Build A Low-Tech Website?’ gives more insights into the motivations on making a self-hosted solar-powered server, while this companion article on will give in-depth technical information.

      Both the articles and the readesign should be read as a proposition how things could be done, but also as a question on what could be improved. So we really appreciate additional insights and feedback.

      Software

      Operating system

      The webserver is running on Armbian Stretch, which is a Debian based distribution built around the SUNXI kernel. This is kernel for low-powered AllWinner-based single board computers. The Armbian project provides good documentation on how write an Armbian image to an SD card an boot the board for the first time in the Armbian User Guide.

      Pelican Static Site & Design

      The main change in the webdesign was to move from a dynamic website based on Typepad1 to a static site generated by Pelican. Static sites load faster and require less processing than dynamic websites. This is because the pages are pre-generated and read off the disk, rather than being generated on every visit.2

      You can find the source code for ‘solar’, the Pelican theme we developed here

      Image compression

      One of the main challenges was to reduce the overall size of the website. Particularly to try and reduce the size of each page to something less than 1MB . Since a large part of both the appeal and the weight of the magazine comes from the fact it is richly illustrated, this presented us with a particular challenge.

      Image from the blog showing 19th century telephone switchboard operators, 159.5KB

      Image from the blog showing 20th century telephone switchboard operators(original source), 159.5KB

      In order to reduce the size of the images, without diminishing their role in the design and the blog itself, we reverted to a technique called dithering:

      The same image but dithered with a 3 color palette

      The same image but dithered with a 3 color palette, 36.5KB

      This is a technique ‘to create the illusion of “color depth” in images with a limited color palette’3. It based on the print reproduction technique called halftoning. Dithering, or digital half-toning4, was widely used in video games and pixel art at a time when a limited amount of video memory constrained the available colors. In essence dithering relies on optical illusions to simulate more colors. These optical illusions are broken however by the distinct and visible patterns that the dithering algorithms generate.

      Dithered with a six tone palette

      Dithered with a six tone palette, 76KB

      As a consequence most of the effort and literature on dithering is around limiting the ‘banding’ or visual artifacts by employing increasingly complex dithering algorithms5.

      Our design instead celebrates the visible patterns introduced by the technique, this to stress the fact that it is a ‘different’ website. Coincidentally, the ‘Bayesian Ordered Dithering’ algorithm that we use not only introduces these distinct visible patterns, but it is also quite a simple and fast algorithm.

      Dithered with an eleven tone color palette

      Dithered with an eleven tone palette, 110KB

      We chose dithering not only for the compression but also for the aesthetic and reading experience. Converting the images to grayscale and then dithering them allows us to scale them in a visually attractive way to 100% of the view port, despite their small sizes. This gives each article a visual consistency and provides the reader with pauses in the long articles.

      To automatically dither the images on the blog we wrote a plugin for pelican that converts all source images of the blog. The plugin is based on the Python Pillow imaging library and hitherdither, a dithering palette library by Henrik Blidh.

      Using this custom plug-in we reduced the total weight of the 623 images that are on the blog so far by 89%. From 194.2MB to a mere 21.3MB.

      Archiving and portability

      Another reason to switch to a static site generator was to be able to ensure an off-line workflow, where the articles can be written and previewed locally in the browser. For this to happen the articles had to be converted to Markdown, a light weight markup language based on plain text files.

      While this is quite a bit of work to do with an archive that spans 10 years of writing, it ensures the portability of the archive for future redesigns or other projects. It also makes it possible for us to archive and version the entire blog using the git versioning system.

      Off-line archive

      Because we designed the system to have an uptime of only 90% it is expected to go off-line 35 days a year.

      Increasing the uptime of the server to 99% on solar energy means increasing the website’s ecological footprint by adding more and more tech in the form of extra solar panels, massively increased battery capacity or extra servers in different geographic locations.

      Rather than that we opted for a low-tech approach that accepts being off-line during longer stretches of cloudy weather. However, we wanted to provide the reader with off-line reading options. Our primary method of doing so currently is by providing an RSS feed containing all the articles and images on the site. In the future we will explore other means of providing off-line reading of the magazine.

      An image of the built-in feed reader of Firefox showing solar.lowtechmagazine.com's RSS feed

      Most browsers preview only the article titles and summaries of the RSS feed. In fact the feed contains the full articles. Once you add the feed to your favorite reader, it will download the full articles that you can read at any given time.

      Material Server

      ”[…] the minimal file-based website is contrary to a cloud mentality, where the material circumstances of the hardware and hosting location are made irrelevant (for the cloud/vps customer) meaning that any ‘service’ can be ‘deployed’, ‘scaled’ ‘migrated’ etc. Our approach instead informs what can be hosted based on the material circumstances of the server.”6

      One of the page’s fundamental design elements is to stress the materiality of the webserver. In web design there is a clear distinction between ‘front-end’, the visual and content side of the website and the ‘back-end’, the infrastructure it runs on top. Outside of professional circles, the material conditions of the web or the internet’s infrastructure are rarely discussed. This has become especially the case with cloud computing as the dominant paradigm, as resources are taken for granted or even completely virtualised.

      A low-tech website means this distinction between front-end and back-end needs to disappear as choices on the front-end necessarily impact what happens on the back-end and vice-versa. Ignoring this connection usually leads to more energy usage.

      An increase in traffic for example will have an impact on the amount of energy the server uses, just as a heavy or badly designed website will. Part of solar.lowtechmagazine.com‘s design aims to give the visitor an insight in the amount of power consumed and the potential (un)availability of the page in the coming days, based on current power usage and forecasts of the weather.

      The power statistics can actually be queried from the server hardware. More on that below. To make the statistics available to the web site we wrote a bash script that exposes them as JSON in the webroot.

      To activate this feature there is a cron entry that runs the script every minute and writes it into the web directory:

      */1 * * * * /bin/bash /home/user/stats.sh > /var/www/html/api/stats.json
      

      Configuring the webserver

      As a webserver we use NGINX to serve our static files. However we made a few non-standard choices to further reduce the energy consumption and page loading times on (recurrent) visits.

      To test some of the assumed optimizations we’ve done some measurements using a few different articles. We’ve used the following pages:

      FP = Front page, 404.68KB, 9 images

      WE = How To Run The Economy On The Weather, 1.31 MB, 21 images

      HS = Heat Storage Hypocausts, 748.98KB, 11 images

      FW = Fruit Walls: Urban Farming in the 1600s, 1.61MB, 19 images

      CW = How To Downsize A Transport Network: Chinese Wheelbarrows, 996.8KB, 23 images

      For this test the pages which are hosted in Barcelona have been loaded from a machine in the Netherlands. The indicated times are all the averages of 3 measurements.

      Compression of transmitted data

      We run gzip compression on all our text-based content, this lowers the size of transmitted information at the cost of a slight increase in required processing. By now this is common practice in most web servers but we enable it explicitly. Reducing the amount of data transferred will also reduce the total environmental footprint.

      #Compression
      gzip on;
      gzip_disable "msie6";
      gzip_vary on;
      gzip_comp_level 6;
      gzip_buffers 16 8k;
      gzip_http_version 1.1;
      gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
      

      A comparison of the amount of data sent with gzip compression enabled or disabled:

      |GZIP      | MP       | WE       | HS       | FW       | CW       |
      |----------|----------|----------|----------|----------|----------|
      | disabled | 116.54KB | 146.08KB | 127.09KB | 125.36KB | 138.28KB |
      | enabled  | 39.6KB   | 51.24KB  | 45.24KB  | 45.77KB  | 50.04KB  |
      | savings  | 64%      | 65%      | 66%      | 66%      | 64%      |
      

      Caching of static resources

      Caching is a technique in which some of the site’s resources, such as style sheets and images, are provided with additional headers that tell the visitor’s browser to save a local copy of those files. This ensures that the next time they visit the same page, the files are loaded from the local cache rather than being transmitted over the network again. This not only reduces the time to load the entire page, but also lowers resource usage both on the network and on our server.

      The common practice is to cache everything except the HTML, so that when the user loads the web page again the HTML will notify the browser of all the changes. However since lowtechmagezine.com publishes only 12 articles per year, we decided to also cache HTML. The cache is set for one day, meaning it is only after a week that the user’s browser will automatically check for new content. Only for the front and about pages this behaviour is disabled.

      map $sent_http_content_type $expires {
          default                    off;
          text/html                  1d;
          text/css                   max;
          application/javascript     max;
          ~image/                    max;
      }
      

      Concretely this had the following effects:

      The first time a page is loaded (FL) it around one second to fully load the page. The second time, however, the file is loaded from the cache and the load time reduced by 40% on average. Since load time are based on the time it takes to load resources over the network and the time it takes for the browser to render all the styling, caching can really decrease load times.

      | Time(ms) | FP    | WE     | HS    | FW     | CW     |
      |----------|-------|--------|-------|--------|--------|
      | FL       | 995ms | 1058ms | 956ms | 1566ms | 1131ms |
      | SL       | 660ms |  628ms | 625ms |  788ms |  675ms |
      | savings  |  34%  |   41%  |  35%  |   50%  |   40%  |
      

      In terms of data transferred the change is even more radical, essentially meaning that no data is transferred the second time a page is visited.

      | KBs      | FP       | WE        | HS       | FW        | CW       |
      |----------|----------|-----------|----------|-----------|----------|
      | FL       | 455.86KB | 1240.00KB | 690.48KB | 1610.00KB | 996.21KB |
      | SL       |   0.38KB |    0.37KB |   0.37KB |    0.37KB |   0.38KB |
      | savings  |   >99%   |   >99%    |   >99%   |    >99%   |   >99%   |
      

      In case you want to force the browser to load cached resources over the network again, do a ‘hard refresh’ by pressing ctrl+r

      HTTP2, a more efficient hyper text transfer protocol.

      Another optimization is the use of HTTP2 over HTTP/1.1. This is a relatively recent protocol that increases the transport speed of the data. This increase is the result of HTTP2 compressing the packet data headers and multiplexing multiple requests into a single TCP connection. In other words, it produces less overhead data and needs to opens less connections between the server and the browser.

      The effect of this is most notable when the browser needs to do a lot of different requests, since these can all be fit into a single connection. In our case that specifically means that articles with more images will load slightly faster over HTTP2 than over HTTP/1.1.

      |          | FP    | WE    | HS    | FW    | CW    |
      |----------|-------|-------|-------|-------|-------|
      | HTTP/1.1 | 1.46s | 1.87s | 1.54s | 1.86s | 1.89s |
      | HTTP2    | 1.30s | 1.49s | 1.54s | 1.79s | 1.55s |
      | Images   |   9   |   21  |   11  |   19  |   23  |
      | savings  |  11%  |  21%  |   0%  |   4%  |  18%  |
      

      Not all browsers support HTTP2 but the NGINX implementation will automatically serve the files over HTTP/1.1 for those browsers.

      It is enabled at the start of the server directive:

      server{
              listen 443 ssl http2;
      }
      

      Serve the page over HTTPS

      Even though the website has no dynamic functionality like login forms, we have also implemented SSL to provide Transport Layer Security. We do this mostly to improve page rankings in search engines.

      There is something to be said in favour of supporting both HTTP and HTTPS versions of the website but in our case that would mean more redirects or maintaining two versions of the website.

      For this reason we redirect all our traffic to HTTPS via the following server directive:

      server {
          listen       80;
          server_name  solar.lowtechmagazine.com;
      
          location / {
          return 301 https://$server_name$request_uri;
          }
      }
      

      Then we’ve set up SSL with the following tweaks:

      # Improve HTTPS performance with session resumption
      ssl_session_cache shared:SSL:10m;
      ssl_session_timeout 180m;
      

      SSL sessions only expire after three hours meaning that while someone browses the website, they don’t need to renegotiate a new SSL session during this period:

      # Enable server-side protection against BEAST attacks
      ssl_prefer_server_ciphers on;
      ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5;
      

      We use a limited set of modern cryptographic ciphers and protocols:

      # Disable SSLv3
      ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
      

      We tell the visitors browser to always use HTTPS, in order to reduce the amount of 301 redirects, which might slow down loading times:

      # Enable HSTS (https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security)
      add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
      

      We enable OCSP stapling which is quick way in which browsers can check whether the certificate is still active without incurring more round trips to the Certificate Issuer. Most tutorials recommend setting Google’s 8.8.8.8 and 8.8.4.4 DNS servers but we don’t want to use those. Instead we chose some servers provided through https://www.opennic.org that are close to our location:

      # Enable OCSP stapling (http://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox)
      ssl_stapling on;
      ssl_stapling_verify on;
      ssl_trusted_certificate /etc/letsencrypt/live/solar.lowtechmagazine.com/fullchain.pem;
      resolver 87.98.175.85 193.183.98.66 valid=300s;
      resolver_timeout 5s;
      

      Last but not least, we set change the size of the SSL buffer to increase to so-called ‘Time To First Byte’7 which shortens the amount of time between passing between a click and elements changing on the screen:

      # Lower the buffer size to increase TTFB
      ssl_buffer_size 4k;
      

      The above SSL tweaks are heavily indebted to these two articles by Bjorn Johansen and Hayden James

      Setting up LetsEncrypt for HTTPS

      The above are all the SSL performance tweaks but we still need to get our SSL certificates. We’ll do so using LetsEncrypt.

      First install certbot:

      apt-get install certbot -t stretch-backports
      

      Then run the command to request a certificate using the webroot authenticator:

      sudo certbot certonly --authenticator webroot --pre-hook "nginx -s stop" --post-hook "nginx"
      

      Use the certonly directive so it just creates the certificates but doesn’t touch much config.

      This will prompt an interactive screen where you set the (sub)domain(s) you’re requesting certificates for. In our case that was solar.lowtechmagazine.com.

      Then it will ask for the location of the webroot, which in our case is /var/www/html/. It will then proceed to generate a certificate.

      Then the only thing you need to do in your NGINX config is to specify where your certificates are located. This is usually in /etc/letsencrypt/live/domain.name/. In our case it is the following:

      ssl_certificate /etc/letsencrypt/live/solar.lowtechmagazine.com/fullchain.pem;
      ssl_certificate_key /etc/letsencrypt/live/solar.lowtechmagazine.com/privkey.pem;
      

      Full NGINX config

      Without further ado:

      root@solarserver:/var/log/nginx# cat /etc/nginx/sites-enabled/solar.lowtechmagazine.com
      
      # Expires map
      map $sent_http_content_type $expires {
          default                    off;
          text/html                  7d;
          text/css                   max;
          application/javascript     max;
          ~image/                    max;
      }
      
      server {
          listen       80;
          server_name  solar.lowtechmagazine.com;
      
          location / {
          return 301 https://$server_name$request_uri;
          }
      }
      
      server{
              listen 443 ssl http2;
              server_name solar.lowtechmagazine.com;
      
              charset UTF-8; #improve page speed by sending the charset with the first response.
      
              location / {
              root /var/www/html/;
              index index.html;
              autoindex off;
              }
      
      
              #Caching (save html pages for 7 days, rest as long as possible, no caching on frontpage)
              expires $expires;
      
              location @index {
                  add_header Last-Modified $date_gmt;
                  add_header Cache-Control 'no-cache, no-store';
                  etag off;
                  expires off;
              }
      
              #error_page  404              /404.html;
      
              # redirect server error pages to the static page /50x.html
              #error_page   500 502 503 504  /50x.html;
              #location = /50x.html {
              #    root   /var/www/;
              #}
      
              #Compression
      
              gzip on;
              gzip_disable "msie6";
              gzip_vary on;
              gzip_comp_level 6;
              gzip_buffers 16 8k;
              gzip_http_version 1.1;
              gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
      
      
              #Caching (save html page for 7 days, rest as long as possible)
              expires $expires;
      
              # Logs  
              access_log   /var/log/nginx/solar.lowtechmagazine.com_ssl.access.log;
              error_log    /var/log/nginx/solar.lowtechmagazine.com_ssl.error.log;
      
              # SSL Settings:
              ssl_certificate /etc/letsencrypt/live/solar.lowtechmagazine.com/fullchain.pem;
              ssl_certificate_key /etc/letsencrypt/live/solar.lowtechmagazine.com/privkey.pem;
      
              # Improve HTTPS performance with session resumption
              ssl_session_cache shared:SSL:10m;
              ssl_session_timeout 5m;
      
              # Enable server-side protection against BEAST attacks
              ssl_prefer_server_ciphers on;
              ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5;
      
              # Disable SSLv3
              ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
      
              # Lower the buffer size to increase TTFB
              ssl_buffer_size 4k;
      
              # Diffie-Hellman parameter for DHE ciphersuites
              # $ sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 4096
              ssl_dhparam /etc/ssl/certs/dhparam.pem;
      
              # Enable HSTS (https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security)
              add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
      
              # Enable OCSP stapling (http://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox)
              ssl_stapling on;
              ssl_stapling_verify on;
              ssl_trusted_certificate /etc/letsencrypt/live/solar.lowtechmagazine.com/fullchain.pem;
              resolver 87.98.175.85 193.183.98.66 valid=300s;
              resolver_timeout 5s;
      }
      

      Hardware

      Image of an A20 Olimex SoC board

      Server

      The server itself is an Olimex Olinuxino A20 Lime 2 single board computer.

      We chose it because of the quality of the (open source) hardware8, the low power consumption and useful extra components such as the charging circuit based on the AXP209 power managment chip.

      This chip makes it possible to query power statistics such as current voltage and amperage both from the DC-barrel jack connection and the battery. The maintainers of Armbian exposed these statistics via sysfs bindings in their OS.

      In addition to the power statistics the power chip can charge and discharge a Lithium Polimer battery and automatically switch between the battery and DC-barrel connector. This means the battery can then act as an uninterruptible power supply, which helps prevent sudden shutdowns. The LiPo battery used has a capacity of 6600mAh which is about 24 Watt hour.

      The server operating system all runs on an SD-card. Not only are these low-powered but also much faster than hard drives. We use high speed Class 10 16GB mirco-sd card. A 16GB card is actually a bit of an overkill considering the operating system is around 1GB and the website a mere 30MB, but considering the price it doesn’t make sense to buy any smaller high-performance cards.

      Network

      The server gets it’s internet access through the existing connection of the home office in Barcelona. This connection is a 100mbit consumer fiber connection with a static IP-adress.

      The fiber connection itself is not necessary, especially if you keep your data footprint small, but a fixed IP adress is very handy.

      The router is a standard consumer router that came with the internet contract. To make the website available, some settings in the router’s firewall had to be changed.

      Using a process called ‘port forwarding’, the following ports had to be forwarded between the external network and the server’s local IP address:

      Port 80 to 80 for HTTP
      Port 443 to 443 for HTTPS
      Port 22 to 22 for SSH
      

      Room for improvements?

      OS Optimization

      While the Armbian operating system has all kinds of optimizations for running on a SoC, there probably are still many tweaks that can be made to lower the energy usage.

      For example energy savings from disabling some of the hardware such as the the USB-hub? Some tips or insights into this are greatly appreciated!

      Image dithering

      We’re looking for suggestions how to further compress the images while maintaining this visual quality. We know PNGs are in theory not optimal for representing images on the web, even though they let us limit the color palette to save bandwidth and produce very crisp dithered images.

      We’ve found that saving them as JPEG after dithering in fact increases the file size but perhaps other file formats exist that give is similar quality but have a lighter footprint.

      Sensible comments on static sites

      Dynamic content such as comments are in theory incompatible with a static site.

      At the same time they are a big part of the community of knowledge around lowtechmagazine.com.

      The comment box under each article on that site is widely used, but e-mail is equally used (often the comments are then added to the article by the author after moderating).

      There are some plugins that might address this such as Bernhard Scheirle’s ‘Pelican Comment System’ but these we haven’t tested.

      SSL & Legacy browsers

      An open question remains: In what a way would it be possible to further extend the support for older machines and browsers without comprimising on security by using deprecated ciphers? Should we maintain both HTTP and HTTPS versions of the site?

      Donations

      As is mentioned on the ‘donate’ page of the site, advertising trackers are incompatible with the new web site design and we really want to keep Low-Tech Magazine tracker free and sustainable so if you enjoy our work or find our public research useful please consider donating.

      Get in touch

      Perhaps you have other issues you’d like to address or get in touch about. You can do so via:


      1. http://www.typepad.com/ 

      2. The advantages of the static website became apparent when on the 26th and 27th of september 2018, the site was on the front page of the popular link aggregator website HackerNews. In a few hours we received more than 500,000 hits but the website and server handled it all fine, never exceeding above 30% CPU utilization. 

      3. https://en.wikipedia.org/wiki/Dither#Digital_photography_and_image_processing 

      4. http://www.efg2.com/Lab/Library/ImageProcessing/DHALF.TXT 

      5. See for example https://web.archive.org/web/20180325055007/https://bisqwit.iki.fi/story/howto/dither/jy/ 

      6. Quote from ‘What a website can be’ 

      7. https://en.wikipedia.org/wiki/Time_to_first_byte 

      8. For a full description of the board have a look at the manual 

      Configuring an XMPP server for secure, mobile instant messaging

      This is a guide to set up a modern XMPP server focused on security and mobile messaging. The whole guide assumes Debian stable running on the server, the fact that you will end up hosting a few of your friends and that you have some basic skills working on a linux command line.

      To make your server communicate make sure following ports are open in your firewall:

      5222 (for client to server)
      5269 (server to server)
      5280 (default http port for prosody)
      5281 (default https port for prosody)
      

      Enabling HTTPS

      First we acquire a signed HTTPS-certificate via Let’s Encrypt: This is among others required for Gajim plugins to work properly; self-generated certs will not work.

      Install Certbot and get new certificates for your domain (replace myserver.org with your own):

      sudo apt-get update && sudo apt-get install certbot
      certbot certonly -d muc.myserver.org -d dump.myserver.org -d myserver.org
      

      Should you succeed, you will be able to read something like:

      Congratulations! Your certificate and chain have been saved at
      /etc/letsencrypt/live/myserver.org/fullchain.pem. Your cert will           
      expire on 2018-01-13. To obtain a new or tweaked version of this       
      certificate in the future, simply run certbot-auto again. To                       
      non-interactively renew *all* of your certificates, run                               
      "certbot-auto renew"
      

      Take note of the path where the certificate is stored as we will use it later.

      Installing and setting up MySQL as a storage back-end

      First update your repositories and install MySQL

      apt-get update && apt-get install mysql-server
      

      Run mysql as the root user:

      mysql -u root -p
      

      In mysql:

      mysql> create database prosody;
      mysql> show databases;
      

      Result should be something like:

      +--------------------+
      | Database           |
      +--------------------+
      | information_schema |
      | mysql              |
      | performance_schema |
      | prosody            |
      +--------------------+
      
      4 rows in set (0.00 sec)
      

      Create a database account for prosody

      mysql> create user prosody;
      

      Give the user prosody the rights to access the database, make sure to change the password and take note of it

      mysql> grant all on prosody.* to 'prosody'@'localhost' identified by 'userPassword';
      

      Exit mysql:

      exit;
      

      Installing and configuring Prosody, the XMPP server

      Install the newest version of Prosody and its dependencies from the official prosody repository:

      echo deb http://packages.prosody.im/debian $(lsb_release -sc) main | sudo tee -a /etc/apt/sources.list
      
      wget https://prosody.im/files/prosody-debian-packages.key -O- | sudo apt-key add -
      
      sudo apt get update && apt-get install prosody lua-dbi-mysql lua-zlib lua-sec
      

      Add the Let’s Encrypt Certificates to Prosody and make sure Prosody can use them

      cp /etc/letsencrypt/live/myserver.org/*.pem /etc/prosody/certs/
      

      Make sure the certificates are owned by prosody and legible only by root:

      chown -R prosody:prosody /etc/prosody/
      chmod -R 700 /etc/prosody/certs/
      

      Install the newest prosody plugins:

      apt-get install mercurial
      cd /usr/src
      hg clone https://hg.prosody.im/prosody-modules/ prosody-modules
      

      Make a backup of the default prosody configuration and install the one by the homebrewserver.club

      cd /etc/prosody
      cp prosody.cfg.lua prosody.cfg.lua.original
      wget https://homebrewserver.club/downloads/prosody.cfg.lua
      

      The homebrewserver.club prosody config:

      -- a custom prosody config focused on high security and ease of use across (mobile) clients
      -- provided to you by the homebrewserver.club
      -- the original config file (prosody.cfg.lua.original) will have more information
      
      plugin_paths = { "/usr/src/prosody-modules" } -- non-standard plugin path so we can keep them up to date with mercurial
      
      modules_enabled = {
                      "roster"; -- Allow users to have a roster. Recommended ;)
                      "saslauth"; -- Authentication for clients and servers. Recommended if you want to log in.
                      "tls"; -- Add support for secure TLS on c2s/s2s connections
                      "dialback"; -- s2s dialback support
                      "disco"; -- Service discovery
                      "posix"; -- POSIX functionality, sends server to background, enables syslog, etc.
                      "private"; -- Private XML storage (for room bookmarks, etc.)
                      "vcard"; -- Allow users to set vCards
                      "version"; -- Replies to server version requests
                      "uptime"; -- Report how long server has been running
                      "time"; -- Let others know the time here on this server
                      "ping"; -- Replies to XMPP pings with pongs
                      "register"; --Allows clients to register an account on your server
                      "pep"; -- Enables users to publish their mood, activity, playing music and more
                     "carbons"; -- XEP-0280: Message Carbons, synchronize messages accross devices
                      "smacks"; -- XEP-0198: Stream Management, keep chatting even when the network drops for a few seconds
                      "mam"; -- XEP-0313: Message Archive Management, allows to retrieve chat history from server
                      "csi"; -- XEP-0352: Client State Indication
                      "http"; -- mod_http needed for XEP-363
                      "admin_adhoc"; -- Allows administration via an XMPP client that supports ad-hoc commands
                      "blocklist"; -- XEP-0191  blocking of users
                      --"cloud_notify"; -- Support for XEP-0357 Push Notifications for compatibility with ChatSecure/iOS. 
                      -- iOS typically end the connection when an app runs in the background and requires use of Apple's Push servers to wake up and receive a message. Enabling this module allows your server to do that for your contacts on iOS.
                      -- However we leave it commented out as it is another example of vertically integrated cloud platforms at odds with federation, with all the meta-data-based surveillance consequences that that might have. 
                      "omemo_all_access"; -- Allow for OMEMO E2E between contacts that haven't added each other
                      "pep_vcard_avatar"; -- use XEP-0153: vCard-Based Avatars to see the avatars of clients that use XEP-0084: User Avatar and vice versa.
      
      };
      
      allow_registration = false; -- Enable to allow people to register accounts on your server from their clients, for more information see http://prosody.im/doc/creating_accounts
      
      -- These are the SSL/TLS-related settings. 
      ssl = {
              certificate = "/etc/prosody/certs/fullchain.pem";
              key = "/etc/prosody/certs/privkey.pem";
      }
      
      c2s_require_encryption = true -- Force clients to use encrypted connections
      
      -- Force certificate authentication for server-to-server connections?
      -- This provides ideal security, but requires servers you communicate
      -- with to support encryption AND present valid, trusted certificates.
      -- NOTE: Your version of LuaSec must support certificate verification!
      -- For more information see http://prosody.im/doc/s2s#security
      
      s2s_secure_auth = false
      
      pidfile = "/var/run/prosody/prosody.pid"
      
      authentication = "internal_hashed"
      
      storage = "sql"
      
      -- Make sure to change the password 
      sql = { driver = "MySQL", database = "prosody", username = "prosody", password = "userPassword", host = "localhost" }
      
      log = {
              info = "/var/log/prosody/prosody.log"; -- Change 'info' to 'debug' for verbose logging
              error = "/var/log/prosody/prosody.err";
              "*syslog";
      }
      
      VirtualHost "myserver.org"
      
      -- Enable http_upload to allow image sharing across multiple devices and clients
      Component "dump.myserver.org" "http_upload"
      
      ---Set up a MUC (multi-user chat) room server on conference.example.com:
      Component "muc.myserver.org" "muc"
      

      Replace all instances of the placeholder domain name and passwords in the config file with your own:

      sed -i 's/myserver.org/yourdomain.net/g' prosody.cfg.lua  && sed -i 's/userPassword/yourownpassword/g' prosody.cfg.lua
      

      Alternatively you can change them by hand. They are on line 62, 70, 73, 76 of prosody.cfg.lua

      Finishing up

      After you’ve set up all of the above it is time to start the server:

      /etc/init.d/prosody restart
      

      Users can be added from the command line, you will also be prompted for a password:

      prosodyctl adduser me@myserver.org
      

      Alternatively you can change “allow_registration = false;” to “allow_registration = true;” in the config (line 35) to allow users to register accounts on your server via their clients.

      Now you can try connecting to your own server by using a client like Gajim or Conversations. Login with the above configured username and password.

      If you have questions about Prosody, the project’s documentation is quite good. If you can’t find answers there, try contacting prosody developers and users directly via the Prosody XMPP chatroom

      This guide is a companion to our article Have You Considered The Alternative? on instant messaging. Also check out our guide on XMPP clients.

      edit 9th of january 2018 updated config for new debian stable and prosody 0.10

      Have you considered the alternative?

      “Remember, when advertising is involved you the user are the product. […] When people ask us why we charge for WhatsApp, we say ‘Have you considered the alternative?’”

      Brian Acton and Jan Koum, June 20121

      “Facebook today announced that it has reached a definitive agreement to acquire WhatsApp, a rapidly growing cross-platform mobile messaging company, for a total of approximately $16 billion, including $4 billion in cash and approximately $12 billion worth of Facebook shares.”

      Facebook Newsroom, February 20142

      “[B]y coordinating more with Facebook, we’ll be able to do things like track basic metrics about how often people use our services and better fight spam on WhatsApp. And by connecting your phone number with Facebook’s systems, Facebook can offer better friend suggestions and show you more relevant ads if you have an account with them.”

      Brian Acton and Jan Koum, August 20163

      Pattern Recognition

      WhatsApp started out full of dreams: “we want WhatsApp to be the product that keeps you awake…and that you reach for in the morning. No one jumps up from a nap and runs to see an advertisement”4. When they thought of WhatsApp, Brian Acton and Jan Koum were very keen on not selling our user data for targeted advertisement purposes. So they charged a nominal rate for the use of their service, rightfully pointing out the hidden cost of using free services.

      In the year of 2014 however, WhatsApp was bought by Facebook, thus joining the social network’s happy and expanding family of venture capital investments, a family including Instagram, purchased in April 2012, and Oculus VR, purchased the month before. At the time, many, and with good reason, worried about the changes this acquisition could entail for WhatsApp. Eventually, in August 2016, WhatsApp users everywhere learned about what was in fact unavoidable. The company that built its reputation upon an ad-free ethic, would now be sharing private user information with Facebook, its parent company. So we, the users, are the product after all, and as expected, this is presented in the form of an improvement of the user experience. Thanks to the tighter coordination between WhatsApp and Facebook, we can now more easily find our friends or see more valuable messages from the companies that truly matter to us. Of course, small footnote, these ‘benefits’ comes at the price of sharing our phone number and other private data with Facebook—though, trusting their word, not the content of the messages themselves.

      Facebook does this for the simple reason that it needs to increase its market share on mobile devices5; the family of Whatsapp, Facebook and Instagram are all different channels leading to this same purpose. One of the consequences of this is that while Facebook’s chat function can still be used on their mobile website, plans are that we will soon be forced to install Facebook Messenger should we wish to continue using it on our mobile phones6. Once again, in a stroke of pure genius and creativity, this move is being marketed as a way to provide us with the best experience ever. And we can use it with just a phone number, we don’t even need a Facebook account. That way, their user base expands along with their profits.

      Every time there is a breach of user trust —read: a change in the Terms of Service— or news regarding network surveillance, people are on the lookout for an alternative, and rightfully so. In these moments there are many also willing to promote such alternatives, usually in the form of yet another disruptive app. After the purchase of Whatsapp, for example, Telegram was advertised as the alternative. After it became clear that Telegram had dreadful security, people promoted Viber. Then Snapchat, then Threema, then Allo and now Signal. There is a reason why we’re falling into this pattern of needing alternatives to the alternatives. And that is because…

      There are no alternatives.

      There’s a tendency to oversimplify the issues related to the use of these apps as merely a privacy matter, and not even that is sufficiently addressed. While each of the aforementioned apps are alternative companies and brands, what these alternatives all have in common is that they share the same model. A model that revolves around centralized services, vendor lock-in and marketing related surveillance, and all of that within a neoliberal context of the free market. These alternatives therefore promote themselves as more than just an alternative, but also as competing products, usually highlighting a particular feature lacking in rivals’ products. Remember that ill-fated, super cool, nice looking alternative to Facebook, Ello? It gained a lot of traction out of legitimate concerns with Facebook’s modus operandi, promoting itself as an alternative for its nice features and its promise not to use advertising. But as Aral Balkan was quick to point out, allowing investments by venture capital firms meant the project was dead before it really began7. Taking these investments, which allowed them to scale as a platform, also meant that they would, at some point, have to make a lot of money for their investors. How? By selling ad space or information about their users. The reason the pattern keeps repeating itself is not because the makers of these apps always secretly intended to sell your data while saying they wouldn’t. The reason is that they have no choice within the economic system they choose to operate in.

      Cryptography matters, but then it also doesn’t

      The latest competitive feature—one might even say, marketing trick—to make concerned users switch from one alternative to another is cryptography, the act of coding messages during communication. This strategy works well because the vast majority of people are not really informed when it comes down to the technicalities of cryptography, so this discourse mostly serves to throw bedazzling sparkles in our eyes. To be sure, cryptography is fundamental for privacy. However, the main privacy threat in the context of using these apps isn’t the potential of a government eavesdropping on our communications. The privacy threat is the wholesale and increasing dependence on centralized services which revolve around the surveillance and monetization of user information. In 2016, both WhatsApp and Facebook Messenger enabled end-to-end encryption? to address increasing privacy concerns. Adding crypto to a communication app in this case merely obfuscates a concern about the hegemony of these platforms. In essence, the issue of privacy is much larger than just the lack of cryptography; the conditions that threaten privacy are structural and economic and not resolved by a patch or a new feature.

      This issue is further stressed when looking at the question of metadata, that is to say, data about data, which in the case of communication applications is everything but the communication data itself. When WhatsApp started sharing, among other things, its users’ phone numbers with its parent company, Facebook, it went to great lengths to guarantee us that the content of our messages was still perfectly secure, impossible to be read by both WhatsApp and Facebook. The argument stating that “It’s only metadata, don’t worry” has been however debunked numerous times. Even though these platforms would love us to believe otherwise, metadata is neither a trivial disposable by-product, nor it is anonymous. And assuming that the crypto is sound and that the app running this crypto is not flawed, cross-referencing several databases containing metadata will always produce an array of very personal information, that in itself is much more valuable than encrypted naked selfies. Thus it should be no surprise that former NSA director Michael Hayden infamously said in 2012 “we kill based on metadata”8 and later argued in 2015 that metadata should be the main area of focus of surveillance activities, and not the creation of backdoors within crypto, or the banning of the latter9.

      In short, both Whatsapp and FacebookMessenger can afford to deploy end-to-end encryption for your messages because it won’t hurt their bottom line, which is making money based on the surveillance of your behavior and your social graph. Adding crypto thus merely patches your privacy worries, but not the threat to it.

      The Wrong Signal10

      The end-to-end encryption enabled in WhatsApp and Facebook Messenger has been developed by Open Whisper Systems, a non-profit run by crypto-celebrity Moxie Marlinspike. OWS also developed the algorithm for their own instant messaging application, Signal, and then open-sourced it. Signal itself is now the latest app being promoted as an alternative to WhatsApp and is hailed as the panacea of both security and usability. It even has the backing of members of the dissident elite such as Edward Snowden.

      While OWS provides thorough expertise in the field of cryptography, Marlinspike is currently advocating centralisation as the only answer towards user-friendly, fast and secure messaging apps. Decentralisation, according to him, has no place in the modern world and apparently hampers innovation. However, some of his arguments have not remained unchallenged. In particular, where Marlinspike accuses federation of stalling evolution11, Daniel Gultsch12 provides a counter argument by using the Web as an example of successfully federated system?. Furthermore, Gultsch states that the problem is not that federation doesn’t adapt, but rather that there are problems with its implementation for a very significant reason: software developers working on federated systems mostly work for free in their spare time or with little means, given the difficulty to monetise a system which design can only succeed if it is open and can be appropriated easily beyond its original scope, and thus making its capitalisation particularly challenging. In that sense, the most interesting aspect of this debate is that while Marlinspike seems to defend his product from a technological perspective, Gultsch’s counter argument moves back the discussion to the context of political economy.

      Daniel Gultsch is an important counter-voice because he is the main developer behind Conversations?. This open-source instant messaging app tries to be both accessible for new users as well as provide enough flexibility for more advanced users. In that regard, Conversations itself does not manage to escape the logic of competition and the discourse around alternative superior apps discussed previously. However, its approach is significantly different because unlike any other apps, Conversations is not a complete solution, nor does it present itself as such. It is a client that relies on federation, which means that it allows for people to chat with each other regardless of what provider they are using. In concrete terms, there is no central server directly connected to Conversations, but Conversations can connect to different chat servers. This is possible because Conversations is built upon a long-lived messaging protocol called XMPP?.

      XMPP, the federated messaging protocol

      Up to a few years ago XMPP and its implementations were lagging behind in terms of mobile features, usability and interface design13. That was the so-called lack of evolution Moxie pointed out. But recently Gultsch and the other contributors to Conversations have managed to bring XMPP up to speed with the functionality of well known mobile messenger applications. Not only did this demonstrate that bridging the gap could be done technically, but it also had the effect of breathing new life into the XMPP community. An example of this new energy was the initiative to create and implement OMEMO?, an XMPP Extension Protocol? that provides multi-user end-to-end encryption and which is based on Signal’s own encryption algorithm. Ever since a growing number of clients have started implementing OMEMO, including Gajim? for desktops and ChatSecure? for iPhones14.

      Gultsch succeeded15 so far precisely because of understanding the technical underpinnings of centralized services? such as WhatsApp or Signal. It is however a bitter-sweet victory, because as Gultsch articulated in his defense of decentralisation, the main difference between centralised and decentralised implementations is not only technical, but also a matter of economic sustainability. In other words, if his ongoing efforts show that it is possible to have a satisfying and safe user experience while using federated alternatives, this is only possible because, unlike any other XMPP client developers, he is in the position of working on this project full time. The problem has not been solved but shifted.

      If economically sustainable XMPP federation were to scale to the point of being as successful as the centralised solution offered by Signal, it would have to face the consequences of doing so in the context of a free market driven by competition. In that situation, each XMMP client’s economic viability would depend heavily on its capacity to capture enough users that can provide income for their developers. The problem therefore is not so much a problem of the technical or economical sustainability of federation, but more a problem of the economic sustainability of open standards and protocols in a world saturated with solutionist business models. After all, many years ago, Google and Facebook did provide XMPP support in their chat applications before deciding to close its interoperability.

      Approaches not Apps

      Given the different problems mapped in this text, it becomes difficult to blindly recommend Conversations as the superior alternative, that is to say, a near drop-in replacement to Signal or any other competing secure communication software. The reason is not technical but is linked to the fact that, as discussed earlier, Conversations’ own success relies on an economic model that is quite fragile, and the success of which—and it’s a paradox—could potentially undermine the cultural diversity of the XMPP ecosystem. With that said, there are however two essential points that the Conversations case brings up. These points are not always articulated clearly in discussions on federation: scale and trust.

      Rather than having to swap one app for the other in an attempt to mitigate a large and confusing privacy problem, the XMPP federation approach allows to collectively tackle the problem based on its various discrete parts. Such an approach, rather than suggesting a singular and proprietary solution, allows for the existence of different free and open source software servers which can be combined with different free and open source software clients. That makes it possible for you and a group of friends to run your own infrastructure, whether on a rented server or on a very small home server.

      The federated nature of the protocol allows you to try, play and experiment with different network infrastructures with different clients. These clients can range from custom XMMP bots to general instant messengers that you would be able recommend your friends and family to replace Whatsapp, without making a fool of yourself. As these open-source technologies continue to evolve you can make incremental changes to your server or switch clients as newer versions arrive.

      Hosting your own infrastructure allows you to scale your communication in a way that is the most meaningful for the group or community you belong to. It is also a way to make sure your system matches your own threat model?, while simultaneously allowing you to deal with trust that is not mediated by an app. It also allows you to experiment with economic models other than those linked to large-scale infrastructure involving surveillance and capturing of your social graph for financial gain. Maybe you want to share the cost of the server or the responsibilities of administrating it, maybe you want to collectively learn how to run all this stuff, or maybe you want to start meetings to exchange tips, etc. However, this does not mean that you need to cut yourself off from the rest of the world and this form of localism should not be misunderstood for a hipsterist and reactionary form of escapism. Instead, such an approach is quite the opposite as it provides a possibility to actively engage with societal issues. It allows groups to collectively think, in the sense of defining questions and hypotheses themselves, acquire skills and knowledge and respond to issues that are both relevant to their own situation but that can also resonate globally, enabling others to start a similar process.

      The goal of this article was to provide some tools and insights which not only allow for contextualisation of the technology we are using and supporting, but also help making sure that the instant-messaging you and your friends use happens in a trusted and secure environment, as much as possible outside the economies of surveillance. For this reason our motivation for writing this article was two-fold. On the one hand we wanted to show that the issue of privacy is more insidious than institutional eavesdropping and not merely solved with the use of end-to-end encryption. On the other hand, and as a consequence, we wanted to suggest not a different app, but a different approach altogether on the basis of XMPP federation and collective action. Therefore we’ve written two guides. One on how to configure a server and one on how to choose and use clients that can go along with it. These allow you to put a self-hosted approach, an approach that brings aspects of trust, scale and implementation to the forefront and into practice. Once again, such guides should not be perceived as definitive answers but more as tools to keep us, and hopefully you too, busy formulating the right questions and building networks of mutual help. So while we are unable to recommend you the next big app that will solve all user surveillance and financialisation once and for all—as we are pretty sure no such app will ever even exist—we hope to at least help shed a light on the confused and confusing discourses that surround crypto-sound alternatives which may obfuscate less obvious problems.

      Picking and setting up modern XMPP clients

      Introduction

      First of all, we recommend to follow this guide with a friend who also wants to use this technology. Then you can help each other out and immediately test if everything works. Aside from that, there are already enough XMPP users with empty contact lists around :’(

      Parts of this guide on are based on articles written by Mathias Renner on how to set-up Conversations and Gajim.

      This is a guide for Conversations (Android), ChatSecure(iOS) and Gajim(desktop Win/Lin)

      Registering an account

      To begin with, you will need a XMPP account! These look like e-mail adresses (username@servername.com) and can be registered with XMPP servers. To get such an account there are a few options:

      Host your own XMPP server at home. We’ve written a guide on how to do so, including on how to add user accounts.

      If you don’t want to or can’t set up your own XMPP server:

      • Find a friend who runs an XMPP server and ask her for a user account!

      • Have a look at the list of public XMPP servers. There are some things to look out for however. Make sure they are compliant with all the modern server extensions or you won’t get the user experience you are looking for[ref]It is also possible to test other servers yourself using this compliance tester[/ref]. Also look out for services requiring your phone number to register, it is not needed for XMPP and it would defeat the purpose of taking back the reins of your messaging horse.

      • Register an account with https://conversations.im/, the server run by the developer of Conversations. It is well maintained and running the latest features[ref]The first six months are free, afterwards there is a monthly fee that goes to support and sustain the ongoing labour into Conversations and free open-source messaging protocols[/ref].

      Considering XMPP clients

      Then you need to pick and install a client (also known as an app or a software package). There are many clients avaible that support XMPP chats, both for mobile, desktop and web-based environments. The nice thing about using XMPP is that your account and your client are not intertwined, as is the case with Whatsapp, Telegram, Signal and the others. These applications offer a full chat service, which includes the facilitation and hosting of your messages over the network, and the interface options of your client. By separating the two, you have the option to choose. To pick from all the available clients we made a list of criteria of what we considered essential requirements and started crossing off all those applications that didn’t meet them:

      • free & open source software —  the technology is open, and therefore it’s possible to install use the software on your own terms.

      • works with federated servers —  servers are not all controlled by a single company or organization, but can also be run by volunteers, organizations, companies, you and me.

      • highly secure (which means support for encryption) —  the software takes security to heart and offers things like end-to-end OMEMO encryption.

      • the project is recently updated —  There are many XMPP clients available, but not all of them are still maintained. For example: many iOS clients have not been updated for a long time.

      • support for easy image sharing — Essential in order to be able to share dank memes and food pictures.

      • relative ease of use - Need we explain more?

      This (apparently) rather rigorous list of requirements left us with three applications that we will discuss in this guide: Conversations for Android, ChatSecure for iOS and Gajim for the desktop computer. There are many other XMPP clients however, and while most of these did not meet our requirements for use, they might be ok for you. Have a look at this extensive list of XMPP clients in general and this list of clients that (plan to) support OMEMO. Additionally you might want to make sure your client supports some of the ‘modern’ XMPP Extensions[ref]XEP-0163: Personal Eventing Protocol (for avatars and OMEMO), XEP-0198: Stream Management(for better experience using flaky mobile connections), XEP-0280: Message Carbons(sync messages between your different clients), XEP-0313: Message Archive Management(receive messages while offline), XEP-0363: HTTP File Upload(send images, share files in groupchats and with offline contacts.)[/ref].

       _______
      < OMEMO >
       -------
              \   ^__^
               \  (oo)\_______
                  (__)\       )\/\
                      ||----w |
                      ||     ||
      

      Conversations, Android

      Download the Conversations app on your Smartphone.

      Conversations is available via Google Play for €2,39. The sale of the app goes towards the ongoing development of te software.

      In case you don’t use Google apps or want it for free, you need to install the alternative ‘app store’ f-droid before. F-droid works like the app store Google Play, except that it isn’t a store and only offers apps that are free and open source software. See instructions in the next paragraph how to install f-droid.

      If you decided for f-droid, open the website (https://f-droid.org/) with your phone’s browser. Press the big download button on the website, which will download f-droid’s installer. After download, press the downloaded file and the installer should start. Next, start f-droid, update the repositories and search for the app Conversations.

      Start the messenger app and register/log in

      Now, start Conversations. If you already have an XMPP account, you can log in with your so-called JID (jabber id, username@server.com) and password. Otherwise, if your server of choice has the option for application-based registration enabled, it is also possible to register a new account in this menu, by selecting the “register new account on server” option.

      After you clicked Next, the registration process might take up to 20 seconds.

      Start chatting.

      To start a chat you need to add another Jabber friend under the ‘+’ in the menu and insert your friend’s Jabber ID, e.g. your-friend@a-jabber-server.com. That’s it. You can now chat with your friend. However, this will be unencrypted!

      Encryption

      So let’s activate OMEMO encryption by pressing the padlock in the top menu bar:

      selecting OMEMO encryption

      OMEMO is an extension to XMPP for multi-client end-to-end encryption. OMEMO only works if the fingerprint of your and your friend’s device match. To compare them, open one of your conversations and click on your profile picture next to one of your messages. At the same time, your friend clicks on your icon on his phone.

      Checking fingerprints

      Now, both of you should see a fingerprint that you can check. If they match, change the slider as you see in the screenshot to the right.

      If OMEMO cannot be activated, just send a message in the chat window. This sometimes helps. Also, it may help to end a conversation by pressing the menu on the top right inside a conversation, and then re-open the conversation again.

      After you activated OMEMO, the input field at the bottom should say you can now send encrypted messages:

      The shield or padlock indicates an encrypted message

      Troubleshooting Conversations

      If OMEMO cannot be activated, just send a message in the chat window. This sometimes helps. Also, it may help to end a conversation by pressing the menu on the top right inside a conversation as shown in the following screenshot, and then re-open the conversation again.

      Ending a conversation

      Allow presence updates, this is used by OMEMO to exchange keys: In a conversation, click on the icon/image of your chat partner. In the new screen (as shown below), make sure that all checkboxes are activated:

      Make sure you allow presence updates so your client can exchange OMEMO keys

      Check fingerprints: You might be asked to trust fingerprints like this:

      Checking fingerprints

      If you run into problems try asking for help in the Conversations XMPP groupchat: conversations@conference.siacs.eu

      ChatSecure, iOS

      Download the ChatSecure app.

      Get ChatSecure from the AppStore. ¯\_(ツ)_/¯

      Start the messenger app and register / log in.

      Choose whether to create a new account or login with an existing one:

      Initial screen: create or add accountSelect XMPPThe login screen

      > >

      If you already have an XMPP account, you can log in with your username@hostname and password. After you selected “Add Existing Account” you have the option to connect with “XMPP” or with “Google Talk”. Select “XMPP” and fill in your Nickname, Username (username@server.net) and password. Optionally fill in the Hostname of your XMPP server and select if you want to use Tor or not. If you’re doubting about the port, 5222 is the default XMPP port and would likely be on your server as well.

      Enabling Push

      Considering using push

      After you’ve logged in, the app proposes to establishe secure connections by sending an empty message to offline contacts. You have the option to “Enable push” or “skip” this part. iOS typically end the connection when an app runs in the background and requires use of Apple’s Push servers to wake up and receive a message. By sending empty messages ChatSecure limits the data being sent to the Apple Cloud’s Push Server but obviously still provide their vertically integrated cloud platform with meta-data. Read more about the Push issues here and here

      In the next screen you can “Share invite” (let people on social media know about the app) or tap the ‘✓’ symbol in the top right corner to continue. This takes you to the general ‘Settings’ menu.

      Invite others to use ChatSecureSettingsLogging out

      > >

      If you are successfully connected, the word “Connected” appears right under your username. Before you can edit your account settings, you need to log out. To do this, click your account/nickname in the settings menu and select “Log Out”.

      Create New Account

      advanced optionsadvanced optionsserver options

      > >

      Choose “Create New Account” and give your preferred nickname. Under “show advanced options” you can customize your username, generate an automatic password, enable TOR (we didn’t test it) and select a server where you would like to register your account on. This is the server you will use to communicate with other people’s selected servers, and depending on the server settings it will also store your (encrypted) messages. ChatSecure let’s you choose between 3 built-in servers options. Default is DuckDuckGo, but when you tap on “DuckDuckGo” the app will take you to the server selection screen where you can choose between DuckDuckGo, Calyxinstitute.org and OTR.im[ref]All three of these servers score poorly on the modern XMPP compliance test[/ref], it also offers you the option to select another, custom, server. Here you can fill in the hostname of the XMPP server of a friend.

      Adding contacts

      server optionsserver optionsfriend request

      > >

      From the settings menu, tap ‘Chats’ (top left) to start chatting and adding friends. To add friends tap the ‘Compose’ icon, top left corner. Then tap “Add Buddy” and fill in your friends username and hostname (username@hostname) or scan their QR code.

      Click the “+” icon when you are ready. Your friend will now appear in the “Chats” list and will be available for conversation after being approved by the other side (“pending approval”). After this, tap your friends name to start chatting

      If you get a friend request, their nickname will appear in the “Chats” list.

      Encryption

      When in a chat, tap the information icon on the top right (i) to change your encryption settings. The information menu displays your current and past verified fingerprints and allows you to specify an encryption method by tapping “Show Advanced Encryption Sett…”.

      friend requestfriend requestfriend request

      > >

      At the time of writing OMEMO works well with other OMEMO clients, images shared over HTTPUpload however are not displayed inline but rather as a URL. If you click that your browser will open it and fail to decrypt the OMEMO encoded image, because it has no notion of your OMEMO fingerprints. So for now the images shared over HTTPUpload have to be shared using plaintext.

      ChatSecure implements OMEMO and OTR on a TOFU or “trust on first use” basis. New “buddies” are automatically trusted.

      friend requestfriend request

      >

      You can also untrust your friends devices/fingerprints by sliding the green “Verified” button and share fingerprints by tapping them and selecting a medium to share your fingerprint over.

      If OMEMO cannot be activated, just send a message in the chat window. This sometimes helps. Also, it may help to relaunch the app…If you’re chatting with someone using something else than ChatSecure, for example Conversations on Android it helps when the Android side allows for receiving and sending presence updates. For specifics refer to the Conversations section of this guide.

      Gajim, Desktop Windows / Linux

      These instructions are for Debian / Linux. For windows it is possible to download the binaries here.

      Getting the latest version of Gajim

      The version that is packaged in the repositories of Debian does not support OMEMO unfortunately. As a way around, you can download and install the latest version of Gajim from the Debian backports repositories.

      In case you don’t have backports on your sources.list, follow these instructions before you start:

      For wheezy add this line to your sources.list (or add a new file with the “.list” extension to /etc/apt/sources.list.d/) You can also find a list of other mirrors at https://www.debian.org/mirror/list:

      deb http://ftp.debian.org/debian wheezy-backports main
      

      For jessie add this line to your sources.list:

      deb http://ftp.debian.org/debian jessie-backports main
      

      Afterwards :::console sudo apt-get update

      Now we are ready to go!

      Installing Gajim & other dependencies from backports

      To install gajim:

      apt-get -t jessie-backports install gajim
      

      Now you’ll also need to install Python-axolotl, which will allow you to setup a security layer on top of XMPP. Run:

      apt-get install python-axolotl
      

      Next, you have to downgrade protobuf due to a bug in python-axolotl:

      sudo pip2 install protobuf==2.6.1
      

      And now for OMEMO! There is a package gajim-omemo on Debian Backports. So run:

      apt-get -t jessie-backports install gajim-omemo
      

      Starting Gajim and installing plugins

      Next, start Gajim. After Gajim has started, wait some seconds until it requests your permission to install updates:

      Allow Gajim to update itself

      Allow this. Afterwards, a new window will open that lists all components that can be installed and updated. In this list, activate the checkbox next to the following plugins:

      OMEMO

      HttpUpload

      Image

      Url image preview

      These plugins allow for encryption (OMEMO) and the easy sharing and display of images across different clients (HttpUpload, Image, Url Image preview)

      Then, click the button Install/Upgrade on the bottom left on that window.

      After the update has finished, go to the other tab Installed. There, make sure that all components are activated via the checkbox. Afterwards, click close on the bottom right of the window.

      Then, you should see a wizard to setup your XMPP account. Select the option that you already have an account and follow all instructions yourself using the default settings.

      Gajim account creation wizard

      After you finished the wizard successfully, Gajim will show your status as Available. Congratulations! Now, let’s send messages to your friends.

      To do so, click on the Gajim window and move your mouse to the top of the screen. There, a menu should appear. Go to Actions -> Start chat… . In the new window, add the XMPP ID of your friend and click ok.

      Adding contacts

      Go to the main menu again and select View -> Show offline contacts… . In the Gajim window, you should see your friend. Right click on the name of your friend and select Manage contact -> Add to roster. In the pop up, just click Add. Now your friend is permanently added to your list of contacts. Next, right click on your friend and select Manage contact -> Allow subscription -> Allow contact to see my status.

      Your friend should see a request like this:

      Friend request

      Your friend should click Authorize, which enables her to see if you are online or not. Also, this step is necessary for activating the encryption.

      Next, make sure that your friend also allows you to see her status.

      Now, when you open the chat window to your friend, it should say OMEMO encryption enabled and show a red shield next to the input field, like this:

      Omemo enabled

      If you don’t see the OMEMO encryption enabled — just restart Gajim and have a look again.

      You might at some point be confronted with a window about trusting fingerprints.

      Fingerprints

      Simply put, a fingerprint is an ID of a device someone uses for the messaging. In order to make sure that you communicate with exact the devices, which your friend uses, you need to see if the fingerprints listed in this window match with the ones your friend really has.

      So, ask your friend to list her fingerprints on her desktop. On her computer, in the chat window with you, she should click on the setting symbol below the text input field (grey, with wheels). From there to OMEMO encryption -> Fingerprints. She should now see the same window as you.

      She should chose the tab Own devices, while you chose the tab Contact. Now, select a fingerprint that matches with the one of your friend and press the button Trust/Revoke Fingerprint. Also press yes in the window that appears.

      Finally, all fingerprints should be green like this:

      Omemo enabled

      Troubleshooting

      Sometimes, a restart of Gajim just helps :)

      If OMEMO encryption or the fingerprint option is grey and cannot be activated, just send a message in the chat window. This sometimes helps.

      If you wish to know more about Gajim check out the documentation. For more advanced issues check out Gajim’s XMPP chatroom

      Beginners guide to XMPP-speak

      XMPP

      Extensible Messaging and Presence Protocol. - A communications protocol based on XML that has been in development since 1999. Ever since the standard has been incrementally developed to add more functionality. It is the underlying technology that powers a lot of well known chat applications such as WhatsApp and Google Talk.

      Jabber - The original trademarked name of the Jabber service. Jabber.org is the original instant messaging (IM) service based on XMPP. Afterwards many different servers and clients have emerged. “Jabber” is to “XMPP”, what “email” is to “SMTP” and what “web” is to “HTTP”1.

      MUC - “Multi-User Chat”, the jargon for groupchat in XMPP world. This feature needs to be supported by both the clients and the servers. See XEP-0045.

      ROSTER - is your list of contacts.

      JID - Jabber ID / XMPP address. JID is the identifier of a user account. It looks a lot like an email address: user@server.com, but it is not. Some users might use the same name for both their email and JID but most of the time these are completely different things. Following the same logic, chatrooms also have a similar address: roomname@muc.server.com.

      XEP - XMPP Extension Protocol

      XEP-0045 MUC - defines support for Multi-User Chats, in other words, group chats.

      XEP-0163: PEP - Personal Eventing Protocol allows amongst other things to automatically publish avatars and OMEMO public keys.

      XEP-0313: MAM - Message Archive Management is an extension that allows one to receive messages while offline.

      federated server - A group of servers which agreed upon certain standards to communicate with each other. Such a group is a federation of servers. The federated XMPP protocol enables the user to select a client of preference and connect to their XMPP server of choice.

      centralized service - A vertically integrated service that includes both exclusive client and server software. In this scenario, most of the time, the user can only run one specific client and only interact with other users from the same service.

      Software: Clients

      As featured in our guide on XMPP clients:

      Conversations - Mobile client for Android.

      Gajim - Desktop client for Linux distributions, BSD, and Windows.

      ChatSecure - Mobile client for Apple iOS, ‘experimental’, but in active development.

      Other popular clients not featured in our guide:

      Adium - Desktop client for Apple macOS. The OSX version of Pidgin

      Kaiwa - A webclient, so it runs in the browser. Supports a lot of features and XEPs. Win/Lin/OSX

      Pidgin A client which supports a number of messaging standards including XMPP. Recently implemented support for OMEMO.

      There are many more clients available. Check your local F-Droid/Google Play Store/AppStore.

      Software: Server

      Prosody - Open Source XMPP Server software written in LUA. It is actively being developed and is notable for the large ammount of supported XEPs.

      Encryption

      C2S - The connection between a client and the server.

      S2S - The connection between servers.

      Transport Layer encryption

      Encrypts communication while it is in transit between client and server (c2s) or from one server to another (s2s). The servers where the messages are relayed between can however still read their content. It is probably known to most people in the form of HTTPS, which indicates the communication is encrypted between your browser and the server that is hosting the website you visit.

      Depending on your threat model, in case you and your contacts share the same trusted XMPP server, transport layer encryption might be enough to safeguard your privacy.

      End-To-End Encryption (e2e)

      End-to-end ciphers is client side method for encrypting messages. Only the sender, and the receiver, at both ends of the communication chain, can read the message, but not the servers in between.

      OTR - “Off-The-Record” is one of the older forms of e2e encryption available in some messaging clients. The big disadvantage of OTR is that both clients need to be online at the same time for the encrypted session to work. It is also not possible to synchronize OTR encrypted messages across mutliple clients.

      OMEMO - OMEMO Multi-End Message and Object Encryption, OMEMO is the XMPP implementation of the Double Ratchett encryption algorithm developed for Signal by Moxie Marlinspike at Open Whisper Systems. It is the most modern and convenient encryption mechanism that is practically invisible to the user. It also provides so-called forward secrecy, which means that every message is separatly encrypted. In the case that one cipher is intercepted by a third party, only one message can thus be decrypted.

      TOFU - Trust On First Use. A mechanism where the received fingerprint is assumed trusted immediately and is therefore checked as verified. Used in ChatSecure for OTR and OMEMO, called ‘Blind Trust’ in Conversations.

      OpenPGP - Pretty good Privacy is the oldest generic method for end-to-end encryption. It requires quite some knowledge and maintenance frmo its users. OMEMO is designed to provide similar or better encryption with less hassle. To use OpenPGP in Conversation a third party app called OpenKeyChain is required.

      Threat Model. When thinking about security and privacy it is important to note that there is no such thing as a protection against every and any possible threats. By aiming too large and aimlessly at a universal form of privacy, there is a risk of missing obvious blind spots because of lack of resources, lack of time, and lack of knowledge to cover all possible situations. In that sense the concept of a threat model is very useful. In a threat model, an assessment of what has to be secured and who could be willing to acquire your information and at what cost, is established in a realistic fashion. What poses a credible threat to you and your situation? Who represents that threat? What kind of resources does this threat possesses? The answer to these questions should inform you on what kind of measures one should take and which ones have the highest priority.

      Obviously this differs from situation to situation. Are you a political activists or dissident trying to organise for direct action and trying to avoid surveillance from governement agencies? Are you the user of a popular social network, trying to protect as much as possible your most confidential information from your private life? Are you an office worker trying to leak confidential information about unethical activities of your employer while remaining anonymous? Are you a user of public or private torrent trackers hoping to get away with mass downloading and uploading of whole seasons of The Great British Baking Show? Every situation is different, every situation needs a specific understanding of what is at stake and what would be the consequence if what you try to protect is exposed. Don’t believe in magical solutions, do your homework.

      This list is partly based on this glossary

      This guide is a companion to our article Have You Considered The Alternative? on instant messaging. Also check out our guide on configuring the self-hosted XMPP server Prosody, and our guide on XMPP clients.