3 ms·

The reason to re-encrypt and inject the bridged messages into Matrix is that they are then persisted serverside in a standard e2ee manner, which you can then ge

The reason to re-encrypt and inject the bridged messages into Matrix is that they are then persisted serverside in a standard e2ee manner, which you can then get at from any client that speaks Matrix (or is bridged in turn to Matrix) without that client or bridge having to know anything about the original network. So, in pidgin, you are stuck with pidgin’s UX whether you like it or not in order to access the remote network (unless you use a different multihead client). Whereas with a matrix bridge, running either serverside or clientside, you can then connect to the bridged conversations using any UX you like (of which there are now hundreds of Matrix apps of different flavours). Moreover, each chat’s history gets decentralised across any other Matrix servers whose users are participating in that conversation. The architecture is more like bitlbee, for those who know it - but using Matrix rather than IRC as the protocol between the client and bitlbee, so the richness of the comms is preserved (rather than flattening everything to IRC).

iforgotpassword 5y ago
Ah yes, having the client push messages back to the matrix network for later retrieval on other devices makes sense. It would however mean that the device running the bride should be either running most of the time, or that the hypothetical API of that proprietary service must be ready to be accessed from multiple clients at once, in case my home and work laptop are running at the same time, and both have a client side bridge, because usually only one of them is online. Realistically I'd run a dedicated bridge on a home server or vps then, but I guess not everyone wants to do that. But one step at a time I guess :)
- Arathorn 5y ago
  > It would however mean that the device running the bridge should be either running most of the time Typically a client-side bridge would run on your current device, so if it can't connect to the server, then you're probably out of connectivity anyway so it's not a disaster. > or that the hypothetical API of that proprietary service must be ready to be accessed from multiple clients at once I'd expect that the gatekeeper's API would allow access from multiple clients, just as the normal clients would. > Realistically I'd run a dedicated bridge on a home server or vps then, but I guess not everyone wants to do that. The problem is that if you run a dedicated bridge to an E2EE messenger like WhatsApp from a VPS, then that VPS becomes a massive attack target. Hence looking for safer places to run it - e.g. buried inside your phone, where if the phone is compromised, you're already toast.
  - iforgotpassword 5y ago
    > I'd expect that the gatekeeper's API would allow access from multiple clients, just as the normal clients would I'm just cynical enough to believe those gatekeepers would totally accidentally make their API as cumbersome to use as possible while still technically meeting the requirements. ;) > The problem is that if you run a dedicated bridge to an E2EE messenger like WhatsApp from a VPS, then that VPS becomes a massive attack target. The usual cautionary disclaimers when self-hosting apply. But probably still a less juicy target than the hypothetical bridge provider TFA outlines. Someone offering Whatsapp bridging as a service is quite a nice attack target.
    - chagaif 5y ago
      I think WhatsApp would need something equivalent to the dehydrated device on Matrix so that you could receive messages even if you're offline on all devices, I guess they're need to provide an open API for that as well?

iforgotpassword 5y ago

Ah yes, having the client push messages back to the matrix network for later retrieval on other devices makes sense. It would however mean that the device running the bride should be either running most of the time, or that the hypothetical API of that proprietary service must be ready to be accessed from multiple clients at once, in case my home and work laptop are running at the same time, and both have a client side bridge, because usually only one of them is online. Realistically I'd run a dedicated bridge on a home server or vps then, but I guess not everyone wants to do that. But one step at a time I guess :)

Arathorn 5y ago
> It would however mean that the device running the bridge should be either running most of the time Typically a client-side bridge would run on your current device, so if it can't connect to the server, then you're probably out of connectivity anyway so it's not a disaster. > or that the hypothetical API of that proprietary service must be ready to be accessed from multiple clients at once I'd expect that the gatekeeper's API would allow access from multiple clients, just as the normal clients would. > Realistically I'd run a dedicated bridge on a home server or vps then, but I guess not everyone wants to do that. The problem is that if you run a dedicated bridge to an E2EE messenger like WhatsApp from a VPS, then that VPS becomes a massive attack target. Hence looking for safer places to run it - e.g. buried inside your phone, where if the phone is compromised, you're already toast.
- iforgotpassword 5y ago
  > I'd expect that the gatekeeper's API would allow access from multiple clients, just as the normal clients would I'm just cynical enough to believe those gatekeepers would totally accidentally make their API as cumbersome to use as possible while still technically meeting the requirements. ;) > The problem is that if you run a dedicated bridge to an E2EE messenger like WhatsApp from a VPS, then that VPS becomes a massive attack target. The usual cautionary disclaimers when self-hosting apply. But probably still a less juicy target than the hypothetical bridge provider TFA outlines. Someone offering Whatsapp bridging as a service is quite a nice attack target.
  - chagaif 5y ago
    I think WhatsApp would need something equivalent to the dehydrated device on Matrix so that you could receive messages even if you're offline on all devices, I guess they're need to provide an open API for that as well?