11 ms·

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 f

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. :)

mfer 5y ago
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 5y ago
  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 5y ago
    Yeah but then we gotta pay for em!
  - acdha 5y ago
    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_ 5y ago
      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 https://en.m.wikipedia.org/wiki/Web3
      - acdha 5y ago
        Yes, I've seen the marketing materials, too. The thing to think about is what you're actually using — the very next paragraph from your quote would be a good place to start: > Specific visions for Web3 differ, but all are heavily based in blockchain technologies, such as various cryptocurrencies and non-fungible tokens (NFTs). Some visions are based around the concepts of decentralized autonomous organizations (DAOs), which seek to enable many people to have equal ownership and governance in an organization. Decentralized finance (DeFi) is another key concept, in which users exchange currency without bank or government involvement. Self-sovereign identity allows users to identify themselves without relying on a centralized authentication system like OAuth. Note how the common thread is that these are all working around the scalability and reliability issues inherent to the popular blockchains. It's perhaps survivable for an identity system to be that slow when making changes if you don't do that very often, although it's definitely a risk for the overall network, but there's no way you're building an XMPP competitor on top of it even before you think about handling audio/video content, and privacy would of course preclude that as well. That means that you're really building a system which looks a lot like the competitors except using something like a wallet ID to login. Beyond being rather less disruptive than the Ethereum salespeople like to tell you, that's going to look a lot like XMPP — a traditional networked service running a protocol of some level of standardization, only with a different login option. There are some natural trends which are hard to avoid: users will gravitate to the more reliable service offered by the larger companies who can invest more time in optimization, various parties will add extensions which either aren't well documented for competitors or favor their infrastructure choices, and abuse will be a problem which leads to some combination of arbitrary moats being created or users leaving to services where they don't get spam. That last point is key: imagine if your web3 messaging startup starts to see enough usage that spammers descend en masse? Your real users will leave unless you do something about it. You can add entry fees, which will tank your user growth (which is probably already dangerously limited if you require a blockchain ID), or restrict federation to peers whom you trust to control abuse by their users.
- johnisgood 5y ago
  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/ https://f-droid.org/en/packages/eu.siacs.conversations/ [2] https://gajim.org/download/ 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/OmemoGajimPlugin https://dev.gajim.org/gajim/gajim-plugins/-/wikis/OmemoGajim....
  - Xunxi 5y ago
    The sheer amount of permissions required for Conversations is mine boggling. What's Bluetooth and WiFi permissions for?
    - johnisgood 5y ago
      You could check out the source code[1]. Check out these files: - src/main/java/eu/siacs/conversations/ui/RtpSessionActivity.java - src/main/java/eu/siacs/conversations/services/AppRTCAudioManager.java - src/main/java/eu/siacs/conversations/services/AppRTCBluetoothManager.java For the most (or all?) part it seems like it is related to Bluetooth audio. There are stuff about establishing connection to headsets and whatnot. [1] https://f-droid.org/repo/eu.siacs.conversations_42023_src.tar.gz https://f-droid.org/repo/eu.siacs.conversations_42023_src.ta...
