SEPA is the direct banking standard in Europe. Basically every transaction between banks follows that standard. If you’re doing business in Europe, that’s the most direct way you can go. Many other companies and their transactions follow the SEPA standard somewhere anyway. An SEPA mandate is pretty safe for the customer, too. It can be canceled by the account owner at any time. It does not have any additional insurance layer, though.

Haha. 🤣 Made my day

Tbh, I understand the problem. There are just so many volunteers for making newer developments work on every platform. Streamlining the development and easing the load on the volunteer devs seems a good idea. Having that said, it’s ofc a pity to drop support for devices. At least the LTS kernels will support the current support for a while and the vibrant Linux community will find a good way to work it out, I have no doubt. Many machines, in particular old ones, run with very old kernels to begin with…

I’m not sure I understand this, tbh. Does that mean the P2P network works on a chat group basis? Or does the user explicitly choose who to build a P2P network with? And then, there are lots of follow up questions already looking around the corner.

Their website seems to explain very little and the app itself is closed source. Although there are open source dependencies, it’s for instance unclear whether they are complete. So I guess it’ll all come down to trust into the software and the company. Btw. their privacy statement allows the usage of aggregate data for marketing purposes and the sharing of data with third parties, such as search engines. And latest at that point I’d rather self-host a matrix instance.

I dunno. P2P traffic always seems to overburden light users and it would indeed require the apps to always run in the background to relay the traffic. Although the idea seems compelling I wouldn’t install the software on a machine of mine.

Using it for years and am fully satisfied. Basically, any imap client capable of encryption will do.

Schleswig-Holstein therefore follows the general strategy to move towards an open source driven administration. In fact, several federn institution already migrated to the openDesk administration bundle (https://gitlab.opencode.de/bmi/opendesk/). Great!

Checked again. Beeper will be running “local bridges”. Once these are implemented into a modular system, there is not really a need for a local chat protocol in my understanding. The matrix connection can simply become another bridge and a Beeper server for Beeper chats would basically be yet another matrix server.

https://blog.beeper.com/2024/06/04/2024-beeper-roadmap/?ref=textscom

The FAQ says that “all integrations were implemented in-house using the Texts Platform SDK”. Whether that sdk is a derivative of the Matrix protocol? No idea. Texts.com does not offer connections to matrix, which kind of suggests it’s not 🤷🏼‍♂️ We will have to see whether the announced unified app will be running a solution based on Matrix or not.

Not exactly what was asked but a thought as I’ve been considering the same. After merging with Texts.com, Beeper seems to be redesigning the bridge architecture. I read that the implementation will move towards running the bridges on the client device so that the decryption is happening in the RAM of the end user’s machine rather than the server. In that case, the mentioned security problem will be at least partially resolved. Self-hosting the bridges is already possible now. One will still have to trust Beeper, though. As I am using their software already, it looks like there’s no reason, yet, to mistrust them.