[HN Gopher] XMPP, a comeback story
___________________________________________________________________
XMPP, a comeback story
Author : upofadown
Score : 177 points
Date : 2021-11-17 18:12 UTC (4 hours ago)
(HTM) web link (takebackourtech.org)
(TXT) w3m dump (takebackourtech.org)
| FpUser wrote:
| I do not think any protocol can claim true privacy. If they want
| they'll find you.
| Andrex wrote:
| Even in that defeatist context, it's still worthwhile to try.
| zmix wrote:
| I wonder what ever happened to SIP presence and text messaging
| (and related specs)?
| Arathorn wrote:
| The barely even got as far as group chat, for which they used
| MSRP. Then they turned into RCS :/
| SaltySolomon wrote:
| The whole issue with XMPP is that yes, in theory you could do
| e2ee accross multiple servers and devices but only if all the
| servers support the right extensions and the clients support them
| properly.
| MattJ100 wrote:
| This is not a problem with XMPP, but any open ecosystem.
| There's no way to force third-party developers to implement
| stuff, especially when they are open-source volunteers working
| in their free time.
|
| XMPP does have this feature parity issue, though there is a
| good selection of modern active XMPP clients across platforms
| with important features like end-to-end encryption and calls.
| But you're right - there's no way to stop people trying to use
| clients like Pidgin, which have been essentially frozen in time
| for a decade.
|
| Matrix is newer, so has less diversity, and lots of resources
| to put into the Element clients. However there certainly is
| exactly the same problem growing in the Matrix ecosystem too -
| there are many features supported by Element that are not
| (yet?) implemented in popular alternative clients such as
| FluffyChat.
|
| The best you can do is ensure that when two clients communicate
| without the same set of features, that you degrade gracefully
| and securely (e.g. the worst case I can imagine would be E2EE
| that silently becomes unencrypted if not supported by your
| contact - thankfully that's not how it's done) to the best
| common feature set between the two.
| jayd16 wrote:
| I think a major problem is there isn't (last I looked) a
| clear set of feature tiers or a collection of XEPs that are
| given names and tests.
|
| Instead of "oh MS teams supports up to xmpp2017" it's just a
| crapshoot.
| MattJ100 wrote:
| Here's what you're looking for:
| https://xmpp.org/about/compliance-suites/
|
| Compliance suites are reviewed, updated and published
| annually with the recommended set of features across a
| range of different categories.
| jayd16 wrote:
| Well there go. I guess now that I think of it, last I
| looked was MUC support in 2012 or so.
|
| Looks like it's on the list but as "* Support can be
| enabled via an external component or an internal server
| module/plugin."
|
| So...a crap shoot, haha.
| rapnie wrote:
| See also "Modern XMPP".
|
| https://news.ycombinator.com/item?id=28276266
| upofadown wrote:
| > ...but only if all the servers support the right
| extensions...
|
| That is only for OMEMO (OpenPGP and OTR require nothing of the
| server) and you can easily check a potential server for the
| things that OMEMO depends on by doing a normal server
| compliance check here:
|
| * https://compliance.conversations.im/
|
| In the same way, if you pick a client that does not support
| something then that thing will not work. But why pick such a
| client in the first place?
| Andrew_nenakhov wrote:
| The whole issue with XMPP is that users are brainwashed to
| demand e2ee even without fully understanding what it means and
| what unavoidable downsides in UX true e2ee brings.
|
| Most users would have the same level of security as with e2ee
| by simply running their own server. E2ee mostly helps against
| service owner you don't trust, so just be your own service
| owner and have nicely syncing history and server side search.
| pkulak wrote:
| I totally agree, though I run my own Matrix server and still
| find value in e2ee because I don't really trust AWS (or maybe
| my ability to secure AWS).
|
| I suppose I could run the service on a machine in my house,
| but that's not going to be good for uptime, the NAT screws
| things up, etc. Plus, even that could be hacked if I fuck
| something up.
| Andrew_nenakhov wrote:
| If you run a legal operation, you don't have to worry about
| hosting company admins logging into your database. That can
| be done only on police inquiry.
| pkulak wrote:
| Eh. I'm still not storing passwords, keys, documents,
| photos, et all, plain text in some RDS database.
| Andrew_nenakhov wrote:
| On photos/documents, you are in a tiniest of minorities:
| ~99% of all smartphone users store photos in unencrypted
| cloud services like Google Photos and use Google Docs and
| MS Office 365.
|
| (But but chats are surely the holy cow and must be
| encrypted - strictly demand those same users,
| paradoxically)
|
| And no modern server stores passwords in plain text, and
| keys are not stored on servers at all.
| NoGravitas wrote:
| For single-user XMPP servers, this is true, but on the other
| hand, not everyone is able to run their own server.
|
| I will say, that even though I kind of like the
| _architecture_ of XMPP better, the Matrix people have put in
| tremendous amounts of work to overcome the UX problems with
| e2ee, in particular the multidevice problem (where I have a
| laptop and a phone logged into the same account and try to
| participate in the same encrypted conversation from both).
| zaik wrote:
| > in theory you could do e2ee accross multiple servers and
| devices
|
| I use XMPP to send e2ee messages to friends on other servers
| and clients every day, so it's very much not just 'in theory'.
| tlackemann wrote:
| I remember using XMPP for a site I built that connected tenants
| and landlords, a reverse MLS of sorts. Back then, I choose XMPP
| because I had heard this is what Facebook was using at the time
| for their new messenger and it provided services like online
| status, typing status, and live messaging out-of-the-box. I don't
| recall it being terribly difficult to implement and it was
| awesome to see it working for the first time!
|
| This was almost 10-years ago now, it's incredible to see this
| technology still moving forward.
| k__ wrote:
| Interesting.
|
| I had the impression the general opinion about XMPP is that
| it's resented as the SOAP of messaging.
| tschellenbach wrote:
| I think XMPP is too complex for most use cases, I'd be surprised
| if it doesn't continue to decline in popularity.
| zaik wrote:
| What makes you think it is currently declining?
| tschellenbach wrote:
| My company, Stream, powers chat for thousands of apps. XMPP
| used to come up in the past as a way for people to build in-
| house chat apps. The last year or 2 it's gone from being rare
| to non-existent. If people do build in-house it's usually
| from scratch with Go or Rust.
| riccardomc wrote:
| We used XMPP to orchestrate servers and runtimes at one of my
| previous employers.
|
| I might be romanticizing it in my memory a bit, but I remember it
| fondly.
|
| We would run ejabberd servers and could easily know which nodes
| were up and talk/send commands to them.
| obiwan14 wrote:
| Memories! I'm sure I have at least one Jabber account somewhere.
| Don't even recall where to find it. Easier to just creat a new
| one and see if things have really improved from way back.
| spankalee wrote:
| Instead of all the web3 nonsense, which still requires
| implementations working with interoperable protocols like this,
| that energy should be put into advocacy for standard protocols,
| or building apps that use them.
| PaulHoule wrote:
| It's little known that XMPP is a big hit with military and police
| organizations. (e.g. the Baltimore police department has XMPP-
| based chat and feeds the messages into Lotus Notes)
|
| Vendors in that market heavily use extension mechanisms. For
| instance commanders of infantry units might fill out forms every
| day about what kind of contacts they had with the enemy and get
| them sent to a central location.
| IceWreck wrote:
| > meaning people from different servers can talk to each other
| while no central authority can have influence on another server
| unlike Matrix
|
| Elaborate please. Matrix doesn't have a central authority server
| which can influence other servers.
| Arathorn wrote:
| Yup, Matrix as a network has no central authority at all,
| although it's a common untruth which gets passed around, rather
| depressingly.
|
| Things which could be at the root of this misunderstanding
| include:
|
| * The fact that we operate a *strictly optional* logically
| centralised directory service to look up matrix IDs by email
| address or phone number. I really wish we'd never added this to
| Matrix; it causes way more grief than it solves - we'd have
| been better off waiting off for someone to build a
| decentralised keybase service and use that instead.
|
| * Element runs a centralised integration manager (aka app
| store) to make it easier to add bots/bridges/widgets to rooms.
| Again, this is completely optional - although back in 2019 we
| had a stupid bug in Element Web which meant it checked the
| integration manager even if you weren't using it. This was
| fixed in June 2019 (https://github.com/vector-im/element-
| web/issues/6802).
|
| * Element has to query your server to find out what
| authentication mechanisms are available before you log in.
| Therefore if its config points to the default matrix.org
| homeserver, you end up pinging that every time you log in, even
| if your homeserver is elsewhere. The solution for now is to
| change your default homeserver in the config to avoid this.
|
| * Servers need to be able to validate events from servers even
| if those servers are offline. To do this you need to grab the
| public key for the offline server from somewhere; by default
| Synapse uses matrix.org as a fallback, but loudly nags the
| admin to pick a better default when you install the server.
|
| None of these actually allow a "central authority to have
| influence on another server" though; I've just listed the only
| places I can think of where a typical self-hosted Matrix
| implementation might interact with centralised services run by
| Matrix.org or Element.
|
| Unfortunately I think the real root of the misinformation is
| that it's just a bit too tempting and easy to throw around FUD.
| Some day we may get to the point where alternative FOSS
| projects will realise that the real enemy are centralised
| proprietary user-exploiting services rather than one another...
| zaik wrote:
| Matrix is a lot better than every proprietary service, but
| it's poor XMPP compliance currently makes it impossible to
| have essential features like encrypted communications or
| adding Matrix users to multi-user chats.
| Arathorn wrote:
| Unfortunately XMPP<->Matrix end-to-end encryption is a
| contradiction in terms. You have to speak the same protocol
| from end-to-end, otherwise you'd have to break the end-to-
| end encryption to translate from one protocol to the other.
| The closest you could get would be to run the Matrix<->XMPP
| bridge clientside alongside your Matrix client... but at
| that point you might almost as well be running a multihead
| messenger that speaks both Matrix & XMPP.
|
| In terms of adding Matrix to MUCs; i believe we're working
| on it in Bifrost, which is in active albeit slightly
| sporadic dev: https://github.com/matrix-org/matrix-bifrost.
| zaik wrote:
| > Unfortunately XMPP<->Matrix end-to-end encryption is a
| contradiction in terms. You have to speak the same
| protocol from end-to-end, otherwise you'd have to break
| the end-to-end encryption to translate from one protocol
| to the other.
|
| You'd only have to speak the same _encryption_ protocol.
| There already exists standards like the Signal protocol
| (on which OMEMO builds) or OpenPGP (which many XMPP
| clients support besides OMEMO). If messages can cross the
| border, so can public keys and encrypted messages.
| Arathorn wrote:
| Unfortunately this isn't true. Olm (Matrix's encryption
| protocol) _is_ the same as OMEMO, which in turn is the
| same as libaxolotl. In fact, the OMEMO XEP even
| recommended Olm as an implementation for OMEMO at one
| point due to licensing concerns with libaxolotl
| /libsignalprotocol!
|
| But the fact that both protocols use the same E2EE
| encryption protocol doesn't help you with
| interoperability - given that you have to break that E2EE
| in order to convert between Matrix & XMPP; either on the
| server (ugh, defeats the whole point of E2EE) or on the
| client (ugh; you might as well just have a multiheaded
| messenger).
| zaik wrote:
| I'm not sure I understand. If in fact the same underlying
| encryption protocol is used, why can I not retrieve the
| public key of a Matrix user, encrypt the message and send
| it? Nothing here requires the server to break E2EE.
| upofadown wrote:
| Even if you could make Olm/OMEMO interoperate otherwise,
| the Signal protocol supporting client requires access to
| a server to pick up pre-keys. So you need to have access
| to the pre-key server of your correspondent or your
| correspondent needs access to the pre-key server you are
| on. The Signal Protocol is not generally suitable for
| this sort of thing mostly due to its complexity.
|
| If you did something stateless like OpenPGP then you
| could do E2EE over bridges with no problem. The cost
| would be that each and every message would be complete in
| itself. So sending a single emoji would take several
| hundred bytes. That might be less important these days...
| ThatGeoGuy wrote:
| Because the message format is different. In XMPP, the
| message is an XML document according to the message
| schema. In Matrix, it's JSON.
|
| You can exchange the private keys, but using what format?
| Once that's done, you can encrypt XML on one side, but
| Matrix has to convert it into JSON on the other (in its
| own, separate format with its own fields). This can be
| done on the server side after decryption (no more E2EE),
| or on the client side (after decryption). In the latter
| case, you're not running a bridge anymore, you're just
| running an ad-hoc client for XMPP inside your matrix
| client.
| h0p3 wrote:
| Amazing work. Bravo. I'm very much hoping to see P2P Matrix
| arise. That is no small task, I realize (and I'm grateful to
| those who have contributed to this). What are you thoughts on
| that aspect of the ecosystem?
| Arathorn wrote:
| P2P Matrix is a moonshot, but it's coming together really
| well. The only bits left at this point are:
|
| * Making Pinecone resilient to attacks. It's working well
| for clear weather scenarios, but we need to properly try to
| break it and get it audited. Need to test it at scale too.
|
| * Improving Dendrite so that it's more stable and efficient
| clientside
|
| * Metadata-protecting store-and-forward, so that clients
| can pass messages to each other without needing to be
| online at the same time. You can cheat and run a serverside
| P2P node to relay, but then it stacks up metadata - whereas
| half the point of P2P is reduce Matrix's metadata
| footprint.
|
| * Account portability. Currently each node is a separate
| account; need to support the same logical account being
| replicated over multiple nodes.
|
| * Better than full-mesh routing. This should be pretty easy
| as we can just follow Pinecone's topology to route traffic
| between nodes rather than having each node try to
| simultaneously post to every other node in a given room.
|
| You can get testflight & APK builds from #p2p:matrix.org if
| you want to experiment.
| klabb3 wrote:
| > The fact that we operate a _strictly optional_ logically
| centralised directory service to look up matrix IDs by email
| address or phone number. I really wish we 'd never added this
| to Matrix; it causes way more grief than it solves
|
| (Not a Matrix user so maybe help me understand here.) I think
| the reason why I have about 30 contacts (instead of like 3)
| on Signal is due to phone number discovery. It's not
| decentralized, which is of course subject to criticism, but
| exchanging & verifying public keys between O(N^2) people
| hasn't "taken off" in the X decades since it was invented.
|
| > we'd have been better off waiting off for someone to build
| a decentralised keybase service and use that instead.
|
| Do you have an example of any _mainstream_ product that has
| ever achieved that, without either being partly centralized?
| Decentralized identity is really, really, really hard, and
| mostly the layer-8 implementation (discovery, name-squatting,
| impersonation, abuse, spam, key-management and exchange,
| etc).
| tjoff wrote:
| And it is also the reason why I'd never considered signal
| for anything.
| Arathorn wrote:
| well, keybase got quite far - it could have been
| decentralised but they chose to centralise it for
| commercial reasons. but yes, decentralised identity is
| hard, hence us cutting that corner (and then getting abuse
| about being too centralised...)
| jagermo wrote:
| Also, the bridge system in matrix is solid. Most people do not
| want to ban all other messengers, but they want all their
| communication in one place. Matrix-based messengers like
| Element or Bleeper seem like the way to go. And if people then
| start using matrix based chatrooms, all the better.
|
| But I doubt you can reach critical mass with a system that is
| not open to other chat systems, even if those are closed.
| akho wrote:
| XMPP has bridges.
| jagermo wrote:
| Yes, but it does not sell them well. Look at Beeper
| (beeper.com) or Element One (element.io), they actively
| market the fact, that you can use whatsapp or signal or
| telegram with them. Using matrix is nearly an afterthought,
| it's more like using pidgin or trillian back in the day.
| And I think it's clever because it lets me switch away from
| whatsapp etc, but I don't have to bring all my friends over
| at once.
|
| And, once I am on board, I can start to look into the
| features provided by matrix. People don't switch to a
| protocol, I think, they want to leave a service or
| provider. And yes, you are still part of whatever walled
| garden you choose to use, but whatsapp can run on an old
| phone and never touch my new phone, never getting the data
| on that device.
| zamadatix wrote:
| Beeper seemed cool but trying to find out more it just
| put me on a waitlist. Element One is extremely limited in
| bridges. Element Home seems better in that regard but
| still doesn't have a major one for me Google
| Chat/Hangouts. Neither seems clear on if I can use my
| personal domain while they host and manage the
| homeserver+bridges. Element One mentions subdomains and
| beeper mentions self hosting but neither seem to comment
| on personal domains which seem a natural fit to use for a
| federated service.
| goodpoint wrote:
| > the bridge system in matrix is solid
|
| Solid? They crash or malfunction all the time.
| MattJ100 wrote:
| XMPP was developed as an open protocol to bridge to
| proprietary communication platforms, just as Matrix is today.
|
| There are still such bridges (more commonly called "gateways"
| or "transports" in XMPP), such as for WhatsApp, Signal, and
| others. However my perception is that over the long period of
| time XMPP has been around, focus shifted to the "native"
| XMPP-XMPP use-case, because it's easier to build a better
| experience that way.
|
| My personal prediction is that Matrix will certainly go the
| same way - using a focus on bridging to bootstrap the network
| in the initial years, and then gradually shifting to focus on
| "native Matrix" for most use-cases after reaching a certain
| critical mass.
| jconley wrote:
| We tried our hardest back in the early 2000's to make this stick.
| I cofounded a startup building servers, clients, and SDK's. Maybe
| the world is finally ready for it now. The issue we ran into was
| customers/consumers just didn't care about federated systems. And
| various implementations had all sorts of quirks making
| interoperability between domains and clients difficult, at best.
| There are just SO MANY THINGS you have to do to make good
| messenger software that lining up all the pieces with open
| standards proved impossible in the ~8 years I was working on it.
| Again, maybe it's better now, but I'm skeptical, probably jaded.
| :)
| jandrese wrote:
| The thing I struggled with was how the XMPP chat based app I
| was trying to use was very much tied to the domain. If you
| weren't the domain admin you were SOL trying to set it up.
| Setting up two on the same domain--we were attempting to make
| it robust against disruption, think multiple servers on the
| same network where the interconnects may go down unexpectedly,
| but all local users need to remain connected and messages need
| to be relayed once the connections are re-established. They had
| previously used IRC which worked ok, but was "insecure" and had
| a mandate to switch to XMPP for security. Also had to be a COTS
| solution.
|
| In the end I left the project before they got it working. I
| have no idea if it ever got deployed.
| dogma1138 wrote:
| XMMP was and is very commonly used in finance for various
| trading systems. Pretty much any exchange or a large trading
| firm with a white label product has a chat function in the
| desktop client and they all almost always used XMMP because
| amongst other things you needed federation.
|
| It's not falling out of fashion a bit with many of the trading
| clients moving to web based interfaces but it have a sense it
| will still stick around for a long time.
| mfer wrote:
| It's not about the protocol. Most people don't care about XMPP,
| RSS, or any of those things.
|
| They have things they want done, like chatting with a friend.
| They want a solution that delights them in doing that. What
| delights people has generally changed (like more people care
| about others not listening in these days).
|
| Whose the user and what's their experience? This is where XMPP
| always failed me. The clients had a poor experience.
|
| If someone wants that to change now... focus on a great
| experience for the people you want to be users.
| jconley wrote:
| Yes, this is generally the issue with open networks. Very,
| very hard to get complex and disparate client/servers to play
| nicely with each other. Perhaps with the capital that is
| being put behind web3 someone will figure this out.
| beepbooptheory wrote:
| Yeah but then we gotta pay for em!
| acdha wrote:
| I'm expecting "web3" to go the other way: all of those
| speculators are looking to get their money back at a
| healthy return and that tends to favor building up barriers
| to switching. I'd expect claims that being open makes it
| too hard to prevent spam or slows innovation by adding
| features which, ooops, they totally slack on making
| interoperable.
| hunter2_ wrote:
| How can it go the other way, when it is specifically
| defined otherwise?
|
| > Web3 revolves around the idea of a decentralized
| Internet. Proponents often contrast this to Web 2.0,
| where large amounts of the web's data and content are
| centralized in a fairly small group of companies (often
| referred to as Big Tech). [0]
|
| [0] https://en.m.wikipedia.org/wiki/Web3
| johnisgood wrote:
| On Android I use Conversations[1] (from F-Droid), on Linux I
| use gajim[2]. For me it works, for others, I have no clue.
| Gajim is available on macOS and Windows, too. I dunno if by
| default it has the OMEMO[3], and PGP plugin though. I think
| they are a must-have. Make sure that "XEP-0384: OMEMO
| Encryption" is supported by the server you pick.
|
| [1] https://f-droid.org/en/packages/eu.siacs.conversations/
|
| [2] https://gajim.org/download/
|
| [3] OMEMO is an XMPP Extension Protocol (XEP) for secure
| multi-client end-to-end encryption based on Axolotl and PEP.
| Might want to go through https://dev.gajim.org/gajim/gajim-
| plugins/-/wikis/OmemoGajim....
| xiaomai wrote:
| I miss the "golden age" of chat where I could talk to anyone
| (google/fb/msn messenger/aol?) with my own jabber server.
| Pidgin was a great client at the time.
|
| I've been looking for a modern self-hosted chat solution. I
| want it to be XMPP so badly (running XMPP with something like
| prosody is so convenient). The clients are really letting me
| down though. Desktop clients are old-fashioned and awful (I
| could get behind that, but I don't think my kids could). The
| mobile situation is even worse.
|
| The new-fangled chat solutions (Matrix, Zulip, etc.) are
| interesting, but the operational requirements are insane (in
| the case of Matrix, I'm also very nervous about reliability).
|
| I can't say I'm super hopeful, but I'm rooting for you, XMPP.
| topdancing wrote:
| dino.im is the new up and coming desktop client. I have a
| few friends that are using Gajim on Windows.
|
| kaidan.im is also a new KDE client.
| icedchai wrote:
| Too bad AIM went away. AOL should've open sourced it. In
| the early 2000's, several companies I worked for used AIM
| like we use Slack today.
| oezi wrote:
| This golden aged failed when it missed the boat to go
| mobile. Ridiculous to think that none of the messengers
| from this time could envision to sync with the mobile
| phone's address book. I don't think we would have WhatsApp
| or Signal if any of the desktop chats had allowed that.
| l72 wrote:
| The Palm Pre actually had a really nice mobile messenger.
| It synced with Address Book, supported SMS, Jabber,
| Facebook Messenger (back when it was jabber), aim, and
| others. It would seamlessly switch protocols based on how
| the contact messaged you. Like most things with the Pre,
| it was way ahead of its time.
| arendtio wrote:
| Yes, someone should fix those iOS clients... I have Siskin,
| Monal and ChatSecure all running in parallel on my iPhone and
| none works as it is supposed to do.
|
| Siskin seems to be the best of these three, but is neither as
| reliable nor as feature-complete as Conversations on Android
| or Gajim on the Desktop.
|
| I think Android is the only platform that currently has a
| good user experience with Conversations or Quicksy for the
| less technical people.
| topdancing wrote:
| https://snikket.org/blog/snikket-ios-public-release/ -
| needs a prosody module for reliability though.
| syshum wrote:
| Back in the day I love the trillio or something like that
| client that connected a bunch of different networks together
| in a single app for the very reason you talk about. I wanted
| to chat with my friends, and others but some where on AOL,
| some on MSN, some on gchat, etc etc
|
| So I could connect to all the networks from one app
|
| Today the would connect Facebook, Teams, Slack, Whatsapp,
| signal, etc etc...
|
| That would be the dream....
| MattJ100 wrote:
| 1000% agree, so much so that I started such a project and
| wrote a blog post about this very problem[1] and launched
| what has become a full-time project to solve it (Snikket).
|
| These days I believe very much in identifying and serving a
| specific set of users. XMPP is just a protocol, it has lots
| of potential applications, but it's nothing unless you
| channel that into a tangible usable product for real people.
|
| This epiphany came to me after more than 10 years of working
| on XMPP as a server developer and spending time promoting
| open communication protocols to people. It was soul-crushing
| that at the end of a day I would still see my own family
| communicating with each other via WhatsApp.
|
| Six months after the initial Snikket prototypes, and after a
| little user testing, I migrated my family over to XMPP by
| sending a simple invitation link (the start of the Snikket
| onboarding journey). They're now using it daily and totally
| happy with it. I'm beginning to hear similar stories from
| others who have repeated this with their own families/groups
| and their own Snikket setups.
|
| All it took was to look at the issue through the eyes of
| "normal people" for a moment, and it changed my approach (and
| success rate) significantly.
|
| [1]: https://snikket.org/blog/products-vs-protocols/
| tsherr wrote:
| This is very cool. I moved our family to signal, but this
| looks better. I'll be trying it out for sure.
| derac wrote:
| This is great. I think it would benefit from having a large
| catch-all public server ehich people could use if they
| don't want to set up their own, shile retaining the choice
| to do so. That would improve the UX substantially, I think,
| although the cost may be too high.
| rglullis wrote:
| Plenty of people willing and able to build that experience,
| but not for free.
|
| If we got a nickel from everyone that complained about XMPP
| client fragmentation, we would have funding to pay enough
| man-hours to get high-quality clients for every major
| platform and even the minor ones.
| neltnerb wrote:
| I think the writing was on the wall for XMPP once people
| started chatting on Facebook and Facebook got past their
| brief XMPP compatible phase. Then Google also deprecated it.
|
| It's a nice protocol, but if you're missing all the
| conversations it doesn't help. When it was popular, it was
| the system that let you connect Yahoo to Google to MSN to
| Facebook to Zephyr to... it's network effects, people have to
| be on it for anyone to want to use it.
| [deleted]
| brunes wrote:
| What would truely make XMPP stick and be a killer app, would be
| if enterprise interoperability could be shown between apps like
| Microsoft Teams, Slack, and Discord. The amount of friction that
| enterprise consumers like myself have to deal with because none
| of these things interoperate is immense. Making them interoperate
| at a basic level via XMPP does not seem like it would be overly
| challenging.
| syntaxfree wrote:
| Idea: market interoperability as a metaverse thing.
| [deleted]
| stock_toaster wrote:
| Once upon a time, google chat (nee gchat) _was_ that killer
| app. For a brief time there was glorious federated
| communication between several IM vendors, self hosted open
| source servers, and gchat.
|
| Then google killed it all by dropping xmpp/jabber support in
| gchat, and others soon followed.
| loremipsium wrote:
| the technical challenge, or lack thereof, is not the reason why
| it's not done I suppose.
| smoldesu wrote:
| You're looking for Matrix. XMPP wants nothing to do with
| 'enterprise' apps that rely on potentially backdoored
| encryption standards. The people who care enough to enable
| OMEMO on their chats aren't going to do so with the intention
| of undermining their communique for a slightly better level of
| compatibility.
| VWWHFSfQ wrote:
| but what if they don't want to interoperate with each other
| artursapek wrote:
| XMPP's biggest flaw is its use of XML. If it modernized its
| serialization protocol, it might have a much brighter future.
| eecc wrote:
| Oh I used it. Built a POC involving devices advertising their
| positions and coordinating their group responses to commands via
| a bot chatroom and json messages.
|
| Worked a charm.
| rekoros wrote:
| boo
| skunkworker wrote:
| I remember back in 2008 reading on how Tivo started using XMPP
| instead of polling to check for new recordings.
|
| https://www.socialmediatoday.com/content/xmpp-aka-jabber-fut...
| ajcp wrote:
| That article is just one poorly aged sentence after another.
| Love it. Two of my favorites:
|
| "Therefore cloud services aren't real-time, won't scale, and
| often can't clear the firewall"
|
| "While Twitter is not a cloud service, nor the largest demand
| service on the internet (with a paltry 350,000ish users, which
| pales in comparison to a MySpace or Yahoo!)"
| kseistrup wrote:
| I've been using XMPP since its inception as Jabber, and it's my
| preferred way of communicating.
|
| Prosody and Ejabberd are two good, lightweight XMPP servers that
| will let you synchronize messages across devices.
| anarchogeek wrote:
| What an earnest and well-meaning BS post.... I mean seriously,
| XMPP is fundamentally flawed, and it's not coming back. What's
| more, we have matrix which is the protocol re-written from the
| ground up with the knowledge of XMPP and better design.
|
| Matrix IS XMPP 2.0.
| datenarsch wrote:
| > XMPP is fundamentally flawed
|
| how is it fundamentally flawed, can you elaborate?
| forty wrote:
| I really wanted to like XMPP back in the days, but honestly I
| always ended up feeling that the protocol is just bad. This
| idea of opening an XML document at the beginning of the
| stream, then only allowing a subset of XML and all the mess
| with the xmlns, all that bringing really nothing to the table
| except complexity.
|
| I think ideally in a good protocol, the server should not
| have to parse the content for the messages that are not
| targetted to itself (only the metadata useful for routing).
| the XML mess makes it impossible to do that since you have to
| validate the full document.
|
| At the time I think this page was a good summary of the
| issues https://about.psyc.eu/XMPP No idea if this is still
| relevant though.
| icedchai wrote:
| I've built an XMPP client for an internal application. My
| impression was the protocol was overly complex, starting
| with the lower level problems you describe ("streaming
| XML.")
|
| It's been years since I've looked at. Maybe things are
| better now.
| Yoric wrote:
| Well, I guess it kinda makes sense? Beats having to
| reinvent a tokenization format from scratch?
|
| Of course, smaller messages (a la Matrix) probbably make
| more sense.
| jandrese wrote:
| Ultimately the issue is that XML is a document markup
| language, not a purpose built streaming protocol. You can
| kind of force it into that role, but the parser ends up
| being overly complex and issue prone. It's like basing a
| chat app around creating a MS Word document of every
| message and sending it across the network.
| pohl wrote:
| I'm not going claim that it's fundamentally flawed, but
| here's an anecdote. Many years ago, when XML was having its
| day in the sun, long before it was sidelined by the
| simplicity of REST and JSON, I was at a Java One convention
| listening to a speaker present on some new XML parsing API.
| After the talk, I approached the presenter for some post-talk
| Q&A to ask how one might use the API to parse the Jabber
| protocol, which may or may not be relevant to what XMPP is
| today (I haven't been keeping up.)
|
| The presenter was unfamiliar with the protocol, so I had to
| describe how the xml document was opened when you establish a
| connection, and how elements keep getting appended to it, and
| how the "xml document" isn't really completed until you're
| all done and the connection is terminated.
|
| They looked at me like I had two heads.
|
| To them, XML didn't make any sense at all unless you have the
| entire document available all at once. After all, how on
| earth could one ever apply an XSLT transform to it, right!?
|
| Good times.
| pkulak wrote:
| That's what Jabber is? Streaming XML? Whoa boy...
| zmix wrote:
| > After all, how on earth could one ever apply an XSLT
| transform to it, right!?
|
| There is streaming APIs for XML. Just as XSLT 3.0 can do
| streaming. Saxon has implemented it, for example[1]. I am
| aware, that you are talking about the past, but also the
| XML world moves forward, albeit slowly, since the community
| has gotten much smaller.
|
| [1]: https://www.saxonica.com/html/documentation10/sourcedo
| cs/str...
| trasz wrote:
| I still find it amusing that XMPP by design violates XML
| spec, thus requiring its own custom XML parser.
| Andrew_nenakhov wrote:
| Matrix is not even a protocol. It is by far inferior to xmpp,
| especially regarding extendability, and the only flaw in XMPP
| is a rather lethargic council of elders that are not really
| interested in its development. This council is too be ignored,
| the base of the protocol is healthy.
| rapnie wrote:
| That is interesting. Do you mean that the xmpp.org foundation
| is not a good custodian of the specs?
| Andrew_nenakhov wrote:
| I think they are in some kind of lethargy, waking up each
| year and updating the compliance suite xeps.
| tannhaeuser wrote:
| TBH, (federated) chat/messaging is a solved problem since
| 1988 (IRC) or 1999 (XMPP), so I don't know what you
| expect
| Andrew_nenakhov wrote:
| - group chats are shit
|
| - message formatting is a mess
|
| - device management is absent
|
| - iOS apps can't really work with stock xeps
|
| And the list is long, these are just the top problems.
| Luckily, this will likely change soon.
| [deleted]
| pferde wrote:
| You say Matrix is not a protocol, and then you go on and
| compare it to another protocol. By your own logic, you are
| comparing apples and oranges here. Make up your mind, either
| it is a protocol or it isn't.
|
| Oh, and Matrix is plenty extensible, for example via custom
| event types: https://spec.matrix.org/v1.1/client-server-
| api/#types-of-roo...
| Andrew_nenakhov wrote:
| Matrix is a product developed by one entity that can be
| installed on premise and has an api. Different instances
| can communicate with each other. Mattermost also has it but
| we don't call it a protocol.
| Arathorn wrote:
| This is just not true. There are four main Matrix server
| implementations today: Synapse, Dendrite, Conduit and
| Construct. Conduit & Construct are written by entirely
| independent different parties; all four share zero code;
| and yet they all can communicate together (modulo beta-
| ness in some places).
|
| (And aside from that, Mattermost doesn't have federation;
| different instances can _not_ communicate with each
| other. Although we hope they 'll implement Matrix
| eventually :)
| Andrew_nenakhov wrote:
| Both third party implementations have beta status and all
| entirely independent implementations will be screwed and
| will stop working each time you decide to significantly
| change the spec in your monolithic protocil.
|
| I know, you consider xep structure of XMPP to be a
| problem, 'because it is hard to orient in it', but in
| fact it is what makes XMPP so durable and capable to work
| in a real federated environment.
| normaler wrote:
| How is Matrix not a protocol? Because it has not been
| externally standardized?
| Arathorn wrote:
| On the Matrix side of this: rather than spending time
| responding in detail I'll link to last week's iteration:
| https://news.ycombinator.com/item?id=29152551.
|
| The TL;DR seems to be the concern that Matrix was created by
| an existing team of folks who worked together (we built VoIP
| stacks for telcos), and because 50% of the people in the Spec
| Core Team who define Matrix's direction are from that
| original team, they have a disproportionate influence over
| how the protocol develops.
|
| The reality, as far as I can tell, is that we are
| incorporating the best proposals from across the whole
| community, wherever they come from, and the protocol is
| progressing steadily under this open governance model, and
| folks are constantly experimenting with new features under
| prefixes, which they propose MSCs (Matrix Spec Changes) for,
| and then get incorporated into the official spec once they're
| approved by the Spec Core Team (which requires 75%
| consensus).
|
| We spent ages setting up https://matrix.org/foundation and
| trying to enshrine a fair and neutral governance process for
| the spec, and as far as I can tell it's overall working. The
| thread linked above gives examples of ways in which the
| process is working as intended.
| Andrew_nenakhov wrote:
| Translation from prspeak: one closely integrated group has
| outsized influence on specification, and development is
| dominated by over commercial entity.
|
| This is not how healthy federated networks work.
| durandal1 wrote:
| It'd take the flawed XMPP protocol any day over the ad-hoc
| implementation of Matrix, which hardly even deserves to be
| called a protocol. Matrix feels like something made by making
| things up as the wrote the code, there is no coherency at all.
| NoGravitas wrote:
| I use both XMPP and Matrix regularly, and run servers for both.
| I wouldn't say Matrix is better than XMPP across the board, but
| that they have different trade-offs.
|
| The main architectural difference between them is that Matrix
| provides "eventually-consistent cryptographically secure
| synchronisation of room state across a global open network of
| federated servers and services", whereas XMPP just passes
| messages from point to point (where one of the endpoints may be
| a multiuser room).
|
| The main practical benefit of Matrix is that multi-user rooms
| don't have a "home" server; they're distributed across the
| homeservers of every member of the room. This means that though
| everyone may have signed up for a room identified as
| #shitposting:matrix.org, if the matrix.org homeserver goes
| down, the chat still works. People can't join it until a new
| name is published for it, but it works for everyone already in
| it. In XMPP, chats are hosted on a particular server, and if
| the server a chat is on goes down, the chat goes down.
|
| The main practical benefit of XMPP is that it is much more
| lightweight than Matrix. Being based on synchronization of room
| state means that Matrix stores a lot of data, generally all
| messages and attachments back to when the room was created (or
| possibly the first time someone on your homeserver joined the
| room). Apparently it's _possible_ to prune room history, but it
| 's not done by default, and as far as I know, it's not
| officially supported. It's much easier to control how much data
| your XMPP server stores.
|
| XMPP is also a simpler protocol, which means there is a wider
| variety of clients; while there are several vaguely viable
| Matrix clients, if you're not using Element, you are much more
| likely to have problems, especially with encrypted rooms. Of
| course, the flip side of this is that a lot of XMPP clients
| don't support all the extensions which make modern XMPP useful,
| either.
|
| Both of them have trouble with multi-device E2EE key
| management, though Matrix has the edge. But again, if you're
| not using Element, you are likely to have problems.
| zaik wrote:
| > whereas XMPP just passes messages from point to point
|
| So does Matrix. All the other qualities are build on top of
| that. XMPP also enables e2ee, message synchronisation and an
| "global open network of federated servers and services".
| etxm wrote:
| At my first startup we used XMPP (wildfire?) to do a lot of our
| ops work.
|
| All of our pet servers had a background process sitting in a chat
| room.
|
| We did deploys, restarted process, got alerts, and a whole bunch
| of other stuff all via XMPP.
|
| It was much cooler than our product that never made any money :)
| wpietri wrote:
| I reverse-engineered the comms for my cheap Ecovacs robot vacuum
| and was surprised to discover that, like some angsty teen, it
| spent all day hanging out in an XMPP chatroom waiting for
| somebody to talk to it:
| https://github.com/wpietri/sucks/blob/master/developing.md
| stefan_ wrote:
| XMPP is a part of TR069 as some sort of rendevzous point for
| device and controller:
|
| https://www.qacafe.com/resources/2015-03-26-using-xmpp-for-t...
| olah_1 wrote:
| Snikket is absolutely the future of XMPP imo. They have the right
| ideas: https://snikket.org/blog/products-vs-protocols/
| rapnie wrote:
| I watched the FOSDEM 2019 video [0] showcasing how XMPP can be
| used as a "generic message bus" for a broad range of application
| types using PubSub XEP and some other XEP's. Yet the vast
| majority of information, like 99.9%, deals with IM chat stuff and
| additional, related features (like Movim supports blogs, video
| via WebRTC, etc). Makes me wonder if it is indeed applicable for
| this generic use (like arbitrary business apps that would benefit
| from a well-specified message-based networking stack), or one
| should better stay away from that.
|
| [0] https://youtube.com/watch?v=JEDRSNGDxUQ
| zaik wrote:
| You can send arbitrary XML to some other node on the network.
| Just built upon the extensions you need and ignore the rest.
| kitd wrote:
| Tbh, unless your business app needed things like presence, file
| transfer, and federation, you're probably better sticking with
| something like mqtt, nats or rabbitmq.
| rakoo wrote:
| I'd like to ask the question the other way around: is it
| better/simpler/easier to use MQTT, nats or RabbitMQ instead
| of XMPP when you don't need those ?
| mike_d wrote:
| You are basically asking: is it easier to have two servers
| just talk to each other, or ping each other back and forth
| on Slack.
| rapnie wrote:
| Presence a nice-to-have, but the others I'd need.
| kixiQu wrote:
| > Can a 20 year old overlooked technology make a comeback as a
| completely decentralized, free, and scalable technology for the
| growing masses of people who value freedom and privacy?
|
| Betteridge's law strikes again!
___________________________________________________________________
(page generated 2021-11-17 23:00 UTC)