4 ms·

This is a single protocol client, which can be replaced by any Matrix client. This is why it is so good

by kitkat_new 6y ago

pseudalopex 6y ago
Bridges make the server a multi protocol client.
- kitkat_new 6y ago
  not really, they are all individual pieces put together - independent of the server
  - pseudalopex 6y ago
    They're called bridges because they connect the Matrix server to the other servers. They aren't independent. And reverse engineering protocol changes wouldn't be easier if they were.
  - Andrew_nenakhov 6y ago
    What is discussed here is nothing new. I ran a jabber ICQ transport for myself and colleagues as far back as in 2005. It was a constant source of pain. Whenever the ICQ protocol changed, you had to wait till developers of transport updated the lib, so you could resume the service. If anything, now it is far easier for service maintainers to update the protocol because the app distribution model got much more efficient - just one tap on the smartphone, so you can just suspend the functionality until the users updates, whereas ICQ devs had to rely on users manually downloading and installing the update to their official apps, slowing the update cycle by many months/years. TLDR: It didn't work then, won't work now.
    - kitkat_new 6y ago
      it works already - and only the bridge needs to be updated. Everything else can stay the same.
      - Andrew_nenakhov 6y ago
        Unlike you, I have actually experienced running the bridge that 'only needs to be updated'. Good luck with that.
Andrew_nenakhov 6y ago
What you refer to is called 'transport',such transports for xmpp exist for more than 20 years. They didn't fly because service owners don't really want them to. Sometimes services resist actively, sometimes passively. The protocol you use is irrelevant, xmpp, matrix, email, whatever - this is never-ending game of catch up which the service owner will win, because he needs users to use their stock app and all their metadata.
philsnow 6y ago
The problem is not the client at all. Look at the history of libpurple/gaim. My chat setup used to be an irc client connected to bitlbee (which uses libpurple), and (way back when) the various chat system owners would either intentionally or unintentionally break the integrations fairly regularly. They have no incentive to keep their API stable since they control their official client. On top of this, when you try to bridge disparate comms platforms together, you end up with the client having only the common subset of functionality, or with the client emulating functionality clumsily. The example I'm thinking of is in iMessage, if you're on a group text thread with people who are on SMS instead of iMessage, "tapback" reactions (the thumbs-up, exclamation, haha, etc ones) show up as "<name> emphasized '<the full text of the message they !!ed>'".
- kitkat_new 6y ago
  it's way harder to make all Matrix clients support all protocols and somehow sync them properly than to write a App Service that can be plugged to a server.
  - pseudalopex 6y ago
    Most multi protocol clients used the same libraries. The hard part was reverse engineering the protocol changes.
- GekkePrutser 6y ago
  For me partial support is a key feature. Not having to send read notifications, not having to look at bs like stickers and the ability to ignore chat deletions is really great about bridging :)
Dirlewanger 6y ago
Any one of those services can instantly plug up the hole (especially the Apple one) and it's over. Building a business reliant on other company's platforms rarely ends well.

This is a single protocol client, which can be replaced by any Matrix client. This is why it is so good

pseudalopex 6y ago

Bridges make the server a multi protocol client.

kitkat_new 6y ago
not really, they are all individual pieces put together - independent of the server
- pseudalopex 6y ago
  They're called bridges because they connect the Matrix server to the other servers. They aren't independent. And reverse engineering protocol changes wouldn't be easier if they were.
- Andrew_nenakhov 6y ago
  What is discussed here is nothing new. I ran a jabber ICQ transport for myself and colleagues as far back as in 2005. It was a constant source of pain. Whenever the ICQ protocol changed, you had to wait till developers of transport updated the lib, so you could resume the service. If anything, now it is far easier for service maintainers to update the protocol because the app distribution model got much more efficient - just one tap on the smartphone, so you can just suspend the functionality until the users updates, whereas ICQ devs had to rely on users manually downloading and installing the update to their official apps, slowing the update cycle by many months/years. TLDR: It didn't work then, won't work now.
  - kitkat_new 6y ago
    it works already - and only the bridge needs to be updated. Everything else can stay the same.
    - Andrew_nenakhov 6y ago
      Unlike you, I have actually experienced running the bridge that 'only needs to be updated'. Good luck with that.

Andrew_nenakhov 6y ago

What you refer to is called 'transport',such transports for xmpp exist for more than 20 years. They didn't fly because service owners don't really want them to. Sometimes services resist actively, sometimes passively. The protocol you use is irrelevant, xmpp, matrix, email, whatever - this is never-ending game of catch up which the service owner will win, because he needs users to use their stock app and all their metadata.

philsnow 6y ago

The problem is not the client at all. Look at the history of libpurple/gaim. My chat setup used to be an irc client connected to bitlbee (which uses libpurple), and (way back when) the various chat system owners would either intentionally or unintentionally break the integrations fairly regularly. They have no incentive to keep their API stable since they control their official client. On top of this, when you try to bridge disparate comms platforms together, you end up with the client having only the common subset of functionality, or with the client emulating functionality clumsily. The example I'm thinking of is in iMessage, if you're on a group text thread with people who are on SMS instead of iMessage, "tapback" reactions (the thumbs-up, exclamation, haha, etc ones) show up as "<name> emphasized '<the full text of the message they !!ed>'".

kitkat_new 6y ago
it's way harder to make all Matrix clients support all protocols and somehow sync them properly than to write a App Service that can be plugged to a server.
- pseudalopex 6y ago
  Most multi protocol clients used the same libraries. The hard part was reverse engineering the protocol changes.
GekkePrutser 6y ago
For me partial support is a key feature. Not having to send read notifications, not having to look at bs like stickers and the ability to ignore chat deletions is really great about bridging :)

Dirlewanger 6y ago

Any one of those services can instantly plug up the hole (especially the Apple one) and it's over. Building a business reliant on other company's platforms rarely ends well.