- xiaomai 5y ago
  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.
  - oezi 5y ago
    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 5y ago
      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.
    - Groxx 5y ago
      Arguably, they were killed by the mobile platform-owners. Sending push notifications, which is broadly necessary for achieving both performance and battery efficiency, has been strictly centralized and locked down (understandably, I'd hate to try to block abuse if I were running it). Federated systems with multiple apps were pushed out because there was no sane way to achieve that with the push architecture, and that's still the case. You see the same thing with nearly any third-party app, they're nearly always partly-crippled experiences because the first-party will not send push notifications to anything but their own app.
- MattJ100 5y ago
  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/ https://snikket.org/blog/products-vs-protocols/
  - tsherr 5y ago
    This is very cool. I moved our family to signal, but this looks better. I'll be trying it out for sure.
  - derac 5y ago
    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.
    - MattJ100 5y ago
      Indeed, https://quicksy.im/ https://quicksy.im/ follows this approach, it's as trivial as it can be. My focus with Snikket is on making it as easy as possible for people to run their own server (hosted or self-hosted), and to avoid a repeat of the Google situation where 99% of the network was controlled by a single (volatile when it comes to messaging apps) entity. Snikket may not be for everyone, but that's kind of the point of XMPP. Snikket users can text and call Quicksy users with E2EE, and vice-versa, despite using two different systems.
- arendtio 5y ago
  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 5y ago
    https://snikket.org/blog/snikket-ios-public-release/ https://snikket.org/blog/snikket-ios-public-release/ - needs a prosody module for reliability though.
    - neilalexander 5y ago
      I realise it’s superficial but I took one look at the screenshots of the Snikket iOS client and thought “the person who built this has no concept of spacing, padding or text sizes”. It’s really difficult to want to use a client that looks ugly and this is where so many iOS XMPP clients seem to fall down.
      - jhugo 5y ago
        Yeah, it seems like a small thing, but this immediately put me off the first time I tried out Snikket. All the spacing and sizing just feels janky and out-of-place compared to other iOS apps.
        MattJ100 5y ago
        If aesthetics are the main issue, then that's validation that we've come a long way :) The iOS app hasn't yet been through a thorough visual review, though it is planned in the coming months (a number of fixes are already in beta builds though). Thanks for the feedback!
- rglullis 5y ago
  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 5y ago
  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.
  - xorcist 5y ago
    Google was federating from the start. Then Facebook started winning customers over, and they weren't. So Google also closed. When that happened, the writing was on the wall for XMPP at Google. If you are not federating, there's no reason to follow the spec. It's a variation of the prisoner's dilemma. If one party shares and the other doesn't, the market becomes lopsided. It's why every big permissively licensed non-copyleft product so far hasn't managed to build an ecosystem outside of a few select distributors. With protocol specifications the problem is much harder. Market dominance can be maintained by slight incompatibilities.
- syshum 5y ago
  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....
- dom96 5y ago
  There is a lot of parallels with Matrix here. I'm sad to say that the Element client just isn't polished enough to win me over Discord. Most people, including myself, don't really care about the proprietary nature of Discord. I can fairly trivially move off Discord if it fails me so I don't really see the point in working harder to use Matrix.
  - Tmpod 5y ago
    Give Cinny[1] a go. It's a new client built to be familiar to Discord users. I've switched to it as a daily driver, even tho it doesn't implement 100% the protocol. It has all the main features in a nice UI which is more than enough for me to daily drive it. [1]: https://cinny.in https://cinny.in
    - DoItToMe81 5y ago
      Cinny is pretty, but with no link previews, no video embeds, no custom emoticons, and very limited user options, you'd be quite hard pressed to get people to leave their current Matrix clients for it, let alone Discord.
    - anon9001 5y ago
      No voice channels :(
  - Yoric 5y ago
    What are you missing from Discord?
- Karrot_Kream 5y ago
  This is why I think the Matrix approach is superior. Matrix seems to prioritize features first and then makes changes to the spec based on the features to support. There's a minority that likes to criticize Matrix for this approach claiming it makes it hard for third-party implementers, but the point is that only people that write software would think about a spec first and the usecase second. No non-technical user cares.
jandrese 5y ago
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 5y ago
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.
- scott00 5y ago
  Any names you can name using federated xmpp? In my little corner of the trading world everybody seems to use either ICE Chat and/or Bloomberg. My guess would be ICE Chat is xmpp under the hood, but I don't think it's federated.
  - dogma1138 5y ago
    CME’s chat client for CME direct uses XMPP they also support connection to other XMPP servers it’s usually mostly server to server or inter domain federation tho (can’t login with just any set of credentials but you can talk to other firms), CME is or at least was interconnected with other financial messenger services like Eikon/Reuters Messenger which is also based on XMPP. And there are federated networks like the one from Markit https://www.businesswire.com/news/home/20131007005587/en/Global-Financial-Services-Firms-Join-New-Open-Messaging-Network https://www.businesswire.com/news/home/20131007005587/en/Glo... I don’t think there is a single major financial messenger today that isn’t based on XMPP.
sneak 5y ago
> The issue we ran into was customers/consumers just didn't care about federated systems. Quite the opposite: users actively do not want federated systems, as federated systems allow anyone on the internet to spam them. This is why Google Talk stopped supporting federation: 99.9%+ of users never used it to talk outside of Google instances, and 99.9%+ of the inbound messages from the outside world were spam.
- wahern 5y ago
  The spam problem was exaggerated and used as an excuse to avoid FTC scrutiny. Even if 99.9% of federated inbound messages were spam, that doesn't mean it all reached the client. Most e-mail is spam but very little makes it to the user. (AFAIU, the primary motivations were 1) lack of MSN reciprocity, and 2) Google's endless dithering and floundering attempts to capture users the same way Facebook, WhatsApp, etc had and/or were going to.) Large walled garden IM platforms have the spam problem potential. It's solved by using whitelists (via invites) instead of blacklists. The same mechanism is trivial to accomplish using XMPP, and I'm sure there are already XEPs for that. (Multiple, even!) You can end up with invite spam, but that's exactly the problem you see on Facebook, WhatsApp, etc. As for me, I ran my own XMPP server for years along side an SMTP server and never received XMPP spam. Both my XMPP and e-mail addresses were the same, and my e-mail address had been in use since circa 2000 and exists on countless spam lists. I doubt the spam problem could have been very significant. I never used a GMail or GTalk address, but of the people I know who did, some of whom I chatted with over federation, I never once heard of GTalk spam. Anybody who cares about privacy should care about federation and should advocate for federation. Being cynical about the potential is counterproductive. If you think federation is impractical because centralization is required to prevent abuse, then you must admit that privacy beyond the current status quo is also impractical; just give up. If you don't want to give up on privacy, don't give up on federation. The technical problems to federation will never go away, but the will to solve them is entirely voluntary. (Though, if we legally mandate federation then that's at least a substantial, long-term commitment.)
