Depends on how it’s implemented. Anyone using a “media proxy” will see their discord bridged media probably fail to load (outside of possible caches) after a day. Anyone who has their bridge configured to reupload discord media to their homeserver should see no change.
Not just the “lack of APKs”, but the lack of a FOSS build. As you noted, it is possible to instal an AAB by extracting the APK(s) inside, but that doesn’t magically remove non-foss libraries.
The only build is an aab file. This is a Play Store bundle file, not an APK, so not directly installable in Android without the Google Play Store.
The only build being a Google Play release also indicates that non-foss libraries were likely included, such as the FCM libraries, as is common for GPlay releases of otherwise FOSS projects.
As far as I’m concerned, Element X for Android is not available yet, unless either building from source (with modifications to included libraries), or by using a non-FOSS version from GPlay.
Your iPhone 13 syncs slower over USB because Apple decided to stay on Lightning connectors, which use USB 2.0 on the other end. Although FireWire was faster back when it co-existed with USB, the USB standard has surpassed it a long time ago with more power, faster speeds, and better physical connectors.
It is up to the device manufacturer. Google develops Android Open Source Project (AOSP) and the Google apps and services (Google Play Store for example). This feature (afaik) is in AOSP.
Google developed the version in AOSP, which is open source. Device manufacturers are then able to change the code as needed. If a device manufacturer uses base AOSP with (nearly) no changes, the fix Google made will be applied when the AOSP update goes through the manufacturers build pipeline and to the device (on Google Pixel phones for example). For manufacturers that have a lot of changes compared to AOSP (Xiaomi, Samsung, and many more), they might have to create their own fix that works on their own version of Android, which takes a lot longer.
One of the reasons people run “Custom ROMs” on their Android phone is to be responsible themselves for updates and fixes instead of the device manufacturer.
The websocket API is being deprecated in 0.18.0 (next major release)
The same “rumors” exist about Matrix. According to some, “a lot of metadata is unencrypted”. While somewhat true, there’s literally no way to be able to deliver a message from person A to person B without knowing who the message is from and who it’s going to, especially on a decentralized platform. Most of the (not E2EE) metadata sent with an event in Matrix needs to be read by the homeserver, and thus can’t be E2EE.
I don’t have a direct source other than the source code of the software they use: https://github.com/mautrix/signal
When using one of their “cloud hosted” bridges, the bridge software (that connects between Matrix/Beeper and other protocols) has to read all message content. Otherwise, it’s impossible to bridge to another protocol. E2EE becomes end (other users) to bridge (beeper) encryption.
With “local hosted” bridges, E2EE stays intact, but messages can’t be sent/received if the device hosting the bridge is unavailable.
In the future, with MLS (a different E2EE protocol), it could be possible to keep E2EE even when bridging to Matrix on cloud hosted bridges.