[HN Gopher] Modern XMPP
___________________________________________________________________
Modern XMPP
Author : jrepinc
Score : 137 points
Date : 2021-08-23 14:28 UTC (8 hours ago)
(HTM) web link (docs.modernxmpp.org)
(TXT) w3m dump (docs.modernxmpp.org)
| notorandit wrote:
| Unluckily, as soon as xmpp was not supported by Google any more,
| all interests around it failed. R.I.P.
| zaik wrote:
| XMPP is doing fine without Google. There are lots of public and
| federating XMPP servers out there you can just sign up for:
| https://xmpp.org/getting-started/
| MattJ100 wrote:
| Hi, thanks for your support of our project, and all the users
| and developers of XMPP in 2021 :)
|
| Google closing down XMPP support was indeed a sad day for
| everyone. But there are plenty of us supporting the idea that
| Google does not control the internet.
|
| If you're interested to know what's happening in the XMPP
| community these days, there are monthly newsletters published
| to the blog ( https://xmpp.org/category/newsletter.html ) and
| by email ( https://xmpp.org/newsletter.html ).
| mst wrote:
| Plus while I was very sad they closed down the federation,
| XMPP is _still_ how I connect to the google chat network
| today, I just had to switch to having my client make two
| outgoing connections instead of one.
| FerretFred wrote:
| My needs were relatively simple in that I needed a system to
| route quick, short messages without much client overhead. I'd
| previously done this with XMPP (using Python) which worked well,
| but the protocol offered way too many options. Also, trying to
| find a decent client for my iPad was a nightmare. I switched over
| to MQTT which is more suited to the role in my case and works as
| intended.
| p4bl0 wrote:
| MQTT looks interesting, do you have links to simple
| implementation of the protocol? I often find simple (even if
| partial) implementations of protocol a better documentation
| than the complete specifications.
| PaulHoule wrote:
| I use
|
| https://en.wikipedia.org/wiki/RabbitMQ
|
| to run the IoT stuff in my house. Mostly I access it through
| AQMP but it supports MQTT also. An asyncio-driven python
| script takes events from the outside world and systems that
| have an cloud component like SmartThings and posts them to
| RabbitMQ. Other scripts listen for events, make things
| happen, log data to arangodb, etc.
|
| On paper XMPP supports M2M applications but it's not a great
| fit compared to other protocols.
| Jtsummers wrote:
| https://mqtt.org/software/
|
| There are a bunch of implementations there.
| kitd wrote:
| And once you have your MQTT server running, you can install
| NodeRed alongside it for a complete "low-code" IoT
| solution.
|
| https://nodered.org/
|
| https://cookbook.nodered.org/mqtt/connect-to-broker
| MattJ100 wrote:
| Yeah, if your needs are simple enough and your clients are
| small, MQTT is a good choice. Two or three XMPP servers even
| have built-in MQTT bridges for supporting very lightweight
| clients.
|
| From what I've seen, XMPP is used in IoT more for the
| federation aspect rather than as the "last mile" to the
| sensors/devices. Cases where you need interoperability and
| security across different sites/organizations.
|
| In any case, the Modern XMPP project (this article) currently
| only focuses on XMPP for the IM use-case.
| PaulHoule wrote:
| My first impression was that "there isn't any there there" but
| after this article got a lot of upvotes I realized I could find
| real content using the navbar at the top.
| eyelidlessness wrote:
| I had a hard time finding it too. It'd be nice to have
| next/prev in the main body for discoverability.
| ape4 wrote:
| I really hope this works. Does it need a new name and mascot ;)
| Its such an important application that's dominated owned by
| Slack/Facebook messenger/What App etc. (In case any one doesn't
| know XMPP was Jabber.)
| MattJ100 wrote:
| Names and mascots are hard :)
|
| Also important to note that this project is still aimed at
| developers (as is XMPP and all the protocol documentation).
| What's needed are friendly projects promoting to end-users.
|
| Current work in that area would be:
|
| - https://snikket.org/ - a client+server package of XMPP
| software for personal messaging (disclaimer: I started this
| project).
|
| - https://joinjabber.org/ - a community of folk working to
| support new users joining the network with documentation and
| infrastructure.
| alberth wrote:
| Obligatory XKCD comic: https://imgs.xkcd.com/comics/standards.png
| kenniskrag wrote:
| I think in this case they recommend the standards, which are
| worth implementing. E.g. "Our recommendations highlight only
| the XEPs you need to implement for a modern messaging
| application, ignoring historical cruft and excessive backwards-
| compatibility."
| ShrigmaMale wrote:
| XMPP is a rather old protocol at twenty-two years. If anything
| it is other standards that are newer and causing the "standard
| proliferation".
| aidenn0 wrote:
| It would be nice if I could, say, post a picture or an emoji in
| one xmpp client and have it displayed in all other clients that
| are capable of sending emojis and pictures. XMPP has so many ways
| of doing both of those that if you're not both using the same
| client it's a total crapshoot.
|
| Also the desktop clients are garbage:
|
| - Libpurple is such a lowest-common-denominator implementation
| that lots of features I expect from XMPP tend to just not work
| (maybe there's configuration buried somewhere in pidgin to make
| them work, but I haven't found them).
|
| - Psi got abandoned and so has like a dozen forks, some of which
| sometimes work; and many of which look a bit sketchy
|
| - Gajim is _almost_ great. However its a plugin-based system and
| too few plugins are enabled by default, so out-of-the-box it
| doesn 't work quite right.
|
| - Dino is getting to the point where it is usable, but if history
| is any clue, it will be abandoned shortly.
|
| There used to be some promising BOSH clients that could be served
| as static JS to make a usable web client, but they are quickly
| becoming out-of-date.
| MattJ100 wrote:
| XMPP is fully Unicode-aware and always has been, so clients
| lacking emoji support are probably due to platform-specific
| issues. I'd be interested in specific examples if you can name
| names.
|
| libpurple (and derived clients such as Pidgin) have been
| lacking in XMPP love for some time, they've been focusing on
| more fundamental changes within the project. There are signs
| things may be improving, but unfortunately it's only a good
| example of XMPP in 2006. Things have moved on.
|
| As you say, Gajim and Dino are good modern clients, and
| actively developed. I see no evidence of either of them being
| abandoned any time soon.
|
| Converse.js and JSXC are actively-developed web clients. JSXC
| just received an EU grant to implement group audio/video calls.
| aidenn0 wrote:
| Re: images
|
| Sending an image from one client software will always result
| in either an inline image or a link to the image being
| displayed in other client(s). However there are combinations
| of clients which won't expand inline images from each other
| (IIRC conversations.js 6.x and dino seem to do things
| slightly differently, while conversations.im views both just
| fine).
|
| Then there's the fact that not all Jabber clients will
| convert to jpeg, so e.g. in my Dino chat history I have a
| bunch of WebP images that don't expand inline, but show fine
| on Gajim and Conversations.im
| aidenn0 wrote:
| RE: emoji
|
| Not all clients send unicode emoji; some send their own
| emoji, as the clients emoji support predate's unicode's emoji
| support (2010). Psi is one example off the top of my head.
| mst wrote:
| (Y)
| Lammy wrote:
| :putnam:
| aidenn0 wrote:
| Converse.js was "the best at the time" when I tried about a
| year ago. I just tried it now and it is far improved, so
| that's good.
|
| JSXC was so-so when I tried a year ago. They seemed to be
| more focused on "Add XMPP to your web-page/webapp" rather
| than "use as a standalone" and a lot of the UI decisions seem
| informed by that (it very much tries to only use a fraction
| of the display, and managing more than about 3 chats starts
| to get crowded). Perhaps with theming I could make a good
| standalone app out of it, but it feels like swimming
| upstream.
|
| [edit]
|
| Didn't address your comment on Dino; I don't see any signs of
| it being abandoned either, this is more my cynical rule of
| "every time a jabber client gets stable enough that you can
| use the one from your distro's package manager, it gets
| abandoned" it's purely empirical and Gajim is the only
| exception to it so far in the past 20 years.
| bertman wrote:
| re. web client: converse.js (https://conversejs.org/) is pretty
| cool!
| ATsch wrote:
| > It would be nice if I could, say, post a picture or an emoji
| in one xmpp client and have it displayed in all other clients
| that are capable of sending emojis and pictures.
|
| I don't personally think multi-device will ever be solved in a
| satisfactory way in XMPP. Like IRC, the whole architecture is
| fundamentally based on relaying messages. This works great for
| desktop computers, but as you add more devices with more
| intermittent connectivity, it breaks down quickly as you need
| to resort to hacks like sending deltas to other devices as
| carbon copies, which may or may not be delivered or interpreted
| correctly by clients. To solve it you need to fundamentally
| rethink your protocol not as one that relays messages, but
| synchronizes history. This is extremely hard to do without
| breaking backwards compatibility as you basically need to
| rearchitect every part of the stack. Matrix is a notable open
| messaging standard that does this and although it has it's
| flaws, multi-device experience is not one of them.
|
| I'd definitely welcome XMPP making improvements in this area,
| but I'm not personally optimistic it can be done in time
| considering the generally dwindling userbase.
| Zash wrote:
| Do you have a source for "generally dwindling userbase" ?
| Lammy wrote:
| Does living through it count? :)
|
| Once Upon A Time every GMail user was also an XMPP user.
| SamWhited wrote:
| And now every Zoom and Whatsapp and meet.jit.si user is.
| This sort of thing didn't really go away, companies just
| decided to construct walled gardens instead of federate.
| ATsch wrote:
| Not really. I can't easily find any statistics, but I just
| based it on the fact that a few years ago roughly half of
| my techy friends used XMPP. Many ran their own servers and
| all of the clubs had one. The work one had hundreds of
| users online at all times. Today all of these numbers are
| zero. Roughly split 40/40/20 between telegram, matrix and
| discord.
| aidenn0 wrote:
| Jabber has almost completely solved this. TFA mentions how
| and notes the two places that have in-progress XEPs for
| improving (there's a race with MAC/Carbons where you have to
| either risk duplicate messages or dropping; current
| recommendation is to do the former and check for dupe).
|
| On top of this, by far the best client I've used for XMPP is
| Android-only (Conversations.im). I have no problem using
| Gajim on my desktop and Conversations on my phone, and I have
| an SMS/MMS bridge (jmp.chat) that lets me send even to people
| without jabber from it. Multi-device and mobile is the one
| place where XMPP is ahead of 99% of the other messages, and
| it works similarly well to Matrix in my limited experience
| with Matrix.
| ATsch wrote:
| In my experience (which was echoed by coworkers requests to
| resend messages, until we switched) there are a select few
| happy paths where it works reasonably well and a lot more
| where it doesn't. You seemed to agree with that in your
| original comment.
|
| In general the problems with XMPP are rarely with missing
| checkboxes or things that miraculously don't exist
| somewhere in the hundreds of accepted and in-progress XEPs,
| but the long tail of user experience in the real world.
| aidenn0 wrote:
| Linux desktop clients not named "gajim" were very slow to
| adopt Carbons as the delivery method. And in Gajim you
| needed to enable a plugin. Things were _very bad_ in the
| transition period (which ended about 5 years ago?). At
| work we setup a jabber server for a small group of about
| 6 people and then more people started using it. It was
| running an ejabberd that was too old to support carbons.
| Once it became clear that some sort of IM solution was
| wanted, we came up with a list of features. Upgrading
| ejabberd and recommending proper clients fixed every box
| except "iOS client with push notifications" (XMPP didn't
| at the time support out-of-band push notifications, it
| does now).
| [deleted]
| sobakistodor wrote:
| We develop Web in C++ and all our protocols looks like this:
| serializer.put<uint32_t>(item).put(another).put(this); if
| (writer.valid()) { // no overflows or other problems
| socketwriter.write(serializer.data()); }
|
| Simple. Bytes. Dont care about any "protocols".
| lelanthran wrote:
| serializer fixes endianess?
| ajconway wrote:
| Bytes don't care about protocols, but anyone who cares about
| future and backwards compatibility should.
| Jtsummers wrote:
| > Simple. Bytes. Dont care about any "protocols".
|
| You have a protocol there, you have an understanding of what's
| expected on either side of that communication. That is the
| definition of a protocol. And if that's for Web stuffs, as you
| say, then you must be implementing something related to
| HTTP/HTTPS, protocols.
| selfhoster11 wrote:
| Good luck with upgrading or downgrading anything. There's a
| reason why people serialise to well-known formats like protobuf
| and JSON, and it's because they are extensible.
| southerntofu wrote:
| Moreover, there's a reason why people standardize/specify
| their profobuf/JSON/XML schemas, and it's because that's more
| extensible than unversioned, unnamespaced serialized data.
| eitland wrote:
| A company I used to work for used to do something like this (I
| never had access to the source code, but I inspected it closely
| with Wireshark a time or two).
|
| Sent over UDP this had stood the test of time for a couple
| decades or so.
|
| Disadvantage: the rest of the system was also written in C++
| and it was impossible to get those who had access to the source
| code and knew it to fix anything. As a result the system looked
| more and more antiquated and there were more and more hoops to
| jump through to get it working with every new version of
| Windows:-/
|
| Edit: that said, I think your comment is a bit off topic :-)
| jpxw wrote:
| XMPP plus plus, perhaps. Or XMPPPP.
| mst wrote:
| But XMPP is federated, not point to point?
| 0xdeadb00f wrote:
| Anyone else feel like the fact XMPP needs this kind of signals
| that it's pretty... shit? (Excuse my language).
| cat199 wrote:
| if so then same is true for say, TCP/IP, HTTP and HTML
| MattJ100 wrote:
| Do you have constructive suggestions on introducing cohesive
| design into open ecosystems without a guiding documentation
| project? (disclaimer: I started this one)
| 0xdeadb00f wrote:
| Firstly, to answer your question: No.
|
| There are other ecosystems that are going "fine" that have
| centralised, official documentation and don't require a third
| party to intervene and collate documentation and
| recommendations in an attempt to make it easier for
| developers. The fact this is necessary, or people feel is
| necessary, makes me want to avoid XMPP at all costs. That's
| just my very shallow surface level opinion.
|
| With all that said, i have to say; what you're doing here is
| commendable. I don't mean to (pardon my language) shit on
| something you seem to have worked very hard on. Doing
| something like this isn't an easy task I'm sure.
| southerntofu wrote:
| XMPP has a long history... Two decades of accumulated
| specifications can make it a bit overwhelming to find what
| you're looking for. It's important to have external
| individuals/collectives gathering the pieces they find
| important and remarks to achieve what they consider a good
| implementation.
|
| It's just like when you do web stuff you may read from MDN,
| csstricks or smashing magazine. It doesn't mean that the
| W3C/IETF specs are useless, far from it. But in my view
| it's useful to find guidance in a nebula of specifications
| and endless UX possibilities.
| franga2000 wrote:
| This kind of thing is pretty common with complex systems
| that have a very long legacy. There's a huge amount of
| features, many of which are very niche and most people
| don't even need to know about them. Official docs tend to
| be unopinionated and cover everything, while third parties
| create "guides" and similar docs for the features that
| matter to them.
|
| You see something similar with end-user software like
| Adobe's entire suite where the official docs are basically
| useless if you just want to learn the common operations
| quickly and so you have to rely on third-party books and
| tutorials (like the Dummies books).
| icedchai wrote:
| XMPP is basically an abomination of a protocol. It's too
| complicated. Other people can explain it better than I:
| https://news.ycombinator.com/item?id=2069810
| pmlnr wrote:
| Seriously? Go check out Matrix or ActivityStreams, XMPP is
| actually much simpler.
| icedchai wrote:
| The core of XMPP may be simple, but when you add in various
| XEPs, the complexity builds really fast. Just look at all
| this stuff: https://xmpp.org/extensions/
| MattJ100 wrote:
| That's a growing list of documents over the course of
| XMPP. It doesn't really prove anything other than... XMPP
| has been around a long time, and people continue to
| develop it.
|
| People saying "look at all this stuff" is one reason the
| Modern XMPP project was born. To draw attention to the
| actually important things that developers need to read.
|
| The XSF receives a lot of submissions each year. Many of
| these proposals never make it past the "experimental"
| stage. Others are only applicable in certain domains
| (IoT, etc.). Over time some of these become widely
| adopted and progress through the standards process. Some
| do not.
|
| The XSF publishes annually the "compliance suite" which
| describes what clients and servers should be supporting
| in different areas: https://xmpp.org/about/compliance-
| suites.html
| mst wrote:
| One of the key points of the article we're discussing is
| to recommend a small curated set of XEPs.
|
| Just look at this relative lack of stuff:
| https://docs.modernxmpp.org/client/protocol/
| floatingatoll wrote:
| The killer app of centralized chat systems is their general
| protections against unwelcome abusive contact from strangers
| (spam, harassment, death threats). Everyone focuses on the
| protocol but I focus on the experience, what with having been
| stalked for twenty years by an Internet-competent stalker. So I
| see nothing in this Modern XMPP website that is competitive on
| that point, which means I'll likely continue ignoring XMPP, same
| as I do IRC these days. Is there something I've missed that
| Modern XMPP implements that protects against abusers?
| NoGravitas wrote:
| XEP-0191 (Blocking command):
| https://xmpp.org/extensions/xep-0191.html
|
| It's a draft XEP, so it's not widely implemented yet. I know
| the server I'm using supports it via a plugin, but I don't
| think even Conversations supports it yet.
|
| The one thing I do think XMPP really has going on for privacy
| protection is that multi-user chats can be configured to not
| give out the real JID of members to other members, which is
| something I kind of miss in Matrix.
| floatingatoll wrote:
| Block commands are not the solution I'm describing, sorry.
|
| If the Block command is the network's only available abuse
| prevention tool, then chat network has failed to do a good
| enough of job of implementing anti-abuse protections.
|
| (I'm aware that some people don't believe in network-level
| anti-abuse protections, and I'm not going to try to convince
| anyone to agree with me. This is just how I evaluate whether
| a given chat network is accessible to me or not. XMPP is one
| such network, and doesn't have any, so.)
| MattJ100 wrote:
| > It's a draft XEP, so it's not widely implemented yet.
|
| Just to pick on this, sorry. The XSF terminology is not
| obvious (it was inherited from other standards
| organizations).
|
| Draft here means the protocol _is_ absolutely in use, it just
| means that it is theoretically open to changes. The next
| stage is "Final", and that is typically only reached after
| substantial time in production (it's basically a statement
| that the document is 100% finished and won't ever be
| updated).
|
| There have been proposals to change the term "Draft" to
| "Active" or similar.
|
| XEP-0191 is supported by practically all servers:
| https://compliance.conversations.im/test/xep0191/
|
| And supported by all modern clients.
| southerntofu wrote:
| I'm sorry that's happened to you. There definitely should be
| ways to mitigate that. There's not a lot happening on this
| front to my knowledge in the Jabber/XMPP ecosystem, but there's
| already building blocks in place which effectively limit abuse:
|
| - Jabber addresses (JIDs) are not broadcast to everyone in
| public chat, only to the admins of services you use, except in
| private encrypted chatrooms (for encryption key retrieval) -
| most public chatrooms support nicknames, so you can have
| different nicknames in every room - it's easy with some clients
| to support multiple accounts to separate your activities - your
| address cannot be automatically gathered from 3rd party
| information (eg. a phone number) unless you precisely declare
| it in your contact information (vCard) or use a server which
| relies on such feature (like quicky.im to use your phone number
| as account name) - 3rd party information cannot be leaked from
| your address unless you explicitly declare it in your contact
| information (vCard) ; it's quite common for services based on
| phone numbers such as Signal to leak your phone number to third
| parties
|
| Unfortunately, there is nothing yet like a Web of Trust or
| reputation system which you could use, for example to only
| display friend requests from friends of friends or something
| like that. And there's no support for single-use aliases as we
| have in the email world. But there is some level of interest
| for that and other fields of experimentation, and there's
| overall strong interest in keeping users safe and happy from
| the community at large, and a vast majority of server
| operators.
|
| Many servers are operated by non-profits and much like in the
| Fediverse don't hesitate to defederate with a server whose
| admins are not interested in preventing abuse from their
| network. Following some issues with misogynistic neonazis in a
| public chatrooms a few months ago, we also setup a chatroom to
| discuss such issues on xmpp:abuse@joinjabber.org?join and
| you're more than welcome to join us and formulate ideas on how
| we can improve in this domain. In case you don't want to setup
| an account for that, you can reach the chatroom via
| https://anon.joinjabber.org (works on Tor browser).
| mst wrote:
| Do you mean forced non-anomymity to the provider so every time
| you block them they need a new phone number to contact you
| again?
|
| Figuring out the right combination of G-lines to get some
| bastard to stay out on IRC is a bit trickier, certainly, but
| I'm sufficiently stubborn that even the worst of the harassers
| I've been chasing down for users have given up before I have.
| floatingatoll wrote:
| I don't know if what you describe is the answer, but
| certainly I mean "someone is implementing anti-attacker
| processes upon new signups and existing accounts", so that
| the majority of abusive attacks are stopped _before_ I 'm
| required to Block someone.
|
| As you describe with G-lines, without a centralized anti-
| attacker system, it is very much the whack-a-mole game that
| I'm accustomed to from XMPP or IRC.
| southerntofu wrote:
| > without a centralized anti-attacker system, it is very
| much the whack-a-mole game
|
| Unfortunately, even centralized networks play this whack-a-
| mole game. Facebook/Google requesting ID cards or phone
| number has unfortunately _not_ eliminated abuse from their
| network. Which is not to say there 's no way we can improve
| the situation (see my other comment).
| floatingatoll wrote:
| Your statement is incomplete, and presents only the
| framing "abuse was not _eliminated_ ", as if eliminating
| abuse were a boolean Y/N flag and therefore all steps
| taken to date are a total failure.
|
| The two centralized networks you referenced _have_
| eliminated _some_ abuse from their network by taking
| those steps.
|
| As I said elsethread, I won't try to persuade you that
| it's right for them to have taken steps, but I'm certain
| we still both agree that it's impossible to _completely_
| eliminate abuse from any system containing user-generated
| content, and therefore the metric of success you set (
| "eliminated") is provably unattainable, which^
| invalidates your framing.
|
| ^ (unless you think it's possible to fully eliminate
| abuse, in which case you have a trillion dollar startup
| idea to pursue, because we all sure need that!)
| solarkraft wrote:
| Modernization/UX improvement projects are badly needed in many
| areas in free software where the underlying technology is great,
| but the experience of actually using it is not.
|
| I'm happy about each one.
| southerntofu wrote:
| You'll be happy to learn that Snikket project just started a
| cooperation with Simply Secure to do UX studies on the Snikket
| family of clients: https://snikket.org/blog/simply-secure-
| collaboration/
|
| Snikket, which a maintainer of modernxmpp.org (who also
| comments in this thread) is also a maintainer for, is a project
| focused on forking existing clients (in a friendly manner,
| contributing patches upstream) to provide a consistent
| UX/"brand" across platforms. Really cool project!
| emptysongglass wrote:
| It'd really be great if selfhosters could take snikket as
| container, tie it into one of their existing reverse proxies
| (like Traefik) and go to town. It's what I do for Synapse and
| it works a treat.
| MattJ100 wrote:
| 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 :)
| [deleted]
| dsr_ wrote:
| I have a suggestion for this and other projects like it:
|
| 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. Make the best decision that
| you can.
|
| In this document, there's discussion about STARTTLS vs TLS-from-
| the-beginning, and how to deal with that in the UI. Don't do
| that. Decide that TLS-from-the-beginning is the requirement for
| client-server interactions, and now you don't have a UI issue.
| You already decided that /resource and priority were not going to
| be useful; make this decision too.
|
| In general, resolve incompatibilities.
| Lammy wrote:
| > 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 with Open Discussion Day
| <http://opendiscussionday.org/>"
|
| Well-intentioned for sure, but the one XMPP provider with an
| actual critical mass of users (Google Talk) remained non-TLS-
| only, all Google Talk users dropped off the federated XMPP
| network after May 2014, and so XMPP effectively ceased to
| matter.
| MattJ100 wrote:
| In fairness, by 2014 it was fairly obvious that Google was no
| longer interested in furthering Google Talk. It was about the
| time that they were pushing folk to Google+ and Hangouts.
|
| Google's XMPP server continued to accept unencrypted
| connections for many years after this point. I think the XMPP
| operators made the right choice, rather than letting Google
| weaken the security of the entire network.
| Lammy wrote:
| > by 2014 it was fairly obvious that Google was no longer
| interested in furthering Google Talk
|
| Definitely, but I think it was a huge PR failure that we in
| the XMPP community were the ones to sever the
| conversational link. Users shouldn't be expected to think
| about the protocol details, hence this thread, and it was
| an XMPP community decision that resulted in people being
| suddenly unable to talk to their friends.
|
| We provided perfect justification for any Google project
| manager to look at the stats and see zero incoming s2s
| connections as justification to kill Talk entirely so they
| could Move Fast(tm) on Hangouts or whatever.
|
| I guarantee we pushed more overall XMPP users to
| WhatsApp/FB than we pushed Google Talk users to privacy-
| first XMPP hosts since it's not like Google popped up any
| alert in the GMail Talk UI explaining to people why their
| nerd friends all suddenly vanished from their buddy lists.
| The moment any of those people used a non-XMPP service to
| reach out and ask "What's up?" we had already lost :/
| giancarlostoro wrote:
| Yeah, I would argue pick one secure way for the client to ask
| which one the server prefers and dont let the end-user even
| bother thinking about it.
| southerntofu wrote:
| That's already what happens in practice, as defined in
| XEP-0368 SRV records for XMPP over TLS
| https://xmpp.org/extensions/xep-0368.html
|
| That UX description is intended for "additional connection
| options" prompts, which are useful when your server is
| misconfigured or you want to reach it in a different manner
| than advertized over DNS (eg. over a .onion address).
| nashashmi wrote:
| I understand where this is coming from. But this kind of early
| decision making can hurt the growth and adoption of projects.
|
| Think of it as Apple making a bunch of decisions for themselves
| and their users and it keeping problematic for future adoption.
|
| The spirit of open source is voluntary participation and
| openness to all platforms and ideas. Though I cannot understand
| the distinction behind TLS and STARTTLS , I don't think locking
| in one option will make it all that better.
| southerntofu wrote:
| > Though I cannot understand the distinction behind TLS and
| STARTTLS , I don't think locking in one option will make it
| all that better.
|
| StartTLS starts unencrypted then "upgrades" the connection to
| TLS if the client and server support it. This leaves a whole
| lot of room for an active attacker on the network to prevent
| all forms of encryption, rendering TLS essentially useless.
|
| That's not to say TLS is perfect: having to trust an entire
| list of third-party CAs with their own incentives/pressures
| is a flawed model. But TLS is better than no TLS, so direct
| TLS is better than StartTLS.
| MattJ100 wrote:
| > This leaves a whole lot of room for an active attacker on
| the network to prevent all forms of encryption, rendering
| TLS essentially useless.
|
| This is a common misconception about STARTTLS. It is
| certainly possible to implement it poorly (and that has
| certainly happened). But there are no inherent security
| issues with a correct implementation. An active attacker
| can just as easily block TLS handshake packets on a direct
| TLS connection.
|
| The problem used to be that many software implementations
| (not just XMPP) would happily continue unencrypted if
| STARTTLS was not offered. But these days everyone requires
| TLS, and will not proceed to connect unless TLS is in use
| (regardless of whether it is negotiated or "direct").
|
| However the future is certainly direct TLS, that has been
| obvious for some time. It has many advantages, such as
| allowing the use of off-the-shelf middleware such as
| loadbalancers and proxies, and bypassing certain firewalls.
| It's also easier to implement, and there is of course the
| (relatively new) ESNI which is beneficial.
| southerntofu wrote:
| > The problem used to be that many software
| implementations (not just XMPP) would happily continue
| unencrypted if STARTTLS was not offered.
|
| Thanks for the correction. I thought that was in fact a
| "feature" from a StartTLS perspective.
|
| > easily block TLS handshake packets on a direct TLS
| connection
|
| But then no downgrade attack is possible at all.
|
| > (relatively new) ESNI
|
| Is there any deployment of that in XMPP clients/servers
| yet?
| ocdtrekkie wrote:
| Indeed. I think this stems from presumably wanting to support
| legacy XMPP where possible, email servers and FTP servers are
| the other two places this option often comes up.
|
| But it should probably be really clear that the correct way is
| X, and support for Y should be buried somewhere so most users
| don't have to think about it, if you do feel a need to retain
| support for it.
| MattJ100 wrote:
| Agreed! As in my sibling comment just now, I've updated this
| section to say basically that.
| MattJ100 wrote:
| You're completely right, thanks for the spotting that and the
| feedback!
|
| I was going to remove it, but I don't think that's the problem.
| The whole section you mention is the problem - all these
| options should be auto-discovered, and in fact are, in any
| normal deployment. It's sometimes used for unusual deployments
| (connecting over a VPN, or a testing/development server).
|
| For normal deployments, XMPP already defines which
| host/port/TLS-mode to use and how a client can pick between
| them.
|
| So I've just merged an update that clarifies that these options
| are not generally recommended for implementations to expose to
| users, except to support testing/development.
|
| I'd rather have this documented (i.e. "if you are going to do
| this anyway, at least do it correctly, like this").
| kbenson wrote:
| > all these options should be auto-discovered, and in fact
| are, in any normal deployment.
|
| I think that's a slightly different thing than what was
| suggested. For some options, auto-discovery is fine. For
| security, I think the current consensus is just make the best
| choice you can, and if something really requires a major
| change, version the standard (major version, like from 1.x to
| 2.0, so it's obvious). Auto-discovery of a setting to do with
| security is just another possible location where a security
| issue might be found because or a poor implementation of the
| standard.
| MattJ100 wrote:
| Sure, but I don't think that applies here. The section in
| question is about a settings screen where (for some reason)
| the user is manually entering all the connection
| parameters. There is no way to detect (without probing)
| whether the port that the user configured is using STARTTLS
| or direct TLS. Both are commonly deployed.
|
| Probing could be implemented, but that quickly introduces
| complexity (and code just as likely for security issues to
| hide in) to implementations. It would be nice to one day
| say "only support direct TLS" for example, but that's not
| the reality of today's network (looks like ~41% of servers
| advertise direct TLS as of today, slowly climbing).
|
| So the happy path is using auto-discovery as standardized.
| If you go the manual path and configure a host/port, I
| don't think probing is sensible to recommend, and I don't
| think strictly assuming only one or the other is going to
| fly right now.
| [deleted]
| kbenson wrote:
| Is this just for clients, or for servers as well? If it's
| for servers also, I guess that's a question of what you
| want this to be then. Is it a descriptive document that
| says "this is what Modern XMPP looks like as we see it in
| the wold" or a prescriptive document that says "This is
| what you need to do to be a modern XMPP deployment so we
| can fix some problems of the past".
|
| Maybe one way that might look is user clients that probe,
| but when defining how servers should act, there's a "one
| true way" unless they aren't adhering to Modern XMPP spec
| or best practices. Changes like this need a push from
| outside or they never happen, and someone just being able
| to point at a spec and say "look, you aren't compliant
| with Modern XMPP, the world has moved on from what you're
| doing" is incredibly useful in spurring change.
|
| I agree it doesn't necessarily make sense for a client
| options perspective, but it might be a good principle to
| adopt or consider for other aspects of the document. If
| you want to actually push things forward, I think it's
| very useful way to do so.
| MattJ100 wrote:
| This project is certainly aiming to push things forward.
| Indeed a decade ago it would be totally unsurprising to
| see a client with a drop-down for "STARTTLS", "Direct
| TLS", "No TLS" (!).
|
| I think it's best described as something of an evolving
| "current best practices" document. There is certainly
| room to tell developers to implement (or not implement)
| certain features. Indeed that is done already for some
| things (e.g. file transfer mechanisms).
|
| I think this specific TLS example is unfortunate because
| it's something that is documented only for advanced use
| (recognising that some people may need it for specific
| purposes that some clients may want to support).
| Macha wrote:
| Similarly, I remember implementing an Android IRC client
| years ago and having to provide an option in a dropdown
| not to verify the TLS certificate since so many servers
| ran self signed certs at that time (thankfully Lets
| Encrypt put a stop to that).
| AshamedCaptain wrote:
| I really hate it when "modern" is used generically in technical
| documentation. What does "Modern" mean? Does it mean lightweight?
| Heavyweight? Easy to implement? Simpler? More complex?
|
| The vague descriptions like "modern" usually mean "More like
| whatever the author's today's usecase is", and good luck trying
| to get anyone except yourself onboard with that...
| sobakistodor wrote:
| Modern means: "we analyzed all bad things about the thing and
| fixed many of them". Paradigm in "modern"-term is "more time -
| better solution". So "modern" - many time passed.
| AshamedCaptain wrote:
| Bad for whom exactly? For example, here it seems today's
| usecase was a "SMS-like mobile messenger", so they are
| deprecating stuff such as resources, priorities and presence
| notifications. WHY? My use-case as is the entire of my
| network is multiple devices, so resources AND priorities are
| a must.
|
| So rather than "modern XMPP" this looks like "how to use XMPP
| to build a SMS-like messaging program for mobile phones". Now
| it's clear who is the target of the document and you avoid a
| weasel term like "modern" which also annoys every other
| consumer of the protocol.
| selfhoster11 wrote:
| I think it's fair to describe the SMS-like mobile messenger
| as the modern goal of XMPP if that is in fact what people
| are using. The goal here is to get broader adoption for the
| protocol, and the only way to do that is to make it easy to
| deploy and use for a mass-market audience that expects
| certain things already.
| MattJ100 wrote:
| You're right. I take responsibility for the name, but
| naming things is hard!
|
| As for the focus, you're right, there is a bunch of advice
| that is specific to this class of personal messaging apps.
| As time, resources and interest allow, I would like to grow
| it to document other "profiles" of XMPP as well. For
| example the Slack-like "team chat" use-case, or even IoT.
|
| If you're using XMPP in a particular domain and you feel it
| would benefit from documentation like this, PRs are
| absolutely welcome. It's in scope.
| HumblyTossed wrote:
| It's definitely over used. Use Google to search for the word
| "modern" on HN. Good grief...
| hkt wrote:
| 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.
| MattJ100 wrote:
| Author here. Yes, Movim is a great project! The Movim author
| has indeed contributed to the Modern XMPP documentation.
|
| As one of the other commenters pointed out, most of the current
| docs here are aimed at a particular use-case of XMPP, which I
| tend to call "personal messaging".
|
| I think the Modern XMPP project is just about growing to the
| point where it will make sense to potentially split some of the
| recommendations into different "profiles", so you would have a
| "social" profile of XMPP which Movim sits squarely in.
|
| I'm excited that the XMPP-ActivityPub gateway will enable Movim
| joining the Fediverse ecosystem (Mastodon, etc.).:
| https://www.goffi.org/b/activitypub-gateway-and-pubsub-e2ee-...
|
| Finally, regarding server support, Movim has always been
| pushing at the edge of XMPP, which is great. It certainly led
| to improvements in Prosody (the server implementation I work
| on) since you tried it in 2015, so it may well be worth another
| try. I don't personally use it myself (yet?), but probably
| someone from the Movim community could give advice.
___________________________________________________________________
(page generated 2021-08-23 23:02 UTC)