- Semaphor 5y ago
  I have used XMPP since forever, and actively used it for GTalk federation. I don’t think I remember any spam messages, but there might have been one or two. Facebook/Messenger? Not a week goes by without some sexy lady wanting to have intercourse with me. This does not seem like it’s a federation issue.
cletus 5y ago
Two things spring to mind reading this. First, I can't remember who said it but there's a quote that goes something like (paraphrased) "open standards are for losers" (side note: if anyone has the original quote, please let me know). It's a pithy way of pointing out that the winners in any market don't care. Others want open standards to level the playing field. Second, and I can't stress this enough, literally nobody wants federated systems apart from a handful techno-enthusiasts. It doesn't solve any problem users care about. In fact, it tends to create problems users do care about. Look no further than the POTS system. Part of the reason you have spam and robocalls is one provider is pretty much free to send or forward traffic to anyone and to essentially spoof the sender such that things like caller ID do very little. Plus there's all the routing issues. Users tend to want to keep their numbers so you can't use a phone number as an identifier anymore. You have to use something lower level (think of this as the difference between a domain name and an IP address) and then deal with all the porting issues and the security issues that creates (eg SIM jacking).
- zhte415 5y ago
  Yes -- if you want a good open data system, you're in a bad place. As long as people continue to use the Internet for their own benefit, that's fine. The internet that will be the ultimate "open standard" for the masses of people.
- GoblinSlayer 5y ago
  That's because with proprietary standards users are losers, and open standards try to fix that.
hnlmorg 5y ago
I tried to run an open source community on XMPP at around the same time and found it equally crap. The XML schema felt bloated (baring in mind a lot of people were still on dial up, and later the data caps of early feature/smart phones), chat client support was rubbish, linking to other servers was non-trivial (they'd often be running extensions you weren't. In fact the whole extension system was broken). And IIRC the leading XMPP server was written in Haskell and the only way to configure it was to edit the source. It was just a horrible experience all round. I had Skype, MSN, AOL IM, IRC, and another (possibly IRQ?) all linked together -- most of which are proprietary -- under one server and the only protocol I couldn't get working properly was XMPP. Which really says a lot about the state of XMPP at that time. Maybe things have improved. But now that Google Talk, Facebook Messenger and others don't use XMPP any more, there is even less reason to bother trying.
- topdancing 5y ago
  The only other reference I can find to a Haskell XMPP server is your other comment at https://news.ycombinator.com/item?id=27297137 https://news.ycombinator.com/item?id=27297137 Suffice to say; go and download a modern client like conversations.im and install ejabberd.im on a machine somewhere (or just use a throwaway account on a public server). The ecosystem has significantly improved since you last tried it... 15-20 years ago?
  - hnlmorg 5y ago
    I'd already answered why I haven't > Maybe things have improved. But now that Google Talk, Facebook Messenger and others don't use XMPP any more, there is even less reason to bother trying. There's no shortage of chat protocols out there. As far as I'm concerned XMPP had it's chance and failed to deliver. While I'm not a fan of NIH (not invented here) syndrome, I'm even less of a fan of polishing a turd, because that's what leads us to monstrosities like STARTTLS, FTPES and so on and so forth.
    - topdancing 5y ago
      I saw that, and it's simply a ridiculous and narrow minded viewpoint (even more so giving you're judging on purely historical data). I myself have rediscovered XMPP in the past two years (whilst using other tools like Matrix for other roles). The experience has revolutionized the way I view chats apps and even I host my own server on my own bare metal. The thing quite simply flies and is rock solid. I've also seen multihour WhatsApp and Signal outages go by whereas my friends and I have kept chatting on my reliable server. Never had an issue with STARTTLS. XMPP has silently evolved with the times and is far better than ever and should simply be the go to if you want to have control over your own comms.
e12e 5y ago
It's a little odd. Facebook and Google talk both allowed use of standard xmpp clients when they were using xmpp underneath - so one could get away with a single app to talk to people over xmpp, Facebook chat and gtalk. And eg OTR worked fine. But both Facebook and Google refused federation, and then phased out xmpp. I assume all the big players are equally eager to kill email, but haven't quite figured out how yet.

mfer 5y ago

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 5y ago
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 5y ago
  Yeah but then we gotta pay for em!
- acdha 5y ago
  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_ 5y ago
    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 https://en.m.wikipedia.org/wiki/Web3
    - acdha 5y ago
      Yes, I've seen the marketing materials, too. The thing to think about is what you're actually using — the very next paragraph from your quote would be a good place to start: > Specific visions for Web3 differ, but all are heavily based in blockchain technologies, such as various cryptocurrencies and non-fungible tokens (NFTs). Some visions are based around the concepts of decentralized autonomous organizations (DAOs), which seek to enable many people to have equal ownership and governance in an organization. Decentralized finance (DeFi) is another key concept, in which users exchange currency without bank or government involvement. Self-sovereign identity allows users to identify themselves without relying on a centralized authentication system like OAuth. Note how the common thread is that these are all working around the scalability and reliability issues inherent to the popular blockchains. It's perhaps survivable for an identity system to be that slow when making changes if you don't do that very often, although it's definitely a risk for the overall network, but there's no way you're building an XMPP competitor on top of it even before you think about handling audio/video content, and privacy would of course preclude that as well. That means that you're really building a system which looks a lot like the competitors except using something like a wallet ID to login. Beyond being rather less disruptive than the Ethereum salespeople like to tell you, that's going to look a lot like XMPP — a traditional networked service running a protocol of some level of standardization, only with a different login option. There are some natural trends which are hard to avoid: users will gravitate to the more reliable service offered by the larger companies who can invest more time in optimization, various parties will add extensions which either aren't well documented for competitors or favor their infrastructure choices, and abuse will be a problem which leads to some combination of arbitrary moats being created or users leaving to services where they don't get spam. That last point is key: imagine if your web3 messaging startup starts to see enough usage that spammers descend en masse? Your real users will leave unless you do something about it. You can add entry fees, which will tank your user growth (which is probably already dangerously limited if you require a blockchain ID), or restrict federation to peers whom you trust to control abuse by their users.
