[HN Gopher] A month using XMPP (using Snikket) for every call an...
___________________________________________________________________
A month using XMPP (using Snikket) for every call and chat (2023)
Author : ColinWright
Score : 68 points
Date : 2025-07-29 18:24 UTC (4 hours ago)
(HTM) web link (neilzone.co.uk)
(TXT) w3m dump (neilzone.co.uk)
| ColinWright wrote:
| Seen here:
|
| https://mathstodon.xyz/@neil@mastodon.neilzone.co.uk/1149374...
|
| Usage continues two years later ...
| riedel wrote:
| What are the actual security concerns when using OMEMO
| mentioned in the post? Most criticism I find is on
| implementations.
| digianarchist wrote:
| https://omemo.top/
|
| Wish there were more library implementations that clients
| could leverage.
| wahern wrote:
| > Moving to XMPP - using prosody - worked really well for
| messaging, but the lack of real-time notifications on Sandra's
| iPhone was sub-optimal
|
| Were they using Monal on the iPhone? I use XMPP (Prosody) with
| some friends. Conversations.im works really well on Android,
| including push notifications. But the one iPhone user, using
| Monal, has said notifications don't work, and I don't know how to
| debug. The Monal website and commit log suggests they should be
| working. (macOS desktop Monal works fine for me, but it's using a
| normal live TCP stream to receive notifications, not cell network
| push notifications.)
| AceJohnny2 wrote:
| AIUI (but actual iOS developers can correct me), for Push
| Notifications to work on iPhones requires the system to route
| through the Apple-hosted Apple Push Notification (APN)
|
| https://developer.apple.com/notifications/
|
| This is fairly at odds with the goal of XMPP, where the device
| listens to the server. But of course that model doesn't really
| work when the device is sleeping most of the time (and I don't
| know how IP or TCP connections are handled in an LTE or 5G
| world, but I'm sure there's a consideration there).
|
| All this to say: iOS is hostile to XMPP.
| sssilver wrote:
| Another way to say it would be: XMPP is hostile to power
| efficiency.
| zaik wrote:
| Conversations is one of the most battery efficient IM
| clients out there despite maintaining it's own TCP
| connection. This is possible because Conversations can tell
| the server to shut up unless it's important, which reduces
| radio usage a lot. This extension (CSI) is quite mature and
| found on most servers by now.
| vetrom wrote:
| It's not that XMPP is hostile to power efficiency, its that
| Apple (and Google) gateway power-efficient edge triggering
| behind vendor-restricted cryptographic feature locks.
|
| They have arguably correct reasons for doing this, but it's
| a false comparison to say that the software is inefficient
| when its just as efficient that anything else at that
| privilege level on the phone can do.
| msgodel wrote:
| Nope. You can do push with XMPP just like everything else.
| The problem is that Apple _demands_ open source client
| maintainers also personally maintain infrastructure with
| high availability to handle the push notifications rather
| than allowing them to delegate that to service operators
| where it belongs.
|
| Apple is aggressively hostile to open source is the
| problem. IMO their behavior is why we don't have any nice
| open source chat apps like we did before the iPhone became
| popular.
| tharant wrote:
| I can find no such requirement in the App Store
| Guidelines. Or is there anecdotal evidence somewhere?
| msgodel wrote:
| They require push notifications to be signed with your
| certificate. You must maintain the infrastructure to do
| this yourself because you can't share the certificate
| with third parties (obviously) and downtime will mean no
| push notification delivery.
|
| I have no idea if that's in the guidelines but that's how
| it works.
| gsich wrote:
| Wrong. Apple (or Google) also use the same TCP based
| approach to maintain connectivity to allow notifications.
| No way is an extra connection responsible for bad power
| efficiency, with that small payloads. This is propaganda.
| jauntywundrkind wrote:
| Apple's implementation of Web Push Protocol is also viciously
| inconsistent. Battery efficient yes but notifications just go
| missing or show up days after they were sent. Apple really
| has a way with keeping their own special native apps and
| their own services locked in.
| WhyNotHugo wrote:
| Somewhat fuzzy on the details right now, but:
|
| You need to enable a plugin in prosody for notifications to get
| routed via Apple's servers. The plugin is disabled by default,
| but included in the default installation.
| danieldk wrote:
| We were living in the future. Around ~2010 we could use
| Jabber/XMPP to chat with people on various community services,
| Google Talk, LiveJournal talk, etc. Besides great Linux clients,
| macOS had iChat which supported XMPP, etc.
| icedchai wrote:
| I briefly worked on an XMPP client around that time. It
| cemented my opinion that the protocol was an absolute
| abomination.
| dietrichepp wrote:
| Company I worked at back then used XMPP. There was something
| that you could paste into the chat that would make all of the
| Mac clients crash, and to fix it, someone with a different
| client would have to join the chat and type a lot of comments
| to flood the history.
|
| I am not surprised to hear the protocol is an abomination.
| kentrado wrote:
| Seems like a problem with the client rather than the
| protocol.
| jauntywundrkind wrote:
| That's quite unspecific and unhelpful.
|
| Personally I find XMPP much makes sense. Sure it's this weird
| streaming XML thing, but there's a request/response pattern
| (IQ) inside that seems fine. I love how nicely it composes:
| accounts have a tree of nodes they can define for whatever
| content they want, which is a sensible & flexible base. Then
| there's pubsub, and ACL capability specs on top of that.
| Everything stacks relatively sensibly. The past decade has
| seen some good XMPP Enhancement Protocols (XEP) to create
| best practices & recommended feature sets.
|
| It was such a small jump to create a full "everything app"
| atop XMPP baseline capabilities:
|
| > _Libervia [ed: nee Salut-a-Too] is a all-in-one tool to
| manage all your communications needs: instant messaging,
| (micro)blogging, file sharing, photo albums, events, forums,
| tasks, etc._
|
| https://libervia.org/
|
| It's unfortunate that the top rated comment is uncontestable
| blanket desparagement. Can we raise this from a low criticism
| to something respect-worthy?
| icedchai wrote:
| I wasn't trying to be specific, just an opinion on what I
| experienced 10+ years ago. Others are welcome to work with
| the protocol and develop their own opinions.
| hackyhacky wrote:
| If your opinion is based on concrete experience, you
| could help people understand your position by sharing the
| specific aspects of XMPP that you dislike. An opinion
| without evidence or reasoning is not a valuable
| contribution to the conversation.
| Bjartr wrote:
| In today's world of containerization and AI powered UI
| automation, perhaps a single user-facing client could be
| viable again, powered by hidden per-service clients under
| the hood. Where each services' UI state is continually
| monitored and interacted with by an AI directed by user
| interactions in the visible interface. That would be
| against the services' ToS probably, but it could work I
| think.
|
| Who needs APIs when a computer can exploit the analog hole
| and use the same affordances as a human?
| edoceo wrote:
| A "User-Agent" if you will.
| zamadatix wrote:
| I don't think having a single user-facing client has ever
| really been held back by the technology. It's always the
| services being intentionally proprietary, intentionally
| breaking 3rd party clients, and ToSs making it risky to
| do.
| bombela wrote:
| Yep it was great. I had one client per device. Could talk to
| everybody. I had a consistent UX. Sure sharing pictures and
| videos wasn't easy then. But also the pay to use features and
| dark patterns weren't an issue either.
| c22 wrote:
| This was the high point of megaupload and bittorrent, sharing
| photos, videos, and other large files was very easy!
| bombela wrote:
| By easy I was thinking of when I merely need a long press
| on a button to record, compress and upload along side my
| message those days :)
| FuriouslyAdrift wrote:
| Trillian and Gaim... (2000 and 1999)
| johnisgood wrote:
| Now Gajim still exists and is maintained. :P
| zsiddique wrote:
| You could even use an XMPP client with HipChat for your
| business chat. Though, I'd argue XMPP was one of the factors
| that contributed to HipChat's demise (it wasn't the sole
| reason, but trying to scale presence via XMPP proved to be a
| nightmare).
| rlpb wrote:
| I've been a big XMPP fan, having deployed it at customer sites
| more than a decade ago, running my own self-hosted service for
| friends and family, and so forth.
|
| I'm disappointed that the experience is still not at feature
| parity with proprietary solutions. For example, Conversations.im
| is a great Android client for XMPP, but it still does not support
| live location.
|
| There's so much potential to be better than the proprietary
| solutions, too, for example with OsmAnd integration
| (https://codeberg.org/iNPUTmice/Conversations/issues/11).
| zie wrote:
| Interesting. I would have never thought of using XMPP to share
| location info like that.
|
| I use Overland[0] and a custom server implementation that lets
| people I care about see where my phone is(and presumably me).
|
| 0: https://overland.p3k.app
| daneel_w wrote:
| Daily user of XMPP as well since over a decade. I still call it
| Jabber out of habit. Prosody on server, Profanity on desktop
| (terminal), Monal on mobile.
| johnisgood wrote:
| Prosody vs. ejabberd?
___________________________________________________________________
(page generated 2025-07-29 23:00 UTC)