12 ms·

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

by 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.
      - GoblinSlayer 5y ago
        Crypto's target audience is cyberpunks, how do you expect those people to accept a walled garden solution? And spammers are already on the big tech platforms and nobody leaves those.
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.

by mfer 5y ago

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.
    - GoblinSlayer 5y ago
      Crypto's target audience is cyberpunks, how do you expect those people to accept a walled garden solution? And spammers are already on the big tech platforms and nobody leaves those.

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.