johnisgood 5y ago
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/ https://f-droid.org/en/packages/eu.siacs.conversations/ [2] https://gajim.org/download/ 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/OmemoGajimPlugin https://dev.gajim.org/gajim/gajim-plugins/-/wikis/OmemoGajim....
- Xunxi 5y ago
  The sheer amount of permissions required for Conversations is mine boggling. What's Bluetooth and WiFi permissions for?
  - johnisgood 5y ago
    You could check out the source code[1]. Check out these files: - src/main/java/eu/siacs/conversations/ui/RtpSessionActivity.java - src/main/java/eu/siacs/conversations/services/AppRTCAudioManager.java - src/main/java/eu/siacs/conversations/services/AppRTCBluetoothManager.java For the most (or all?) part it seems like it is related to Bluetooth audio. There are stuff about establishing connection to headsets and whatnot. [1] https://f-droid.org/repo/eu.siacs.conversations_42023_src.tar.gz https://f-droid.org/repo/eu.siacs.conversations_42023_src.ta...
xiaomai 5y ago
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.
- oezi 5y ago
  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 5y ago
    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.
  - Groxx 5y ago
    Arguably, they were killed by the mobile platform-owners. Sending push notifications, which is broadly necessary for achieving both performance and battery efficiency, has been strictly centralized and locked down (understandably, I'd hate to try to block abuse if I were running it). Federated systems with multiple apps were pushed out because there was no sane way to achieve that with the push architecture, and that's still the case. You see the same thing with nearly any third-party app, they're nearly always partly-crippled experiences because the first-party will not send push notifications to anything but their own app.
MattJ100 5y ago
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/ https://snikket.org/blog/products-vs-protocols/
- tsherr 5y ago
  This is very cool. I moved our family to signal, but this looks better. I'll be trying it out for sure.
- derac 5y ago
  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.
  - MattJ100 5y ago
    Indeed, https://quicksy.im/ https://quicksy.im/ follows this approach, it's as trivial as it can be. My focus with Snikket is on making it as easy as possible for people to run their own server (hosted or self-hosted), and to avoid a repeat of the Google situation where 99% of the network was controlled by a single (volatile when it comes to messaging apps) entity. Snikket may not be for everyone, but that's kind of the point of XMPP. Snikket users can text and call Quicksy users with E2EE, and vice-versa, despite using two different systems.
arendtio 5y ago
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 5y ago
  https://snikket.org/blog/snikket-ios-public-release/ https://snikket.org/blog/snikket-ios-public-release/ - needs a prosody module for reliability though.
  - neilalexander 5y ago
    I realise it’s superficial but I took one look at the screenshots of the Snikket iOS client and thought “the person who built this has no concept of spacing, padding or text sizes”. It’s really difficult to want to use a client that looks ugly and this is where so many iOS XMPP clients seem to fall down.
    - jhugo 5y ago
      Yeah, it seems like a small thing, but this immediately put me off the first time I tried out Snikket. All the spacing and sizing just feels janky and out-of-place compared to other iOS apps.
      - MattJ100 5y ago
        If aesthetics are the main issue, then that's validation that we've come a long way :) The iOS app hasn't yet been through a thorough visual review, though it is planned in the coming months (a number of fixes are already in beta builds though). Thanks for the feedback!
rglullis 5y ago
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 5y ago
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.
- xorcist 5y ago
  Google was federating from the start. Then Facebook started winning customers over, and they weren't. So Google also closed. When that happened, the writing was on the wall for XMPP at Google. If you are not federating, there's no reason to follow the spec. It's a variation of the prisoner's dilemma. If one party shares and the other doesn't, the market becomes lopsided. It's why every big permissively licensed non-copyleft product so far hasn't managed to build an ecosystem outside of a few select distributors. With protocol specifications the problem is much harder. Market dominance can be maintained by slight incompatibilities.
syshum 5y ago
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....
dom96 5y ago
There is a lot of parallels with Matrix here. I'm sad to say that the Element client just isn't polished enough to win me over Discord. Most people, including myself, don't really care about the proprietary nature of Discord. I can fairly trivially move off Discord if it fails me so I don't really see the point in working harder to use Matrix.
- Tmpod 5y ago
  Give Cinny[1] a go. It's a new client built to be familiar to Discord users. I've switched to it as a daily driver, even tho it doesn't implement 100% the protocol. It has all the main features in a nice UI which is more than enough for me to daily drive it. [1]: https://cinny.in https://cinny.in
  - DoItToMe81 5y ago
    Cinny is pretty, but with no link previews, no video embeds, no custom emoticons, and very limited user options, you'd be quite hard pressed to get people to leave their current Matrix clients for it, let alone Discord.
  - anon9001 5y ago
    No voice channels :(
- Yoric 5y ago
  What are you missing from Discord?
Karrot_Kream 5y ago
This is why I think the Matrix approach is superior. Matrix seems to prioritize features first and then makes changes to the spec based on the features to support. There's a minority that likes to criticize Matrix for this approach claiming it makes it hard for third-party implementers, but the point is that only people that write software would think about a spec first and the usecase second. No non-technical user cares.

jandrese 5y ago

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 5y ago

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.

scott00 5y ago
Any names you can name using federated xmpp? In my little corner of the trading world everybody seems to use either ICE Chat and/or Bloomberg. My guess would be ICE Chat is xmpp under the hood, but I don't think it's federated.
- dogma1138 5y ago
  CME’s chat client for CME direct uses XMPP they also support connection to other XMPP servers it’s usually mostly server to server or inter domain federation tho (can’t login with just any set of credentials but you can talk to other firms), CME is or at least was interconnected with other financial messenger services like Eikon/Reuters Messenger which is also based on XMPP. And there are federated networks like the one from Markit https://www.businesswire.com/news/home/20131007005587/en/Global-Financial-Services-Firms-Join-New-Open-Messaging-Network https://www.businesswire.com/news/home/20131007005587/en/Glo... I don’t think there is a single major financial messenger today that isn’t based on XMPP.

sneak 5y ago

> The issue we ran into was customers/consumers just didn't care about federated systems. Quite the opposite: users actively do not want federated systems, as federated systems allow anyone on the internet to spam them. This is why Google Talk stopped supporting federation: 99.9%+ of users never used it to talk outside of Google instances, and 99.9%+ of the inbound messages from the outside world were spam.

wahern 5y ago
The spam problem was exaggerated and used as an excuse to avoid FTC scrutiny. Even if 99.9% of federated inbound messages were spam, that doesn't mean it all reached the client. Most e-mail is spam but very little makes it to the user. (AFAIU, the primary motivations were 1) lack of MSN reciprocity, and 2) Google's endless dithering and floundering attempts to capture users the same way Facebook, WhatsApp, etc had and/or were going to.) Large walled garden IM platforms have the spam problem potential. It's solved by using whitelists (via invites) instead of blacklists. The same mechanism is trivial to accomplish using XMPP, and I'm sure there are already XEPs for that. (Multiple, even!) You can end up with invite spam, but that's exactly the problem you see on Facebook, WhatsApp, etc. As for me, I ran my own XMPP server for years along side an SMTP server and never received XMPP spam. Both my XMPP and e-mail addresses were the same, and my e-mail address had been in use since circa 2000 and exists on countless spam lists. I doubt the spam problem could have been very significant. I never used a GMail or GTalk address, but of the people I know who did, some of whom I chatted with over federation, I never once heard of GTalk spam. Anybody who cares about privacy should care about federation and should advocate for federation. Being cynical about the potential is counterproductive. If you think federation is impractical because centralization is required to prevent abuse, then you must admit that privacy beyond the current status quo is also impractical; just give up. If you don't want to give up on privacy, don't give up on federation. The technical problems to federation will never go away, but the will to solve them is entirely voluntary. (Though, if we legally mandate federation then that's at least a substantial, long-term commitment.)
Semaphor 5y ago
I have used XMPP since forever, and actively used it for GTalk federation. I don’t think I remember any spam messages, but there might have been one or two. Facebook/Messenger? Not a week goes by without some sexy lady wanting to have intercourse with me. This does not seem like it’s a federation issue.

