[HN Gopher] Ask HN: Why XMPP failed and SMTP didn't?
___________________________________________________________________
Ask HN: Why XMPP failed and SMTP didn't?
I was born too late to witness popularity of XMPP as a
decentralized instant messaging protocol. When I started to be a
"conscious" user of the Internet, such services already became
centralized, so I don't really remember those times. As I follow
the development of projects like Matrix, I wonder what has made
SMTP such a stable protocol that has stood the test of time and
what is the real reason we don't use XMPP (I mean, we do using
Whatsapp, but as a part of closed ecosystem). Is it only that XMPP
was overcomplicated and if managed better it would survive? Or is
it something else?
Author : kertoip_1
Score : 85 points
Date : 2022-05-26 14:57 UTC (8 hours ago)
| tapoxi wrote:
| I was a weird XMPP nerd in high school and tried to switch
| friends from AIM. So here's my experience.
|
| * Onboarding was difficult. There was no obvious choice of server
| or client to use.
|
| * Adding friends was difficult. You needed to send a subscription
| request to a contact, and they needed to send one to you. If
| anything happened during this process, you couldn't chat.
|
| * Popular XMPP clients, like Pidgin, also supported the other
| chat services (AIM, ICQ, MSN, Yahoo, etc) so people just
| continued using those.
|
| * Network effect. You need to convince a mass of people its
| better, otherwise nobody's using it because no-one uses it.
|
| * No obvious benefit to the user. It's decentralized sure, but
| there weren't many improvements over AIM that people actually
| used.
|
| * A lack of good iPhone XMPP clients.
|
| In 2005 Google added XMPP support to Google Talk/GMail Chat and
| they were federated, but nobody federated back and they closed
| off its successor (Hangouts).
| ethn wrote:
| I thought it was pretty easy to use using Pidgin.
| metajack wrote:
| > In 2005 Google added XMPP support to Google Talk/GMail Chat
| and they were federated, but nobody federated back and they
| closed off its successor (Hangouts).
|
| I don't think "lack of federation back" was a big driver in
| this decision. Everyone who used XMPP was able to chat with
| gchat folks and despite some weird changes Google made to their
| integration, it worked reasonably well. You didn't need to do
| anything special to federate with another XMPP server. It just
| worked like email does.
|
| I expect either product complexity (like having to support non-
| gchat addressing which then requires full JIDs instead of short
| names) or de-prioritizing features that weren't directly
| driving their growth thesis were probably more relevant. Ie,
| why spend two engineers to fix integration concerns and deal
| with federation everywhere, when you can just retask those
| headcount onto some new feature that will drive growth.
| tapoxi wrote:
| I really mean that no other big chat service federated back.
| The global network of federated XMPP servers was dwarfed by
| Google's userbase. Maybe if AIM/MSN/Yahoo added an XMPP
| bridge they would have kept it.
| als0 wrote:
| Wasn't Facebook Chat a big one?
| prash_ant wrote:
| Yes: https://news.ycombinator.com/item?id=9266769
| Macha wrote:
| Was Facebook messenger ever _federated_ though, like
| GChat was? You could use an XMPP client with messenger,
| but you couldn't talk to people on other XMPP servers
| like you could with Google Talk, from my recollection.
| yepguy wrote:
| I seem to recall there was a brief period of time when
| gchat federated with both XMPP and AIM, and I was using
| Gajim to chat with users from both of those services
| without a bridge (or at least, the bridge run by Google/AOL
| was invisible to me).
| verelo wrote:
| This is a dumb questions, please excuse the ignorance: Why
| were/are there not (or are there?) adapters so that you can
| speak whatever protocol you prefer (smtp, xmpp x.400 etc) but
| it still gets through to the user on the other end?
| metajack wrote:
| There is a long history of this including multi-protocol
| clients. You see this now for example as people want a single
| "chat" for the many places they publish live streams (twitch,
| youtube, discord, etc). Unfortunately, because you must
| ultimately support the lowest common denominator you end up
| with much of the nice features of particular platforms being
| unavailable or things like the youtube chat filled with
| comments like `@comment-copy-bot: James (Discord): That was a
| cool video!` and things like direct messages and emotes don't
| really work.
| MattJ100 wrote:
| That's exactly what XMPP was originally created for - a
| single open protocol that would let you interface with all
| the others.
|
| But it's very hard, technically, to maintain interfaces to a
| changing set of evolving third-party protocols, and provide a
| good user experience. Especially if those people don't want
| you bridging to them. Open networks tend to fare better in
| the long term, but generally the user experience of an app
| bespoke for the target protocol is nearly always better.
| zokier wrote:
| XMPP has explicit support for "transports"/"gateways" for
| that purpose, so you could plug in AIM/ICQ/whatev support
| into your XMPP server. See
| https://spectrum.im/documentation/about.html for example.
|
| IRC has bitlbee (and probably others) to fulfill that role
| https://www.bitlbee.org/main.php/news.r.html
|
| Matrix has "bridges" to interop with other protocols
| https://matrix.org/bridges/
| teakettle42 wrote:
| > A lack of good iPhone XMPP clients.
|
| As someone whose company used XMPP prior to the iPhone, this is
| what killed it for us, and I suspect it's a major contributor
| to federated XMPP losing any public inertia it had.
|
| iPhone push notifications could only be sent with a signing key
| tied to the same developer account as used to publish the
| client application.
|
| That meant it was impossible to send push notifications from
| your own XMPP server to a generic XMPP client written by
| someone else.
| solar-ice wrote:
| FWIW, this eventually got solved in XEP-0357, which, while it
| says it's deferred, is actually implemented by common mobile
| clients and modules exist for both common server
| implementations. This is the same design that Matrix
| eventually borrowed to solve the same problem.
| lukasb wrote:
| Fascinating. Is this problem solved for Mastodon?
| als0 wrote:
| This restriction that push notifications must only come
| from the developer's server is a restriction imposed by
| Apple and their App Store.
| mjevans wrote:
| A solution would be E.G. subscribing to a community (an
| endpoint URL, or what Discord likes to brainwash
| consumers by calling a 'server') should trigger
| background actions that allow that community's chosen
| point of contact to have push notification capabilities,
| and to maintain that forward until your subscription is
| expired.
| throwaway92394 wrote:
| > should trigger background actions
|
| Because of the way iOS works nowadays, you cannot
| reliably do this for notifications because you can't run
| apps in the background reliably for this purpose.
|
| > allow that community's chosen point of contact to have
| push notification capabilities
|
| This is what push notifications are?
| mjevans wrote:
| Not device background. IE submit requests to the iOS
| mothership and to the endpoint URL to talk to each other
| and work things out.
| throwaway92394 wrote:
| I apologize I'm not sure what you mean by mothership,
| I'll assume you mean the core API's the OS presents. I
| mean that's how requests already work? You ask the system
| to handle the network for you and it passes the app data?
|
| In the context of notifications this isn't an issue for
| when the app is in the foreground. But when it's in the
| background the app's event loop isn't ran consistently,
| so you might not get the notification for hours. To my
| knowledge the ONLY way to consistently push notifications
| for apps in the background is through apple's push
| gateways.
| mjevans wrote:
| An __off device__ request that is processed server to
| server.
|
| Mobiles aren't "real computers" in the sense of the
| Internet. They are not intended to be always on; nor
| always connected from a stable address. They are portable
| (very smart) terminals, often with poor text input (but
| usually with reasonable quality camera and microphones),
| and often a large local cache.
| LinAGKar wrote:
| Presumably you can do like Matrix, and have the developer
| of the app run a push gateway.
| MattJ100 wrote:
| Exactly, that's how XMPP does it too. Since
| authentication to the OS vendor APIs are generally linked
| to the developer's account, that's basically the only
| practical way to do it.
| zaik wrote:
| It is solved for XMPP as well:
| https://xmpp.org/extensions/xep-0357.html
| GekkePrutser wrote:
| > A lack of good iPhone XMPP clients
|
| And no server based push, though I'm sure someone invented an
| xmpp extension to fix that eventually :)
| GekkePrutser wrote:
| Tbh I wish SMTP had died a long time ago. It's the reason email
| is so terribly broken. We can't trust a sender is who they say
| they are. We can't stop spammers, we can't hide personal info,
| there is no e2e encryption. As a result everyone is afraid of
| clicking on links and companies no longer send confidential info
| through it. It's just a fancy notification service now ("there's
| a message waiting for you at our portal" crap). I understand why
| they do it but it's really poor UX having to log into portals
| just to read a message.
|
| Of all the original internet protocols, SMTP is the ice that
| needs replacement the most IMO.
| rglullis wrote:
| If there is one practice that I'd like to see more encouraged,
| it would be for websites to start giving other forms of account
| verification beyond "we will send you an email". Zoom bought
| keybase, why couldn't push for a "login with keybase"? Why
| can't sites send a link via matrix/xmpp/whatsapp/signal
| message? The only service I've used so far doing it is njal.la.
| l72 wrote:
| I prefer email but why can't it be encrypted. Why can't I log
| into my bank and optionally upload my pgp public key?
| TillE wrote:
| Because given the rest of the software ecosystem available,
| maybe 0.01% of their customers would ever use such a
| feature.
|
| It's way easier to just properly secure website logins with
| any number of 2FA methods, and rely on good old TLS for
| your encryption.
| cryptonector wrote:
| SMTP doesn't really prevent end-to-end crypto for email.
| There's a lot of reasons why that's hard that have nothing to
| do with SMTP: - multiple devices sharing a
| mailbox - store in plaintext? - if store in
| ciphertext, how to index, search? - how to share
| decryption, signing keys among devices? - how to enroll
| devices? - how to exchange keys?
|
| These problems are easier to solve for IM because it's
| interactive, not store-and-forward.
| layer8 wrote:
| In spite of all the valid criticism, we still got lucky that we
| ended up having this nonproprietary, decentralized, universally
| supported medium called email. A large number of businesses
| still (and will continue) to run on email, as does a certain
| subset of open source and other projects (using mailing lists).
|
| > companies no longer send confidential info through it.
|
| It depends, B2B absolutely still do.
| taway2022-05-26 wrote:
| I'm glad that you have learned of the brief golden age of online
| communication. I had friends on 6 different services and used
| Trillian, Pidgin, etc to talk to them all. Somehow we have to
| escape these walled gardens and get back to that borderless
| world.
|
| At work (operations for a space mission), we use an XMPP-based
| chat system for tactical communications along with several other
| systems, but Slack was introduced and more and more communcations
| are being handled over Slack. I'm advocating for replacing
| several systems with Jitsi, which is XMPP-based, because it
| allows us better control and customizability. It's an uphill
| battle.
| badrabbit wrote:
| Timing and demand. For many, the cost does not outweigh the
| benefit. Migration is a b**.
| Zash wrote:
| How can XMPP have failed when I and many others use it daily?
| When many things like Snikket and Zoom and WhatsApp are built on
| it?
| spicybright wrote:
| I think the argument for failure is because barely anyone is
| using it directly with an XMPP client. But as a back end layer
| for other platforms, it's a smashing success.
|
| According to the XMPP offical website to add some numbers to
| what you mentioned: ~800 million WhatsApp
| ~200 million Zoom ~4 million Grindr
|
| Matrix is also (one of) the more popular decentralized chat
| platform, which is built on XMPP.
|
| I wouldn't at all be surprised if there's chat services that
| have you connect your local app with XMPP to, and get a simple
| UI layer that only connects to specific servers and other
| provides other config settings.
|
| I've also heard of other uses besides chat, like for server
| management or video game multiplayer games for example. It's a
| great protocol that's provides delivery logic, accounts, etc.
| but keeps the actual messages simple and flexible for whatever
| you want to do.
|
| I think SMTP "won" from being focused on email management
| instead of a more general protocol for multiple uses. (not that
| you can't do wacky things with SMTP, of course)
| OrvalWintermute wrote:
| XMPP is in actually in Cisco VOIP too, and that Cisco VOIP
| Unified Communications [1] stuff is incredibly popular.
|
| The client side Cisco Jabber app is Cisco's version of it
| that works with their VOIP.
|
| Believe it is both Client & Server, and that is an
| interoperable implementation that looks like a reskinned
| pidgin somewhat in older versions, but has a great deal more
| functionality now, and looks capable of doing VTC and other
| things [2]
|
| Considering how popular Cisco VOIP is, I think lots more
| people have XMPP functionality than they realize
|
| [1] https://www.cisco.com/c/en/us/products/unified-
| communication...
|
| [2] https://www.cisco.com/c/en/us/products/unified-
| communication...
| zaik wrote:
| > Matrix [...] built on XMPP.
|
| Matrix is not built on any existing Internet Standards for
| messaging and is not compatible with XMPP in a meaningful
| way.
| bombcar wrote:
| They may use the protocol but it's not interoperable - you
| can't chat with someone on Zoom from WhatsApp; that's what
| people mean by "it failed".
| hkt wrote:
| His other example, Snikket, is self hostable and
| interoperable with the wider xmpp world. The pattern is
| largely related to companies wanting to build walled gardens.
| On that basis, most open source tech has "failed" in the
| sense of having created greater value in VC backed companies
| with marketing departments than in communities without them.
| It isn't really surprising that it works that way, and IMHO
| it isn't failure.
| bombcar wrote:
| That's really the key and the end of it - SMTP was big
| enough that all the companies _had_ to work with it, even
| the ones that originally wanted to walled garden (Lotus
| Notes and Microsoft Exchange are two big names, even now
| Exchange still has X500 stuff in there).
|
| The closest thing to that which chat has is text messaging,
| and I'm honestly surprised that MORE platforms don't have a
| text messaging "bridge" of sorts.
| bradyd wrote:
| WhatsApp switched to the Signal protocol several years ago.
| zaik wrote:
| Signal protocol refers to a cryptographic protocol not a
| messaging protocol. XMPP also has an Signal protocol
| implementation called OMEMO.
| egberts1 wrote:
| Only for two-way chat, plus the default is still not
| encrypted (using Signal protocol) for WhatsApp.
|
| In short, data-at-rest still can remains unencrypted for
| majority of the messagings on the WhatsApp's server for all
| those who may be interested in them ... UNLESS you enabled
| Signal/Encrypted option for two-way.
|
| Group chat for WhatsApp?, it's still the proverbial pants'
| down.
| xico wrote:
| No. All communications in WhatsApp are encrypted end to
| end, whether between 2 persons, or inside a group [1].
|
| I believe you are referring to Telegram which does not use
| encryption by default.
|
| [1] https://www.whatsapp.com/security/WhatsApp-Security-
| Whitepap...
| spicybright wrote:
| Signal as in the chat platform? Fantastic if so.
| LinuxBender wrote:
| SMTP was already entrenched in business uses and thus will
| survive for some time. XMPP was used by some chat servers. I used
| XMPP/Jabber in a company but we could have easily switched to
| something else such as IRC or NNTP. Moving off SMTP would be a
| non starter for most businesses.
|
| If there were an alternative to SMTP I believe it would be NNTP
| given it is similar in concept and just introduces threaded
| messaging which SMTP clients try to mimic now. There are several
| potential rabbit hole discussions of why moving away from SMTP
| are highly unlikely to ever occur.
| jasode wrote:
| _> , I wonder what has made SMTP such a stable protocol that has
| stood the test of time and what is the real reason we don't use
| XMPP_
|
| There are probably multiple reasons and we can't replay history
| to know which reason contributes the most but one key difference
| is that email accounts (SMTP) were _pushed_ onto the regular non-
| techie consumers whereas XMPP was more of a geek tool that users
| had to _pull_ and opt into.
|
| E.g. New students at a university automatically got a ".edu"
| email address. Residents got a free email account (ISP) with
| their cable service. Employees got a corporate email address. In
| other words, millions _effortlessly_ got the utility of email
| /SMTP even without installing AOL CDROMS.
|
| To further reinforce email/STMP, if consumers want to order
| something from Amazon, they needed an _email address_ to create
| an account instead of an XMPP address.
|
| Other forms of communication like XMPP/IRC don't have that
| _widely disseminated_ self-reinforcing utility cycle so they stay
| a niche tool. What critical service in normal life requires an
| XMPP address? I can 't think of any.
| wruza wrote:
| But SMTP also failed in a sense (and for the same reason). Big
| mail services may use it internally, but try to spin up your own
| mail server reliably.
| 0xbadcafebee wrote:
| It's mainly because XMPP is overcomplicated, but also they're for
| different use cases.
|
| XMPP: - is designed for chatting and P2P and VoIP
| over persistent HTTP connections - requires everyone to be
| online - servers have to implement 50 different specs
| - works at the frontend and backend
|
| SMTP: - is designed to send one large message in
| bulk over a regular short-lived TCP session - is a store-
| and-forward messaging system, highly resilient to slow or
| inconsistent networks and server issues - is simple and the
| ecosystem is layered, so the core server doesn't have to
| implement a dozen specs - is practically backend-only
|
| The difference between "Can you hear me now?", and putting a
| letter in the mail.
| hkt wrote:
| This isn't really accurate: xmpp isn't p2p, it is hub and
| spoke. All comms (except optionally some VoIP and file
| transfers) go through the server. XMPP can also do store and
| forward pretty easily with common server addons.
|
| I'd not really describe it as fragile or bloated either, having
| used it for twenty years or so with no real problems except the
| now-solved absence of e2e encryption (OTR, OMEMO).
|
| Still, clients could be better.
| 0xbadcafebee wrote:
| What an XMPP server supports: - XML -
| XHTML - vCard - Bookmarks - Message Archive
| - P2P - VoIP - Multi-user Chat - File
| Transfer - Data Forms - Service Discovery -
| Pub-Sub & Personal Eventing - Bidirectional Synchronous
| HTTP Streams - WebSockets - Push Notification
| - Protocol Gateways - TLS - OTR - PGP
|
| What an SMTP server supports: - SMTP -
| TLS
|
| 175 XMPP specifications (https://xmpp.org/extensions/)
|
| 24 SMTP specifications (https://en.wikipedia.org/wiki/Simple_
| Mail_Transfer_Protocol#...)
| usrn wrote:
| cheogram has an SMTP<->XMPP gateway now (along with others.)
|
| Aren't open protocols and interoperability great?
| zaik wrote:
| If anyone is wondering how to use it see
| https://smtp.cheogram.com/ .
| jcranmer wrote:
| The short answer is network effects. The longer answer:
|
| SMTP is an old protocol; it really predates much of what we'd
| think of as the Internet (e.g., it predates DNS or even IPv4).
| This means that during the big initial growth phase of the
| Internet, SMTP was already an established standard that could be
| used to transfer email. Indeed, for email routing on the
| internet, you kind of had to support SMTP anyways, which makes it
| difficult for any other protocol to gain traction.
|
| That's not to say that there weren't alternative protocols. The
| biggest of these was X.400, which many in the 90s saw as the
| eventual replacement of SMTP. But this was hampered by the
| already existing install base of SMTP. Other failures leading to
| the failure of X.400 was its reliance on the OSI stack, which
| lagged behind in implementation compared to the TCP/IP stack, and
| the rather cumbersome addressing model of X.400 compared to SMTP.
| The value added in supporting X.400 in addition to SMTP wasn't
| worth the cost of implementing X.400, and it wasn't really
| feasible to support _only_ X.400 given the already widespread use
| of SMTP.
|
| In this model, XMPP actually works closer to X.400 than it does
| to SMTP. It came about after the protocols it aimed to replace
| were already in existence--and wide use. (See also IRC, which is
| still alive and active). So implementing XMPP means you need to
| justify the value-add of XMPP over existing legacy protocols. If
| you were implementing your own, new chat service, it might make
| sense to build it on top of XMPP instead of a custom protocol.
| But replacing existing chat protocols with XMPP was again a
| costly move with benefits rarely justifying the move. The further
| federation goal of XMPP would have been an anti-goal to many of
| the chat implementations.
| baobob wrote:
| XMPP shares another feature in common with X.400:
| implementation complexity. Where XMPP had numerous
| implementation options and XML, X.400 has ASN.1. It's probably
| straightforward to write another solid explanation that phrases
| SMTP's success entirely in terms of its simplicity
| mmmm2 wrote:
| As an old sendmail hacker, it amuses me to see SMTP called
| simple. I suppose it is though, at it's most basic level.
| It's the extra layers added over the years (MIME, text
| encodings, security, ...) and sendmail itself that make it
| complicated.
|
| Email address routing used to be ugly too, but the
| consolidation on the <user>@<host> standard really helped
| there.
| jotm wrote:
| I mean, it's in the name :P
| cryptonector wrote:
| SMTP was simple then. It grew organically via grafting of
| new things. It's not simple now, but nothing would be.
| fulafel wrote:
| Email has grown without fragmentation, because
| interoperation is seen as a basic requirement by the
| users and operators.
|
| Also strictly speakng MIME and other content layer things
| aren't part of, and didn't need changes to, SMTP. This is
| of practical importance because it means email server
| infrastructure doesn't need to know about email content
| format evolution, only end user email software does.
| cryptonector wrote:
| Yes, this.
| [deleted]
| mjevans wrote:
| I recall reading that XMPP also wasn't always fully
| implemented / federated between services.
|
| E.G. wasn't advertising basic client online / busy / etc
| janky between different siloed implementations?
| MattJ100 wrote:
| Online/busy/etc. are part of the core standards and very
| basic functionality. All software has occasional bugs, but
| I never encountered widespread issues with statuses such as
| you seem to be describing.
|
| There was a period of time where if someone signed in using
| the Google+ chat client, they would appear online but
| wouldn't receive any messages you sent them from the XMPP
| side. That was entirely a Google implementation thing (they
| had stopped maintaining XMPP interoperability at that
| point).
| jcrawfordor wrote:
| The big growing pain for XMPP was behavior when you had
| multiple clients connected simultaneously. Extensions were
| added to the standard that unified behavior around which
| clients received messages (today we'd assume all of them
| but that was more up in the air at the time) and tracking
| of read status across clients in order to highlight new
| messages. But during perhaps the heyday of XMPP the
| extension was not universally supported by even some
| popular clients, so multi-client functionality could be
| confusing and inconsistent, e.g. messages delivered to only
| one client for no clear reason. This is a pretty well
| solved problem today but, well, no one is using XMPP.
| cryptonector wrote:
| Tooling is always an issue in the beginning, when you pick a
| new technology like XML or ASN.1. Tooling is not an issue
| _now_ , but now is too late. Turns out that writing specs
| -and implementing them- around simple textual protocols is
| easier than building new binary and textual structured
| encodings.
| Macha wrote:
| That said, the initial protocols that were too challenging for
| XMPP to unseat (MSN, AIM, Skype...) have been unseated by newer
| tech anyway (Whatsapp, iMessage, Telegram), so it clearly
| wasn't a perpetually insurmountable challenge.
| cryptonector wrote:
| > Other failures leading to the failure of X.400 was
|
| naming. The biggest failure of X.400 was naming. X.400/X.500
| style naming was and remains an unqualified disaster. Not that
| the pre-DNS alternative (UUCP) was great, but that name@domain
| turns out to be infinitely better than X.400.
| technothrasher wrote:
| > it predates DNS or even IPv4
|
| I don't know about IPv4... IPv4 was RFC 760 (Jan 1980) while
| SMTP was RFC 821 (Aug 1982). DNS was certainly later, RFC 1034
| (Nov 1987).
| tremon wrote:
| I can't confirm nor deny any claims about protocol age, but
| still want to point out that the RFC numbering only indicates
| the order in which these protocols were standardized (or at
| least proposed for standardization), not when they were first
| used.
| technothrasher wrote:
| Sure, and they both had several predecessors. But
| everything sort of blends together if you don't pick a
| specific point to define when a protocol 'begins'.
| Standardization through RFC seems like the best choice for
| the core internet protocols.
| zinekeller wrote:
| Nope, SMTP is the older one. RFC 821 _standardized_ SMTP,
| RFC 760 _created_ IPv4, and in fact if you read RFC 801
| it required a switchover from the previous Network
| Control Protocol (NCP) to then-new TCP /IP on the start
| of 1983. As the grandparent points out:
|
| > RFC numbering only indicates the order in which these
| protocols were standardized (or at least proposed for
| standardization), not when they were first used.
|
| Even today, many things are _de-facto_ implemented before
| standardized so I personally don 't think that it's
| correct to look at the RFC date as _the_ date to
| consider.
| jcranmer wrote:
| The first SMTP RFC is RFC 788, not RFC 821. RFC 780 and RFC
| 772 are RFCs for MTP.
|
| IPv4 is defined by RFC 760 and RFC 791, although I don't know
| if RFC 760 actually implements something that looks like
| modern IPv4 (one of the challenges with old RFCs is that they
| were actually requests for comment, and I don't have a good
| sense of when this practice actually stopped).
|
| I was going by Wikipedia's dates, which give the actual use
| of IPv4 on ARPANET as January 1983, which I believe postdates
| the actual use of SMTP on ARPANET.
| zinekeller wrote:
| > I was going by Wikipedia's dates, which give the actual
| use of IPv4 on ARPANET as January 1983, which I believe
| postdates the actual use of SMTP on ARPANET.
|
| This is documented on RFC 801
| (https://datatracker.ietf.org/doc/html/rfc801), which
| literally just mandated use of the previous NCP until 1982
| and then switch to the incompatible TCP/IP protocol stack
| in 1983. Imagine doing that with IPv4!
| JoelMcCracken wrote:
| IIRC, It was successful for a long time, but then when Google
| started supporting it, they captured a lot of the market because
| gmail was so popular, and it had xmpp chat support built into it
| with gchat.
|
| Eventually, for various reasons, Google decided that an open xmpp
| based system didn't work for them, and they closed it and
| extended it. This was effectively the end of xmpp as a
| distributed tech that many people use today.
|
| Interesting, in a lot of ways SMTP is no longer an open system.
| It is extremely hard to operate a mail server in such a way that
| your valid emails get delivered correctly and not marked as spam.
| So for example in the name of fighting spam, it is extremely
| difficult to participate in this "open" system.
| smm11 wrote:
| XMPP was difficult for most to understand. Hardly plug/play.
|
| Same issue with Mastodon, in my opinion. People want to grab
| something from the Store or Play, sign in, and be where everyone
| else is.
| zokier wrote:
| SMTP is not such a great success either. It has fading into
| irrelevance for a long while already. Private comms have been
| shifting towards facebook/whatsapp/whatever, and corporate which
| held to email longer is now shifting towards slack/teams. Even
| with email SMTP is becoming less relevant with the rise of
| Microsoft-Google duopoly. Come to think of it, SMTPs decline and
| XMPPs failure coincide pretty well.
| dragontamer wrote:
| SMTP achieved critical mass before the age of modern startups /
| companies.
|
| All of these federated protocols: XMPP and even Mastodon to an
| extent, are smaller groups of humble nerds running instances.
| They aren't massively advertised, large-scale billion dollars of
| investment companies like Discord or Facebook, trying to build
| network effects and/or advertising revenue.
|
| -----------
|
| When competing against profitable companies, its not sufficient
| to merely exist. You're competing against advertising and
| eyeballs. Facebook is big because its big, because it advertises,
| because it is constantly pushing for more-and-more users. Same
| with Twitter, same with Discord.
|
| This leads to little advantages: a $10-million+ UI overhaul every
| few years. Designers to simplify the interface and onboard
| faster. Paying Google/Apple absurd amounts of money to access the
| push-notification APIs on phones. Etc. etc.
|
| Smaller XMPP instances already fail at the push-notification
| thing. Who will pay for that? And without push-notifications, do
| you really have a modern chat platform? Other companies can
| afford the costs.
| MattJ100 wrote:
| For the record, access to push notification APIs only needs to
| be done by the developer of the app the users are using. Small
| servers never need to communicate with Apple/Google themselves
| - any necessary notifications are routed through a gateway
| operated by the app's developer (which is also necessary
| because only the app developer is given the API keys and
| permissions to send push notifications to their app).
|
| At the time of writing this, 90% of 363 tested XMPP domains
| support push notifications.
|
| I'm not disagreeing with your overall point, mind. There is
| lots to compete with, and due to the lack of a good business
| case for open networks, most XMPP projects are by open-source
| volunteers and the majority of public XMPP services are
| similarly operated by volunteers.
|
| There do exist projects with funding though, and there are
| multiple companies actively engaged in paid XMPP projects and
| deployments. But these all tend to happen behind closed doors,
| they're typically not deployments for the general public, or
| the XMPP is quietly under the hood of a larger service/product
| (such as happened in Zoom, WhatsApp, and many online games such
| as EVE and Fortnite).
| kazinator wrote:
| Regardless of SMTP and XMPP being from different eras, we can
| make these high level observations: SMTP was something designed
| for and deployed at the enterprise/institutional level. Whereas
| XMPP relied on word-of-mouth spread and adoption among
| individuals.
|
| I tried XMPP early on, and found the software to have a user
| experience that was utter garbage, so after that I didn't give it
| a second thought.
|
| At the enterprise level, though, garbage UX is the norm. SMTP is
| hard to deploy, but you have paid full-time sysadmins whose job
| it is to figure out the necessary parts of sendmail.cf or
| whatever else. You tell them "make it so" and they do.
|
| I suspect there was no enterprise level push for XMPP anywhere.
| zaik wrote:
| > I suspect there was no enterprise level push for XMPP
| anywhere.
|
| Gmail and Facebook adopted XMPP. But it seems like it wasn't a
| good fit for their business model of shutting users in and
| collecting as much data as possible, so they shut it down
| eventually.
| deaddabe wrote:
| Before the pandemic hit and management decided to move to MS
| Teams, we have been using Cisco Jabber which -- by the name
| -- obviously seems to use XMPP.
| timbre1234 wrote:
| XMPP was a nightmare. Too configurable. The exact opposite of
| HTTP's "just work" mentality. All the interesting functions were
| in XEP's and some of them (chat rooms, e.g.) were just insanely
| complicated. Classic death by committee.
| bfrog wrote:
| Matrix is also incredibly complicated at this point. A chat room
| in matrix is like an append only log with rules about precedence
| to ensure even when federated the resulting state of the room
| makes sense.
|
| That might be the biggest contribution matrix has to offer.
|
| The json encoding is large and seemingly under defined. Many
| things only seem to work with element and the python server.
| pvg wrote:
| SMTP was there early and with significant adoption - it's not
| inherent stability or quality of design. Early success and
| adoption tends to both entrench and freeze protocols despite
| their deficiencies. XMPP never got the sort of adoption to make
| it entrenched and its deficiencies were noted far earlier in its
| lifecycle. Moxie Marlinspike's piece on some of this is well
| worth reading:
|
| https://signal.org/blog/the-ecosystem-is-moving/
| zaik wrote:
| Daniel Gultsch's response is also worth reading:
| https://gultsch.de/objection.html
| pvg wrote:
| Seven years haven't been particularly kind to that (fairly
| slight, I think), objection. The specifics change but the
| principal points Marlinspike raises haven't. Of course, XMPP
| is more dead than ever, SMTP is still around and taking on
| the piece by moving the goalposts from protocols to something
| else hasn't become more effective.
| zaik wrote:
| > XMPP is more dead than ever
|
| What are you basing this on? The opposite is the case:
| https://takebackourtech.org/xmpp-comeback/
| pvg wrote:
| That link says XMPP advocates think XMPP isn't dead.
| Beltalowda wrote:
| From that post:
|
| > because someone's choice to use an XMPP client or server that
| doesn't support video or some other arbitrary feature doesn't
| only affect them
|
| It was actually even worse than that, because clients also have
| complete freedom in which audio and video codecs to support. So
| you would end up with client 1 and 2 both supporting video, but
| not _the right protocol_ , so it didn't work, and it was hard
| to figure out why.
| yobbo wrote:
| It has nothing to do with the protocol, it's the penetration of
| the services that used it.
|
| In the 90s email addresses along with domain names became part of
| professional fashion. Everyone wanted @mycompany.com addresses,
| and that created one of the obstacles for walled garden email.
| And ISPs often offered email-addresses to subscribers.
|
| "The Microsoft Network" was an attempt at a walled garden that
| failed.
|
| Hotmail etc had no choice but to support the existing open
| protocols. Hotmail was just one of many free webmails.
|
| No instant messaging network used "global identities" (or
| hierarchical identities/addresses like email). The early-mover
| ICQ was a walled garden, and it died quickly when it became
| outdated. ICQ logins/identities had no relevance to anything
| else.
|
| If instant messaging platforms that wished to form a network had
| existed, then adopting some protocol would have been trivial.
| Creating new a network of services/operators competing with
| already an established platform is not trivial.
| r00fus wrote:
| XMPP _failed_ like RSS _failed_ - the original vision for the
| protocol effectively died, but the protocol is in wide use
| despite that.
|
| Essentially, XMPP's federation goal was antithetical to the
| vested interests of messaging providers so it was ignored. But
| the protocol itself was relatively well designed and so formed
| the basis of a lot of what we use today.
| akrymski wrote:
| Alternative take: all protocols die a slow death, being replaced
| by centralised services. XMPP was replaced by WhatsApp. SMTP is
| being replaced by Gmail. HTTP will probably get replaced by some
| binary Chrome protocol, etc. At some point network effects kick
| in, and you just don't need a decentralised protocol when most
| users are on the same system.
| mike_hearn wrote:
| HTTP was already replaced by HTTP/2, which is mostly SPDY
| rebranded - a protocol developed by Google. They weren't
| satisfied with that so now HTTP/2 is being replaced with QUIC,
| a binary protocol implemented first in Chrome.
| olliej wrote:
| I've always assumed it was because it came after IM chat clients
| were already popular? I think ICQ for instance was measuring
| hundreds of millions of users before the first jabber/xmpp
| announcement?
|
| I vaguely recall there being something else as well as ICQ but
| we're talking back to high school for me so well out of the range
| of good/clear memory.
|
| I think messenger also came into existence at around the same
| time as jabber so concurrent development presumably meant
| completely independent protocol, so it wouldn't even be subject
| to embrace/extend/extinguish - this was the height of MS monopoly
| so presumably it meant essentially "everyone" instantly had
| messenger?
| olliej wrote:
| Goddammit I forgot AIM, that was the other one.
|
| So by the time jabber and xmpp came around there were giant
| existing networks: AIM, ICQ, Messenger. Obviously none of them
| had any business reason to adopt an open, etc protocol.
|
| Additionally even if they wanted to, actually doing it would
| likely have been a significant engineering challenge, due to
| the need to maintain compatibility between client versions.
| blihp wrote:
| XMPP was never that popular... it was IRC that was the
| (relatively) widely used open protocol.
|
| SMTP was early enough and good enough to get widespread adoption.
| IRC in its original form was never good enough (esp. re:
| scaling), so services like AIM were able to step in and were good
| enough and open enough[1] solution while the open source world
| stuck with IRC for too long because it 'works for us'. So open
| standards like IRC never got entrenched the way SMTP did in
| proprietary solutions and by the late 90's the open source world
| had become pretty weak on developing new Internet standards that
| would even get widespread adoption in the open source world.
|
| It's worth noting that there's nothing etched in stone to say
| that SMTP has won indefinitely. Try setting up a purely open
| source SMTP server on the Internet these days and see who you can
| talk to. Google has been making it harder and harder[2] to use
| non-Google clients with their servers. Slowly but surely,
| business interests seem to be enveloping SMTP with their own
| walled gardens... it's just taking longer.
|
| [1] Well, sort of. They actually seemed to want to be proprietary
| about it. But every time they changed the protocol, the apps that
| worked with it were able to reverse engineer their changes
| quickly and AOL didn't fight too hard to prevent them from doing
| so.
|
| [2] Or at least enough of a chore so that most people won't
| bother trying.
| jandrese wrote:
| IRC was a different usage model too. While you could do direct
| messages in IRC, it was a side feature and not the primary use
| case for it. XMPP, AIM, and the like are focused far more on
| direct messaging with chat rooms being a clunky add-on.
|
| Anecdotally I experimented with an XMPP server for awhile and
| found it far more difficult to start up than an IRC server. It
| was far more enterprise oriented, assuming you had control over
| the DNS (only one server per domain of course) and with lots of
| complexity around LDAP or AD integration. This is as opposed to
| an IRC server where you downloaded the software, optionally
| exchanged keys with a peer, and started it up.
|
| Using XML as a message format was also a mistake, but not one
| so bad that it would sink the entire project. ASN.1 would have
| been a better choice.
| mike_hearn wrote:
| AOL didn't fight too hard?! AOL fought the hardest of any of
| them! AIM interop was by far the most notoriously difficult
| challenge for alt client devs back in the day because they
| explicitly fought alt clients, whereas MSN Messenger, ICQ etc
| didn't bother.
|
| The trick I remember the most was really quite clever - the
| server started sending hash challenges to the clients i.e. a
| random byte range into the client binary. The client had to
| respond with a hash within a timeout or else the server
| disconnected them. The trick was, because the challenges were
| randomly generated you couldn't make a database of them, but
| also, the copyright license on the client forbade people
| redistributing it. Eventually it was worked around of course,
| people set up servers to answer the oracle queries that clients
| could relay to, but it really disrupted the alt messenger scene
| for quite a while. And in turn that meant it screwed people who
| wanted to use Linux because AIM was the number 1 social network
| in the USA during this period (though it's all forgotten now
| and was never as big in Europe, where MSN dominated).
| webmaven wrote:
| XMPP wasn't adopted by large organizations who valued interop and
| federation. They valued the implementations, but almost
| invariably used it to build a walled garden.
|
| I'm not entirely certain why this was, but I suspect that valuing
| extensibility over interoperability (or the perception of it) was
| part of it. Optional extensions and interop with hosts that used
| a different set simply gave hosts/operators too much to think
| about in terms of deploying the service for users.
| falcolas wrote:
| SMTP came before corporations offered their own email solutions.
| XMPP came after AIM and others had already staked out their
| claims on the chat space.
| corrral wrote:
| SMTP got a toehold before the eternal Corporate Age of the
| Internet practically ended open protocol development, because
| it was far more useful on intermittent connections, and on
| terminals one only used a few minutes a day.
|
| Chat didn't get super-useful until everyone had a screen in
| front of them or on them just about every waking hour. People
| used it before (I know, I was there, and I did) but it was more
| of a "see who's on and chat with them" than what it is now.
| dmytrish wrote:
| Chats have always been super-useful for a more technical
| crowd, IRC is still alive somehow.
| PaulHoule wrote:
| I'd say it was the opposite. In 1990 there were numerous non-
| SMTP email services such as Lotus Notes, uucp-based email on
| Unix systems, the email system in VAX/VMS, etc.
|
| SMTP made these all interoperate and ultimately replaced them
| all.
| tinus_hn wrote:
| Like Lotus Notes, Microsoft Exchange comes with its own
| protocol for internal communication and it is more popular
| than ever, and there is nothing stopping Microsoft from
| slipping in some 'superior' new proprietary protocol for mail
| transport between installations, apart from that it'd be a
| lot of work and not very useful for them.
| PaulHoule wrote:
| XMPP is popular in military and public safety applications.
| mro_name wrote:
| around 2008 a german mass email and hosting provider holding
| chose every email address being a valid xmpp address, too. It was
| about 10 millions each for GMX.de and Web.de alone.
|
| They never managed to promote pleasant onboarding and finally
| shut it down ('nobody wants such') months before WhatsApp
| rocketed - with ejabberd.
| tetraca wrote:
| XMPP was actually fairly successful. It was just embraced,
| extended, and extinguished by the major companies that provided
| services using it. Google, Facebook, and Atlassian all used XMPP
| for their chat clients. You could freely interact with all of
| their chat solutions using XMPP clients. XMPP support for each
| one of them went away one by one.
|
| The environment outside of major providers was (it definitely is)
| kind of janky. If you can set up a server application it's not
| hard but it's not exactly easy to get started, or get people on
| it without handholding (from my own experience).
| dsr_ wrote:
| And, if I understand correctly, the text chat in Zoom is XMPP.
|
| All of these companies chose to kill federation for their own
| advantage, making the world poorer.
| mike_hearn wrote:
| Not really. Google killed XMPP federation because virtually
| nothing used it except spammers, who were becoming a big
| problem.
|
| Controlling spam inside a closed network is drastically
| easier than controlling spam in an open network, because in a
| closed network you have lots of ways to make bans stick,
| whereas in an open network you really can't. Faced with the
| choice of building a massive Gmail style heuristic spam
| filter in which basically all the messages it was processing
| would be spam, or, just turning off federation, they went for
| the latter. It was probably the right call. Very few people
| even noticed, let alone cared. The idea of an SMTP-style
| global network of federated chat servers was dead by that
| point.
| MattJ100 wrote:
| They killed it mainly because there was a dictate to unify
| around the emerging Google+ (I'm pretty sure there is a
| public source for this, but I fail to find it right now,
| otherwise I would link it here).
|
| I'm not saying they didn't have spam problems, but that's
| the kind of thing they certainly had resources to solve.
| They already had such systems due to Gmail, and even
| independent XMPP operators have a pretty good handle on
| XMPP spam these days without even a fraction of the
| resources available to Google. It was more a matter of
| priorities du jour for the company.
| AshamedCaptain wrote:
| That's manipulation of history. XMPP federation was
| actually still working on the Google Talk servers even as
| recently as a couple years ago. However, Google outright
| refused to update their XMPP server capabilities. I am not
| talking about refusing to implement the latest XEPs (which
| they don't), I am talking that they didn't even bother to
| implement SSL! https://xmpp.org/2015/03/no-its-not-the-end-
| of-xmpp-for-goog...
|
| Google was kicked by the other servers out of federation
| due to their abandonment way before Google turned it off.
| And it was always flacky to begin with, specially since
| they also started dropping 3rd party clients (and for that
| you can't blame spam...).
|
| And even if one argues that Google ignored federation
| because of spam and/or low usage, OP's claim that they did
| that "for their own advantage, making the world poorer"
| would still be valid.
| e12e wrote:
| I suppose this includes irc in a way too - AFAIK slack used to
| be (mostly) just a propiatary IRC network and client?
| sc68cal wrote:
| They had IRC gateways that you could use to connect your IRC
| client into slack, but I don't think their architecture
| started like the IRC protocol. It appears to have at one time
| just been a webapp, with databases for storage for messages.
| Not anything like IRC's protocol/architecture.
|
| https://www.slideshare.net/InfoQ/how-slack-works
|
| It may have subsequently turned into something more like how
| IRC servers work, but early on it doesn't appear to have
| been.
| nitia wrote:
| Twitch still is
| hdjjhhvvhga wrote:
| Because SMTP was absolutely necessary for everyone and XMPP
| wasn't - and moreover, there was active interest in making XMPP
| fail. At first, all competitors supported XMPP to lure users, and
| in the end they dropped the support. Same old story as always,
| see Slack shutting down their IRC gateway.
| nikolay wrote:
| The classical Betamax vs VHS question?
| dangerface wrote:
| The web killed the internet.
|
| As developers we look too often for technical reasons for a
| limitation or failure but usually the social reasons are more
| significant.
|
| Getting a client installed on a computer was socially difficult
| like convincing some one to install an app on their phone. Having
| a browser installed on every computer and phone made it trivial
| to get a client on a computer the only down side is being forced
| to use http and websockets as the protocol.
|
| DNS and WHOIS used to be protocols in their own right but both
| are being replaced by http, I wouldn't be surprised if http came
| for smtp next.
| dane-pgp wrote:
| > The web killed the internet.
|
| This is an under-appreciated observation, and adds useful
| context to a lot of the other answers given here.
|
| > I wouldn't be surprised if http came for smtp next.
|
| I hate to be the one to tell you, but:
|
| https://jmap.io/
| eternityforest wrote:
| XMPP is only kind of decentralized.
|
| As far as any individual user is concerned, loss of the
| server(Which their identity is tied to) would be a hassle. Just
| like email.
|
| SMTP got really entrenched really early. It's what gmail uses.
| They can't really do a proprietary mail protocol, SMTP was around
| way before them and nobody wanted to switch.
|
| Instant messaging for the masses was proprietary from the start,
| as far as I can tell.
|
| There was IRC, but it seems like by the time the internet was
| everywhere, people were already on AOL and ICQ and a bazillion
| other proprietary ones offering various extras and integrations.
|
| None of them seem that interested in open protocols.
| bombcar wrote:
| SMTP was a way for email systems to communicate - and so things
| like CompuServe jumped on the bandwagon early.
|
| Universities and others using mainly UUCP also migrated because
| of the benefits.
|
| There wasn't really a huge benefit for the big instant
| messaging players to integrate, and the dirty secret is cross-
| platform "instant" messaging has always existed - it's SMTP!
| Many people still use email as a form of a chat tool.
|
| XMPP also suffers from the "oh shit security might be
| important" that SMTP originally didn't deal with (it's horribly
| insecure by modern standards) which greatly increased the
| complexity.
| justsomehnguy wrote:
| > SMTP originally didn't deal with
|
| More so, absence of security is what allowed SMTP to
| proliferate.
| mike_hearn wrote:
| Here's a slightly different take.
|
| SMTP dates from the earliest days of the internet and you don't
| really see new decentralized/federated protocols after about
| 1995, which is when IM started to be developed. But that isn't by
| itself an answer, it just raises the question of why open
| protocol development mostly stopped in that era.
|
| I think a big reason why was the advancement of networks and
| hardware made it feasible to actually build and run large
| internet connected datacenters for the first time. In turn that
| meant you could run a server farm to which everyone could connect
| to, without running massive modem banks and the like.
|
| In the early days of the internet that wasn't the case. Servers
| were machines running in people's offices and the ecosystem was
| extremely fragmented. There were lots of different kinds of
| network and email system, SMTP was really a sort of hack to
| bridge different systems together. The internet was congealing,
| being patched together out of lots of existing stuff, and big
| companies mostly didn't care. Networks were often only
| intermittently connected, the internet was for hobbyists and
| researchers, not 'serious' companies like AOL or Microsoft, who
| didn't "get" the internet at all until some famous memo by Bill
| Gates (they were pushing their own closed network). SMTP reflects
| this world with its handling of offline servers, lowest-common-
| denominator simplicity etc.
|
| Once big companies realized the internet mattered and datacenter
| / networking technology got far enough along, the era of
| decentralized federated infrastructure died out pretty quick.
| This is in many ways very sad, but it's also in some ways
| inevitable. The decentralized cooperative standards-based
| approach sounds romantic, but it can be described in other much
| less noble ways e.g. as a form of committee-controlled pure
| communism in which nobody owns anything.
|
| Phrased that way it's maybe obvious why that model of development
| has failed: there's no incentive to do anything good. SMTP isn't
| good. It's like an MVP email protocol. XMPP isn't that good
| either in many ways; you certainly wouldn't design a protocol
| that way today. And of course the issue here is not just the
| protocol but the entire stack - the servers, and most especially
| the clients. Every federated protocol system always suffers badly
| from a fragmented and min-viable client landscape, which
| certainly held back XMPP a lot.
|
| Who is incentivized to make something good? Well, people who have
| an ownership stake in the results. The prospect of a big payout
| is what lets you attract teams of the most skilled people who
| will work crazy hours to build a service people love. It's the
| capitalist model - wall off the garden and charge an entrance
| fee. Suddenly finding gardeners isn't a problem anymore, because
| you can just pay them instead of asking them to volunteer.
|
| The lack of ownership causes all sorts of subtle problems in the
| federated protocol landscape, beyond the obvious ones like a
| proliferation of low quality clients written in people's spare
| time. Probably the worst is that there's little innovation.
| People become motivated to build a federated/open protocol mostly
| when they see a successful proprietary product and they'd like to
| have the benefits of that product without the loss of freedom,
| dependence on a single vendor, having to pay for it etc. These
| communities are always going where the puck _was_ , not where
| it's going now. By the time they finish cloning one cool feature
| their proprietary competition has, it's too late, that
| competition already moved ahead and added something else. This
| really nailed XMPP because networks like MSN were constantly
| adding features that XMPP couldn't easily respond to, and you see
| it again with stuff like stickers in Telegram. No open source dev
| is going to spontaneously decide to add stickers if they haven't
| seen that feature before, because it'd require recruiting a ton
| of artists and would seem trivial. Proprietary software companies
| are much more likely to come up with popular stuff like that.
| They find it much easier to build multi-disciplinary teams.
| emteycz wrote:
| I used to chat on IRC between 2005 to 2014. We tried to switch to
| Jabber several times but it was simply too much work (we had
| elaborate mIRC bots, for example) and it simply wasn't as good -
| bloaty clients (this was in times when we had 512 MB RAM and
| single or dual core), chat servers were frequently down while IRC
| always worked (with the occasional netsplit, but oh well)...
|
| Then we tried Slack but most people didn't come there too much.
| Today we have a Telegram group and it's so much better UX/UI
| wise...
| nitia wrote:
| Telegram is backed by xmpp ;)
| emteycz wrote:
| Cool, but the coolest thing about Telegram is that IDGAF, it
| just works
| runjake wrote:
| XMPP didn't fail. It's used everywhere. I can look at my firewall
| traffic any time and I _always_ see XMPP traffic from the various
| Big Tech companies you already know.
|
| But, like commenter tetraca mentioned, XMPP has been embraced and
| extended, and it's not very interoperable, as implemented.
|
| SMTP has been and will always be around forever, albeit
| eventually viewed like FAX is today. I personally view it like
| that today.
| MithrilTuxedo wrote:
| Isn't XMPP almost ubiquitous?
|
| I thought it's what everyone used for messaging and push
| notifications. I know Google extended it beyond compatibility
| around when Hangouts came out and they started doing browser
| notifications. Apple stopped providing sources for ejabberd in
| the last few years, so I assume they moved off that for their
| iChat/messaging backend, but isn't iChat still an XMPP client?
|
| Aren't most SMS messages routed via XMPP?
| zaik wrote:
| > isn't iChat still an XMPP client
|
| That's really cool. I would love to send XMPP messages to my
| friends who use iPhones without having them register on a
| public chat service and downloading a client.
| taway2022-05-26 wrote:
| Wikipedia tells me that iChat was XMPP-based, but was
| discontinued in 2012 and replaced with iMessage, which is based
| on Apple Push Notifications and not XMPP.
|
| Google has also discontinued Hangouts and who knows what you're
| supposed to use now. Their chat stuff has been so chaotic I
| really can't keep track. (Allo? Duo? Plus? Google Talk? Wave?
| Chat?)
| api wrote:
| There are two reasons that I see.
|
| One is that XMPP is an overcomplicated nightmare. The protocol
| was verbose, flabby, and hard to implement, and the server
| software was very hard to set up and run especially for novices.
| A person could not just install a server and start chatting, even
| if the server was just stand-alone let alone linked to anyone
| else.
|
| The second and IMHO more fundamental reason is that the Internet
| is a dark forest. Any open system that becomes sufficiently
| popular will be destroyed by abuse.
|
| If you offer a chance to make _any amount of money whatsoever_
| online millions of hustlers will rush into the void like gas
| molecules invading a cracked vacuum bell and will scramble all
| over each other to suck every last fraction of a penny out until
| nothing of value remains. So far only centralized managed systems
| have been (somewhat) successful at keeping the barbarians at bay.
| I 'm not saying a decentralized system could never succeed here,
| but I don't think it's been done yet. (Cryptocurrency isn't an
| example as it's already been throughly destroyed for its original
| vision and use case by scammers. It's a great case study in
| exactly what I mean.)
|
| (Edit: the goal is not always money either. Read money as
| "value." Political propaganda, cult recruitment, weaponized
| disinformation, or just trolling for lulz all count as extracting
| value of some kind at the expense of the commons.)
|
| SMTP along with Usenet was one of the first casualties of this
| phenomenon, and I would argue that it _did fail_ as an open
| system. You can run your own SMTP server but it 's not for
| novices or people without time on their hands. You'll have to
| fight constantly to keep your IP out of blacklists and to keep
| spam away from your users. Spammers are in an arms race against
| huge companies with massive training data sets and entire teams
| dedicated to spam filtering, so this only gets harder over time.
| An independent SMTP server is easy prey.
|
| 99% or more of users use one of several large mail hosts. These
| are mostly Google, Microsoft, and Apple in the USA. E-mail
| hosting is cheap to free and the vast majority of people would
| rather someone else deal with the pain of defending them from
| spam.
| Beltalowda wrote:
| > If you offer a chance to make any amount of money whatsoever
| online millions of hustlers will rush into the void
|
| It's even worse than that because just a very small group
| (dozens, or even a single individual) can really screw over an
| entire system because doing things digitally is so cheap and
| easy. For example the world has 8 billion people, and sending
| every single one of them an email message (assuming everyone
| has an email address, which they don't) is easy, cheap, and can
| be done relatively quickly. With just 100 spammers on the
| entire planet your email system would still be screwed.
| Sohcahtoa82 wrote:
| > Any open system that becomes sufficiently popular will be
| destroyed by abuse.
|
| This is a harsh truth that I'm always surprised that so many
| HNers haven't accepted yet.
| api wrote:
| We are about to see it happen with reasonably open software
| package repositories. Prepare yourself for a coming deluge of
| increasingly stealthy and sophisticated software supply chain
| attacks.
|
| It's not that most people are bad. It's that it doesn't take
| very many people behaving badly to ruin a common platform on
| the Internet since one bad actor can use cloud compute and
| bots and other resource pools to launch huge attacks. Add
| anonymity to the mix and you've got a recipe for easy high-
| impact low-risk abuse.
| pohl wrote:
| Underrated truth bomb right here.
| shireboy wrote:
| As a rabbit trail/pet peeve, I think there needs to be _some_
| standard in this space. It is silly to me that
| iMessage/SMS/Google Talk/Facetime/etc. can't all just interop on
| some open standard. I understand there are marketing forces
| pushing against it, but we do it for email, why not chat & talk?
| Totally ridiculous that I have to think "is this friend using
| Android or iOS?" when I text or call them. Even worse for group
| texts, plus means that windows/linux users can't easily message
| through their iphone. I haven't dove into it, but XMPP seems like
| a good candidate.
| zaik wrote:
| XMPP is already a RFC Internet Standard.
|
| It's just that getting federation, interoperability and
| backwards compatibility is much harder than inventing your own
| new thing + users gain the freedom to move to a different
| provider (without loosing all your contacts).
| kristianc wrote:
| A common mistake tech people make is assuming that things that
| bother them must also bother a large number of other people
| enough to incur sizeable switching costs to solve it.
| number6 wrote:
| Nah, the other people are just wrong.
___________________________________________________________________
(page generated 2022-05-26 23:02 UTC)