[HN Gopher] Instant messaging: Protocols are "commons", let's ta...
___________________________________________________________________
Instant messaging: Protocols are "commons", let's take them
seriously
Author : mooreds
Score : 72 points
Date : 2023-12-31 13:13 UTC (9 hours ago)
(HTM) web link (www.process-one.net)
(TXT) w3m dump (www.process-one.net)
| edhelas wrote:
| It's time to give XMPP more love <3
|
| XMPP in 2023 is having all the modern features that you can
| expect while being massively scalable and having a really nice
| ecosystem (there is still some quirks here and there but it
| really improved the past few years).
| wyldfire wrote:
| But XMPP encoded everything in XML? This seems like a really
| high overhead.
| f1refly wrote:
| Fortunately, there's an RFC for people concerned about this
| :) https://xmpp.org/extensions/xep-0295.html
| pocketarc wrote:
| Wow, my first thought reading through it was "wait they're
| just wrapping XML in JSON, what in the world is happening
| here", eyes widened after reading the completely
| contradictory introduction, until I saw the reason for that
| RFC.
| rijoja wrote:
| Absolutely yes, I have fond memories of the Pidgin client,
| which handled everything gracefully, and also libpurple.
|
| This was ages ago, is pidgin still one of the best xmpp
| clients, or are there better ones now?
|
| I remember that pidgin even used with facebook, unfortunately
| facebook dropped xmpp as someone else in this thread mentioned!
| PaulHoule wrote:
| Even though people have long experienced that you can call an
| iPhone from an Android or that a Vodaphone customer can call a
| Reliance customer, somehow people aren't bothered at all that
| "messaging" programs don't interoperate. Google can make 10+
| messagers that are incompatible with each other and only a tiny
| fraction of people see that's a problem.
|
| And that's a problem!
|
| After about 30 years we see a clear pattern: something like AIM
| comes out, because it is locked in there is no competition for
| the client or the server so there is no motivation to improve
| either. The thing is the computing world moves ahead so the
| system goes bad like cheese as the environment it works in
| changes. A decade later there is a new client out and people are
| saying "Remember when AIM used to work? There's a new service
| that works _just as well_ as AIM used to work" and finally people
| are so burned out of AIM they are ready to switch but failing
| messaging systems can lumber on for years like that.
|
| Emphasis on "just as well" because in this scenario the systems
| _are not getting better_ , you're not getting an upgrade by
| switching, you're just treading water. What people aren't
| realizing is that if we had interoperability we would have had
| competition and after 30 years we'd see 30 years of progress in
| messaging systems unlike the occasional churn but lack of
| progress we've had.
| lotsofpulp wrote:
| > Emphasis on "just as well" because in this scenario the
| systems are not getting better, you're not getting an upgrade
| by switching, you're just treading water.
|
| Modern messaging systems allow me to do much more than AIM. I
| can send and receive very high quality photos and other files.
| I can video and audio call all around the world at zero cost. I
| get very little spam on WhatsApp/imessage.
|
| > What people aren't realizing is that if we had
| interoperability we would have had competition and after 30
| years we'd see 30 years of progress in messaging systems unlike
| the lack of progress we've had.
|
| We had interoperability with phone numbers, but I saw no
| improvement until AIM/Skype/MSN Messenger/Google
| Talk/WhatsApp/iMessage came along.
|
| With the previous "interoperable" system, I had to pay for
| international audio calls and SMS/MMS, so I never did.
|
| So interoperability does not seem like a guarantee of progress,
| and things might even stagnate due to interoperability
| requirements. Pros and cons for both.
| paulryanrogers wrote:
| Messaging and expectations thereof have plateaued. Moving to
| standardized protocols is unlikely to stifle innovation that
| isn't really happening.
| naravara wrote:
| For now. Once AR/VR gains broader adoption you're going to
| see another wave of new features and capabilities people
| will want. This will not only involve how people interact
| with them and stuff they do, but also underlying stuff like
| compression and latency compensation.
| JohnFen wrote:
| > Once AR/VR gains broader adoption
|
| That's a really huge "if" right there.
| naravara wrote:
| Inevitable on a long enough timeline I'd say. It's just a
| question of whether that's a 5, 10, or 50 year deal.
| JohnFen wrote:
| I think it's far from inevitable, personally, but it
| might happen eventually. Right now, it doesn't seem
| likely (for general use -- I fully expect it will get
| widely adopted for certain niches), but who knows what
| will happen tomorrow?
| Spivak wrote:
| They plateaued and then Slack/Discord got popular which
| further pushed the expectation around group chats and 3rd
| party integrations. The "web 2.0" style messaging where
| it's just an inbox with a linear chat history now feels
| ancient compared to group chats with multiple
| streams/topics, threads, events, pinned messages, live-
| statuses that show music listening/gaming, built-in
| voice/video/livestreaming with bots that can supply rich
| interactions like select menus/buttons.
| naravara wrote:
| People seem to have forgotten that AIM (and Google Talk) were
| not asynchronous. If you wanted to IM someone they had to be
| online at the same time you were. Neither of these protocols
| was particularly good at syncing across devices and working
| with the modern expectation that people be able to check in
| and check out from any device at any time.
|
| They were always destined for being retired once smartphones
| became a thing.
| toast0 wrote:
| AIM was online only for a long time, but it developed
| offline messaging eventually (my memory is fuzzy, but I
| think this happened after ICQ was integrated; ICQ had
| offline messaging for as long as I used it and I had a
| 6-digit account)
|
| Indeed, there wasn't synchronization between devices,
| although there are many ways that could have been handled.
| yterdy wrote:
| >somehow people aren't bothered at all that "messaging"
| programs don't interoperate.
|
| I used Trillian for almost a decade; it was the second best
| solution to actually being able to message Yahoo and MSN users
| from my AIM handle.
|
| I think people have been bothered, but when an entire platform
| disappears, there's not much anyone can do. The coding wizards
| who _are_ capable of doing something (in concert with some
| marketing wizards, maybe) don 't seem interested.
| jrochkind1 wrote:
| The "coding wizards" are largely interested in doing what
| someone will pay them to do, of course. With some exceptions,
| but of course the bulk of the work that has been put into
| messaging apps and protocols over the past two decades,
| whether open or proprietary, has been by engineers and
| "coding wizards" getting paid by a for-profit company to do
| it.
|
| So it's really about what those who have money they spend
| paying for development are interested in, I think, not the
| interests of "coding wizards", who might love making
| something different if they could be paid similarly (or at
| all?) to do it.
| yterdy wrote:
| There are many ways to get paid, and many basic
| technologies that people work on because they're
| intrinsically interested in it or in what it could do for
| their community or the public.
|
| I don't think it's controversial to say that there's
| generally a focus/priority issue in the tech industry. The
| world's most profitable progress-themed ad distributor.
| jrochkind1 wrote:
| I think the amount of developer-hours spent working on
| things -- without betting paid -- because they are
| intrinsically interested or think it's socially useful,
| is dwarfed, by orders of magnitude, by developer-hours
| spent getting paid.
|
| The number of developer-hours getting paid to work on
| proprietary messaging systems is pretty huge.
|
| And this is hardly irrelevant to understanding why we
| have proprietary messaging systems.
|
| Whether you personally are a developer or not -- if you
| have spent more hours building something you haven't
| gotten paid for than you have at your paid job, you are
| an unusual person. (Such unusual people do exist! they
| often, but not always, have atypical lives in some way
| that allows this)
|
| I mean, you think "the world's most profitable progress-
| themed ad distributor" comes about becuase "coding
| wizards" are just intrinsically intersted in this, rather
| than because it's what makes people lots of money? It's
| just a lucky coincidence lots of people made money, that
| focus is really because "coding wizards" by and large
| just love distributing ads, it's a personal interest?
| This is all guided by the personal interests of "coding
| wizards" rather than by who pays for software development
| for what?
| Shish2k wrote:
| > if we had interoperability we would have had competition and
| after 30 years we'd see 30 years of progress
|
| Counterpoint: IRC
| dijit wrote:
| i dont see the counterpoint here, which company has poured
| even a fraction of a percent into IRC as Google has with its
| myriad of messengers or Whatsapp/Telegram ec?
|
| One google engineer on his personal time introduced entirely
| new systems into IRC (RobustIRC) https://robustirc.net/ which
| is the most commercial support that exists.
|
| The IRCv3 initiative is a very small number of people, none
| of them supported commercially.
| jrochkind1 wrote:
| Companies apparently do not see incentive to pour that kind
| of money into software for open protocols. We can talk
| about whether they are rational or irrational, but from a
| perspective of maximizing profit I think they are probably
| rational.
|
| I agree what it gets the consumer is crap.
| nemothekid wrote:
| The claim was if we had interoperability we would see
| progress. IRC exists and we didn't. Now your claim is if we
| had interoperability _and_ there was a benevolent giant
| willing to pour billions in investment we would see
| progress.
| dijit wrote:
| Ah, well, I still disagree IRC was that.
|
| XMPP was that, and it saw widespread adoption up until
| Facebook and Google walled off their XMPP federation-
| slack even disabled its XMPP bridge (that wasnt
| federated).
|
| Companies definitely killed that open protocol, though
| there could be arguments against XMPP: functionally they
| could have been worked around, there is just a
| significant financial incentive to _not want to_.
| bebna wrote:
| why counter?
|
| still alive and well, survived takeover attempts, see
| freenode -> libera.chat and got a shiny new protocol spec
| with modern features
| Shish2k wrote:
| > still alive and well
|
| Last time I checked user numbers were both steadily in
| decline, and small in absolute terms (top 10 IRC networks
| combined have ~500k users - compare to eg discord with 150
| million users. There are individual discord servers with
| larger user numbers than the entire world of IRC)
|
| > survived takeover attempts
|
| Didn't the takeover succeed, and then all the users
| migrated to a different server? I guess if you're saying
| "IRC as an abstract concept survived the takeover of an
| individual network" then sure that happened.
|
| > got a shiny new protocol spec with modern features
|
| Perhaps I'm reading this chart wrong, but checking the
| IRCv3 feature support page, features that I would consider
| "modern by 80's standards, table stakes by 90's standards"
| (eg account registration, chat history) are still in the
| "draft" stage and not supported by libera.chat. Features
| from the 2000's (eg mobile notifications) aren't even being
| drafted?
|
| If interoperable protocols really drove progress, Discord
| wouldn't have attracted more users in 6 months than IRC did
| in 30 years :P
| tycho-newman wrote:
| I used Pidgin/Adium back in the day to consolidate all my IM
| protocols. There was a hot second where XMPP was really taking
| off and even worked on Gchat. I think iMessage and WhatsApp
| made that moot because people got used to apps, and did not pay
| attention to the protocol.
|
| All the cool messenger tech that I want to use is buried under
| user experiences that drive off normies accustomed to iMessage.
| I have made peace with it and use Signal instead.
| alexwasserman wrote:
| iChat, Apple's earlier messenger worked with XMPP too. There
| was a small period it looked like it would be a good standard
| app.
| parineum wrote:
| >Even though people have long experienced that you can call an
| iPhone from an Android or that a Vodaphone customer can call a
| Reliance customer, somehow people aren't bothered at all that
| "messaging" programs don't interoperate.
|
| > ...if we had interoperability we would have had competition
| and after 30 years we'd see 30 years of progress...
|
| SMS has been popular and interoperable for at least two
| decades. The progress we've seen is MMS and the promise of RCS.
|
| The problem with building interoperability is that the
| innovators are innovating for their competitors.
| timw4mail wrote:
| The question then, is what kind of protocol(s) should be used.
|
| SMS is about as close as exists for open instant messaging, but
| it requires a phone number
|
| IRC seems to have inspired Discord and Slack, with the closed
| variants improving on features and discoverability.
|
| As far as I know, XMPP doesn't really have a cross-server ability
| like SMS and IRC, though.
| jon-wood wrote:
| XMPP absolutely has cross server support, it was designed from
| the ground up to do so. You can run your own server and
| advertise it via DNS, which will then allow other servers to
| communicate back and forth with users on your server.
| BirAdam wrote:
| SMS is essentially just email. The phone number just ends up
| being part of the email address: 0123456789@att.net and
| whatnot.
|
| Edit: there was also a time when AIM could send and receive SMS
| due to this structure, and at one point it was trivial to set
| up a script to email your phone number as SMS for alerts and
| such. This became more complicated as SMS providers started to
| require a lot of the same stuff as email providers to cut down
| on spam.
| jon-wood wrote:
| It's really not. Lots of mobile providers did indeed run
| email to SMS bridges back in the day, but those were taking
| the body of the email (or sometimes just the subject) and
| converting it into an SMS for delivery.
| Hakashiro wrote:
| It is more than a protocol. It's an experience.
|
| E-mail is totally intercompatible, but the experience for
| anything apart from "the equivalent of letters" is simply
| horrendous. Delta Chat tries to make e-mail more like a chat
| app, but it isn't perfect, because e-mail wasn't designed to be
| a chat application.
|
| XMPP has other massive usability flaws. So does IRC, Matrix,
| and others.
| Arathorn wrote:
| None of Matrix's typical usability problems are the
| protocol's fault - they are the clients' fault. The fact is
| that on the Matrix side we invested _much_ more time on the
| protocol, spec process and even server implementations in the
| early days.
|
| Meanwhile the clients Element built to bootstrap the protocol
| have been stuck paying off huge amounts of product debt, and
| are _finally_ at the point now of surpassing mainstream apps
| - eg https://element.io/blog/element-x-ignition/ - but it
| took years longer than it should have to get there. Again,
| it's not the protocol's fault though, other than the extent
| to which building a protocol draws energy from building
| killer apps.
| pocketarc wrote:
| The problem is that there is absolutely no incentive for a
| company to do this. There is no reason for Apple to work with
| Meta to make iMessage work with WhatsApp, and for both of them to
| work with Telegram and Signal so they all work together and share
| everything.
|
| It kills their ability to add differentiating features, it
| removes their networking effect moat, and it provides them with
| no benefit. It's so much more appealing for their answer to be
| "just download my app".
|
| It happened for telephone and email because they were developed
| in a different era. It's not going to happen for IM because we're
| in the era of "why build it if I can't profit from it?".
| lotsofpulp wrote:
| > It happened for telephone and email because they were
| developed in a different era. It's not going to happen for IM
| because we're in the era of "why build it if I can't profit
| from it?".
|
| Who is going to pay for the bandwidth for 5MB to 100MB
| photos/videos/gif/files that are sent through the network?
| paulryanrogers wrote:
| The sending service should do the hosting so they can pass it
| on to the sender themselves. Receiving services can fetch
| thumbnails or full images on demand
| lotsofpulp wrote:
| What incentive does the sending service have to pay to
| host? The answer to this is the response to:
|
| > "why build it if I can't profit from it?".
| beanjuiceII wrote:
| you already lost me
| zo1 wrote:
| This makes no sense to me and is probably why we're so far
| away from a good solution - I pay my ISP for bandwidth to
| "the network", which includes other devices on "the network".
| This is the problem, not everything has to go through a
| "server" which then needs "bandwidth".
| lotsofpulp wrote:
| Surely, the cost of delivering a packet of data is at least
| partly function of how far the packet has to travel.
| Assuming your ISP has to pickup the cost of delivering this
| packet to every corner of the world, the ISP would have to
| increase prices to account for this (similar to paying
| extra for international phone calls).
|
| Currently, it seems like a variety of entities are
| subsidizing this via things like peering agreements and
| whatnot to make the use of internet simple for the end
| user.
| sixstringtheory wrote:
| So what happens if you send a message with a video and the
| recipient's device is not responsive, say because it is out
| of battery or data service range? Should the message simply
| be lost or should it be stored somewhere until it can be
| successfully sent?
| dns_snek wrote:
| That "somewhere" could be a server embedded inside your
| home router provided by your ISP or another "dumb"
| mailbox of your choosing. That would of course require
| regulation or an industry-wide push towards P2P, which is
| unlikely at best.
| krrrh wrote:
| Signal runs on donations with a small staff and budget, and
| even still half of its infrastructure budget goes to sending
| a verification SMS on sign-up. You can run an open chat
| network as a tiny non-profit, and any hope of profits is in
| the same ballpark. For the incumbents it's a loss leader for
| other services, and that complicates the whole analysis going
| on in this thread.
| esafak wrote:
| Interoperability does not benefit incumbents, but it does
| benefit entrants.
|
| The cross-protocol clients back in the day used reverse
| engineering to work. That would not fly today because today's
| tech culture is less hacker friendly, more litigious. Such a
| company would not receive venture funding due to its risky
| nature.
|
| I think there is room for improvement in messaging, but
| interoperability makes it more difficult. I think it is in
| everyone's best interest to first ask for better features, let
| its inventors make a profit, then worry about interoperability
| once competitors catch up. If the market is competitive,
| interoperability can be achieved through coalitions. IBM's MCA
| vs Compaq et al's EISA is an instructive example.
| darklion wrote:
| > it does benefit entrants.
|
| Which is why you don't see successful messaging companies
| rushing to open their systems.
|
| What company wants to spend the effort to build a successful
| messaging platform, only to open it and see some nobody come
| in with feature parity _and_ the ability to reach/convert
| every single one of their customers?
|
| Open protocols would have worked great if that's what was
| mandated _before_ these established products were in the
| market. Now, it's going to be an uphill fight all the way,
| and companies are going to do the absolute bare minimum---not
| just what they can get away with technically, but what they
| can get away with legally (e.g., Apple adopting RCS so they
| can point to RCS as the common messaging denominator, thus
| avoiding opening up iMessage itself).
| ImPostingOnHN wrote:
| I don't see why we should assume that apple must open
| iMessage users to others out of pure, market-based economic
| incentive, or even out of the goodness of their heart. We
| can just make them do it regardless of what they want.
|
| It'd be better for people (maybe not apple), and the people
| can decide how their country is run, including requirements
| on tech interoperability for businesses operating in that
| country.
| naravara wrote:
| iMessage already works with SMS/RCS, which is low level enough
| that any messaging service could use it as a method to
| interoperate with anything else.
|
| What iMessage can't do is translate a lot of the QOL and UI
| features, each client will have to adapt to read those on their
| own.
| user3939382 wrote:
| Many have probably long forgotten Facebook ditching XMPP. For a
| moment there was hope we'd be moving open federated comms
| protocols into the new era.
| rijoja wrote:
| Yeah I remember this! I used to use it with pidgin, as I
| mentioned in another comment on this thread.
|
| Google talk used to use xmpp as well back in the good old days,
| and there's maybe even some more!
|
| It'd be nice if open source projects where to culturally make
| it a norm to use xmpp instead of slack, discord, and the like,
| sort of how everything used to be run over IRC in the even
| better old days!
| bsaul wrote:
| Seems like european union DSA will force this interoperability
| protocol to emerge quite soon, doesn't it ?
| mikem170 wrote:
| "The EU Digital Markets Act mandates that messaging services
| like iMessage are required to offer other companies some level
| of interoperability if they're deemed to be big and important
| enough." [1]
|
| The law has already passed and will apply to messaging services
| with more than 10% of the market. WhatsApp and Facebook
| Messenger will need to comply. After review it was determined
| that iMessage doesn't have enough users in Europe at this time.
|
| [1] https://www.theverge.com/2023/9/6/23861030/imessage-bing-
| eur...
| bsaul wrote:
| yes sorry i didn't notice that at first read. Thanks for the
| info about imessage, i had no idea about that 10% market
| share..
| rapnie wrote:
| Tangential. Here's the CCC talk [0] about RFC 9420 Messaging
| Layer Security, mentioned in the article, and More Instant
| Messaging Interoperability (MIMI) [1] at the IETF, mentioned in
| the video.
|
| [0]
| https://media.ccc.de/v/37c3-12064-rfc_9420_or_how_to_scale_e...
|
| [1] https://datatracker.ietf.org/group/mimi/about/
| bitzun wrote:
| A developer bemoaned to me the threat of being legally obligated
| to make major chat apps interoperate because it would be too much
| effort and would stifle innovation, and I found that rather
| pathetic. If we couldn't figure out how to create protocols that
| connect these "modern" apps, especially given that they have
| mostly converged on the same set of basic features, it'd be a
| pretty strong indictment of the industry. To be clear, I hope it
| is mandated and if it is I'm sure it'll be achieved easily.
| j45 wrote:
| The delusion that one app can be the only centre of your life
| continues to litter our phones with 9 chat apps.
|
| Not making protocols interoperable allows the app to attempt to
| build their own walled garden.
|
| Interoperability is a very old problem, and it has been
| reasonably solved a few times (jabber pre Cisco/xmpp/etc) and
| most recently technologies like matrix/riot are pretty well
| positioned.
|
| While tools like pidgin exist today, software like trillian of
| old allowed one interface to log into everything.
| JohnFen wrote:
| > and would stifle innovation
|
| I am getting increasingly concerned about the number of times
| aggressively antagonistic things are defended because
| addressing them would potentially "stifle innovation".
|
| Innovation is important, but it's far from the only important
| thing. We need to stop sacrificing everything on the altar of
| "innovation".
| gumby wrote:
| Why did SMTP win? My first business card had my ARPA email
| address on it, which occasionally generated a question but which
| was usually ignored by those who didn't have email. Then people
| started to list their compuserve or whatever address on their
| cards -- often several addresses -- which made me laugh, and then
| eventually an SMTP address wiped all those alternatives out.
|
| I used to see the same thing with phone numbers: a stack of phone
| (desk phone), fax, pager, voice mail, mobile, all eventually
| collapsing into a single phone number.
|
| Why did this not happen with messaging (which is more than 30
| years old, despite what the article says)?
| Anunayj wrote:
| What is a ARPA email address? I've never heard of it. Did they
| look different from normal SMTP email address used today? Or
| was it like your email server just supported ARPA and not SMTP.
| gumby wrote:
| I was gumby@MIT-AI.ARPA. By then mail used SMTP but the
| arpanet had not yet transitioned to IP/TCP.
|
| Those .ARPA names were part of a lengthy transition to the
| DNS; before this I was just gumby@mit-ai or just gumby@ai
|
| The ARPA. TLD isn't used for hosts any more but has been
| repurposed mainly for network database lookups. Yes, the `.`
| after the TLD is there for a reason.
| esafak wrote:
| WhatsApp lets you use phone number as your ID, and it is very
| successful.
| gumby wrote:
| My point was that there is a single universal email system
| but no single universal IM system.
|
| WhatsApp is another silo, even though it uses phone numbers
| as identifiers.
| tptacek wrote:
| _The burning question is, why not choose an open protocol that
| already works on a large scale, like XMPP, adding their value on
| top?_
|
| This never works. It's a recipe for disaster. The security model
| of a secure messenger informs the protocol from top to bottom.
| You try to retrofit cryptography onto a general-purpose messaging
| protocol and you get group membership protocols that allow
| servers to decrypt messages, and centralized databases of
| everybody who's talking to everybody else. Even good, purpose-
| built protocols have ended up with these kinds of problems (see
| Matrix). Never do this.
| uhoh-itsmaciek wrote:
| Do you have more info about the issues with Matrix?
| MattJ100 wrote:
| https://nebuchadnezzar-megolm.github.io/ has details of the
| main issues I recall (most/all fixed as I understand it).
| Arathorn wrote:
| He's talking about https://nebuchadnezzar-megolm.github.io/ -
| and the fact that group membership in Matrix is currently
| determined by the server rather than a client. So if Alice is
| in a DM with Bob, Bob's server could make up malicious
| devices for Bob, or fabricate an invite to add Charlie to the
| room. This is mitigated by encouraging users to verify
| devices, so Bob's fake device would be recognised as an
| attacker - and for faked invites, relying on Alice and Bob
| spotting that an unexpected malicious user just joined their
| conversation.
|
| However, it could be better: first we have been converging on
| a single Rust crypto impl (at last) - see the crypto section
| of https://matrix.org/blog/2023/12/25/the-matrix-holiday-
| update.... Then we're shifting to TOFU (so unsigned devices
| never get encrypted for). Then, finally, we're shifting to
| client-constrained group membership (unless MIMI gets there
| first, and then we may switch horses to their MLS-based
| solution).
|
| edit: the other issues raised by the nebuchadnezzar paper
| were impl bugs in the 1st gen crypto impls, which were fixed
| at the time. also, the premise that you can't add encryption
| posthoc to a protocol is flawed, imo. Matrix may not have
| nailed it, but as long as you consider the crypto as if it's
| a new protocol and have the agility to evolve to it, everyone
| wins.
|
| edit 2: there is no centralised db of who talks to who in
| Matrix. individual servers can see who shares a conversation
| which their server participates in, but this is very hard to
| avoid given you could always figure it out via traffic
| analysis (unless you go down a Nym style mixnet solution).
| tptacek wrote:
| Regarding the database, I am thinking of systems like Wire.
| I don't know how Matrix handles buddy lists.
| MattJ100 wrote:
| MLS addresses many of these issues and both Matrix and XMPP are
| working on incorporating it.
| daft_pink wrote:
| 1. I think security and privacy has a lot to do with it. If the
| services interoperate then other companies that make the services
| will get access to your personal data even if you don't use them.
|
| 2. Even though there are so many services, I find functionality
| to be lacking on many of them. I don't want to use facebook,
| because of privacy. I don't like signal because it doesn't give
| you your chat history across devices. I used to love hangouts,
| but google destroyed it. Many of the services are tied to your
| phone and don't work if it isn't on. There is a good chart in
| german comparing the different features. I just use imessage
| because it's end to end encrypted, i trust apple's privacy and it
| works.
| Mortiffer wrote:
| Surprised to not see DIDcomm standard mentioned
| https://identity.foundation/didcomm-messaging/spec/v2.1/
| https://didcomm.org/
| JohnFen wrote:
| That every IM service is an island of its own is the primary
| reason why I don't use any of them. I'm not about to install and
| keep track of multiple IM service apps. It's just better and
| easier for me to avoid them all.
| Hakashiro wrote:
| While this is commendable, the problem with this is that you're
| also refusing to interact with people who use those platforms.
|
| For example, you can refuse to use Google Chrome, and instead
| choose Firefox or Vivaldi. Your web experience will be slightly
| different, but the most important parts will remain the same:
| You type an address, you wait for it to load, and you access
| the content.
|
| On the other hand, refusing things like WhatsApp means there's
| a non-insignificant amount of people that use WhatsApp to
| communicate exclusively. This may not have impacts for you,
| personally (although I would be hesitant to believe that), but
| it definitely leaves out billions of people who communicate
| exclusively via WhatsApp.
|
| A similar thing happens, for example, if you refuse to use
| YouTube, which is the largest Internet video platform on the
| planet: You will have to refuse to watch any content that is
| only uploaded to YouTube, or put up with frontends that use
| YouTube in the background, or perhaps even be forced to pirate
| videos, neither of those three options is good for different
| reasons.
| JohnFen wrote:
| > the problem with this is that you're also refusing to
| interact with people who use those platforms.
|
| That's not a problem for me at all, honestly. I interact with
| my friends and family through other channels. Nobody I know
| uses these services exclusively.
|
| > it definitely leaves out billions of people who communicate
| exclusively via WhatsApp.
|
| I don't want or need to communicate with billions of people.
| I want and need to communicate with the people I know and
| care about.
|
| Don't get me wrong -- I'd use an IM app for the convenience
| if there was one that served my needs. But as long as each IM
| app is it's own island, then none of them serve my needs at
| all. I'd have to have a half dozen of them, and that's
| unmanageable and ridiculous.
___________________________________________________________________
(page generated 2023-12-31 23:01 UTC)