cletus 5y ago

Two things spring to mind reading this. First, I can't remember who said it but there's a quote that goes something like (paraphrased) "open standards are for losers" (side note: if anyone has the original quote, please let me know). It's a pithy way of pointing out that the winners in any market don't care. Others want open standards to level the playing field. Second, and I can't stress this enough, literally nobody wants federated systems apart from a handful techno-enthusiasts. It doesn't solve any problem users care about. In fact, it tends to create problems users do care about. Look no further than the POTS system. Part of the reason you have spam and robocalls is one provider is pretty much free to send or forward traffic to anyone and to essentially spoof the sender such that things like caller ID do very little. Plus there's all the routing issues. Users tend to want to keep their numbers so you can't use a phone number as an identifier anymore. You have to use something lower level (think of this as the difference between a domain name and an IP address) and then deal with all the porting issues and the security issues that creates (eg SIM jacking).

zhte415 5y ago
Yes -- if you want a good open data system, you're in a bad place. As long as people continue to use the Internet for their own benefit, that's fine. The internet that will be the ultimate "open standard" for the masses of people.
GoblinSlayer 5y ago
That's because with proprietary standards users are losers, and open standards try to fix that.

hnlmorg 5y ago

I tried to run an open source community on XMPP at around the same time and found it equally crap. The XML schema felt bloated (baring in mind a lot of people were still on dial up, and later the data caps of early feature/smart phones), chat client support was rubbish, linking to other servers was non-trivial (they'd often be running extensions you weren't. In fact the whole extension system was broken). And IIRC the leading XMPP server was written in Haskell and the only way to configure it was to edit the source. It was just a horrible experience all round. I had Skype, MSN, AOL IM, IRC, and another (possibly IRQ?) all linked together -- most of which are proprietary -- under one server and the only protocol I couldn't get working properly was XMPP. Which really says a lot about the state of XMPP at that time. Maybe things have improved. But now that Google Talk, Facebook Messenger and others don't use XMPP any more, there is even less reason to bother trying.

topdancing 5y ago
The only other reference I can find to a Haskell XMPP server is your other comment at https://news.ycombinator.com/item?id=27297137 https://news.ycombinator.com/item?id=27297137 Suffice to say; go and download a modern client like conversations.im and install ejabberd.im on a machine somewhere (or just use a throwaway account on a public server). The ecosystem has significantly improved since you last tried it... 15-20 years ago?
- hnlmorg 5y ago
  I'd already answered why I haven't > Maybe things have improved. But now that Google Talk, Facebook Messenger and others don't use XMPP any more, there is even less reason to bother trying. There's no shortage of chat protocols out there. As far as I'm concerned XMPP had it's chance and failed to deliver. While I'm not a fan of NIH (not invented here) syndrome, I'm even less of a fan of polishing a turd, because that's what leads us to monstrosities like STARTTLS, FTPES and so on and so forth.
  - topdancing 5y ago
    I saw that, and it's simply a ridiculous and narrow minded viewpoint (even more so giving you're judging on purely historical data). I myself have rediscovered XMPP in the past two years (whilst using other tools like Matrix for other roles). The experience has revolutionized the way I view chats apps and even I host my own server on my own bare metal. The thing quite simply flies and is rock solid. I've also seen multihour WhatsApp and Signal outages go by whereas my friends and I have kept chatting on my reliable server. Never had an issue with STARTTLS. XMPP has silently evolved with the times and is far better than ever and should simply be the go to if you want to have control over your own comms.

e12e 5y ago

It's a little odd. Facebook and Google talk both allowed use of standard xmpp clients when they were using xmpp underneath - so one could get away with a single app to talk to people over xmpp, Facebook chat and gtalk. And eg OTR worked fine. But both Facebook and Google refused federation, and then phased out xmpp. I assume all the big players are equally eager to kill email, but haven't quite figured out how yet.