Modern XMPP

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • SurveyJS - Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • Movim

    Movim - Decentralized social platform

    I'd be really interested to hear the authors' take(s) on movim - is this under the umbrella of "modern" and are they involved?

    https://movim.eu/

    I love their social networking features and have periodically used their nodes but I've never managed to get family and friends on board. I suspect easier clients would be key there, but last I checked (2015, admittedly) server support for movim wasn't great.

  • manifesto

    A public statement about ubiquitous encryption on the federated XMPP network. (by stpeter)

    > When you are establishing a standard that clients and servers will advertise that they adhere to, don't leave technical decisions to the end-user by default.

    On principle I agree, but ironically the exact scenario you suggest was the single biggest event that "killed" XMPP as we used to know it. In late 2013 there was an XMPP community manifesto calling for mandatory TLS (even STARTTLS) for XMPP server-to-server communication by a drop-dead date in early 2014: https://github.com/stpeter/manifesto/blob/master/manifesto.t...

    "The schedule we agree to is:

    - January 4, 2014: first test day requiring encryption

    - February 22, 2014: second test day

    - March 22, 2014: third test day

    - April 19, 2014: fourth test day

    - May 19, 2014: permanent upgrade to encrypted network, coinciding

  • SurveyJS

    Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.

  • snikket-server

    Image builder for Snikket server

    Yes! That's what people do. I don't know about Traefik specifically, but we have docs for many other reverse proxies: https://github.com/snikket-im/snikket-server/blob/master/doc...

    If you feel like trying it with Traefik and submitting some example config for the docs, that would be very welcome :)

  • onionmx

    Onion delivery, so delicious

    Great question! onion vhosts ([email protected] addresses) don't need that, as long as your client can resolve onion addresses (Gajim/Conversations have good tor integration, otherwise Tor's AutomapHostsOnResolve will do the trick systemwide but in that case your client may complain that the domain doesn't support TLS or with a wrong certificate).

    "Advanced" connection settings is required when the vhost you are connecting to doesn't match the hostname you need to reach on the network. For example, if you're reaching your server over a VPN/SSH/IPSEC tunnel.

    Another example is if you wish to login as [email protected] by reaching foobar.onion. This is useful if you want to be part of the broader Jabber federation, in which not every host supports federation over onion addresses (i'd be curious to make stats about that) but it still gives you the security guarantees of Tor when reaching your server (though not for server-to-server connections).

    Onion name discovery for automatically upgrading to onion routing when Tor is available client-side is not yet specified within the XMPP ecosystem. Onion discovery in the HTTP ecosystem is usually done via Onion-Location HTTP header (HTTPS only), in the email ecosystem they use _onion-mx DNS SRV records: see https://gitweb.torproject.org/tor-browser-spec.git/tree/prop... and https://github.com/ehloonion/onionmx/blob/master/SRV.md respectively

    Implementing something similar XMPP side would be easy. Prosody already has a community mod_onions, but currently only supports a static map of hosts to their onion addresses. It could use some love: https://modules.prosody.im/mod_onions.html

    Another problem we face from a UX perspective for onion services is that currently XMPP server implementations are very strict about which node/resource messages are intended for, and to my knowledge none support aliasing systems as we have in the email world. In this specific example application of aliases, there's currently no way (that i know of) to have the same account across .org/.onion domains and having servers to know it's the same account in a federated manner, eg. to prevent you from adding the same person twice to your contact list.

    All in all there's interesting challenges and none of them is really hard so if you'd like to get involved or just let us know about your ideas and expectations, feel free to drop by xmpp:[email protected]?join

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts