In matters where a server is needed, you generally have three options:

• self-host
• get a friend/colleague/employer to host
• pay for a host

I have seen that interview. Neither the excerpt you quoted nor the rest of the interview is what Thinker@lemmy.world claimed.

Sync to a CalDAV/CardDAV server instead of to Google. If you’re up for self-hosting, Radicale is a good and simple one.

I use DAVx⁵ on Android and Thunderbird on the desktop. Other sync clients are listed here: https://radicale.org/v3.html#supported-clients

the explicit declared direction is that Rust should become an increasingly large part of the Linux kernel.

Who explicitly declared this? Where?

Thanks!

My “client” is Lemmy’s native UI, and is rendering it correctly according to markdown and html specs. If your client is wrapping it or using a variable-width font, then that’s convenient for you in this case, but it’s violating the spec. (This is somewhat common in mobile apps, so I guess you’re reading on a phone.)

OP, can you please remove the four spaces preceding each paragraph in your post? That syntax is for code formatting. It triggers a monospace font and puts each paragraph into a single line, forcing readers into painstaking horizontal scrolling to be able to read each one. It’s like trying to read a book through a keyhole.

Agreed.

To be fair, though, OP’s username does say that he is a twelve-year-old. :)

How would the sender prevent messages from going to the admin user that joined the room?

It wouldn’t matter if a rogue admin eavesdropped on an E2EE room, because they would see encrypted blobs where the message content would be. That’s what E2EE is for.

https://en.wikipedia.org/wiki/End-to-end_encryption

How would the sender prevent messages from going to the admin user that joined the room?

You’re conflating multiple things. Merely joining a room does not grant access to message decryption keys.

I respect your curiosity, but I think you’re going to have to familiarize yourself with the software and concepts to get a detailed understanding of how all this stuff works. If you’re technically inclined, I suggest reading the protocol spec, or at least the parts that interest you. You could also drop in to the chat room and ask more questions there: #matrix:matrix.org

SimpleX has some interesting ideas, but also some shortcomings for people who want a practical messaging service. For example:

• It is funded by venture capital, which calls into question its longevity, and even if it does manage to stick around, suggests that it will be leveraged to exploit people once the user base is large enough.
• Its queue servers delete messages if they are not delivered within a certain time frame (21 days by default). Good luck if you take a vacation off-grid for a few weeks.
• No multi-device support. (This means a single account accessed concurrently from multiple independent devices.) The closest it comes is locally tethering a mobile device to a computer.
• Establishing new contacts requires sharing a large link or QR code, which is not always convenient.
• No support for group calls.

I would not recommend it for talking to family members and people in general, which is what OP requested.

But who/what gets to decide who the intended recipients are?

The sender, of course.

Can’t the homeserver admin just join the channel and then the other members would exchange keys automatically and now they can see what people say?

No. Verification prevents that.

a compromised or hostile home server can still take over the room

A compromised server could affect a denial of service attack against its users, of course. The attacker could do the same thing by simply turning off the server. That’s true on all platforms that use servers. A reasonable response would be to switch to a different server.

That admin (or even a newly minted user) can then send events

Exactly what events do you think would be dangerous?

or listen on the conversations.

No. End-to-end encryption ensures that only the intended endpoints can read the messages. Older Matrix clients have a setting to block the user from sending messages to unverified devices/sessions, in case they somehow don’t understand the meaning of a bright red warning icon. I think newer ones (e.g. Element X) enforce that mode; if you’re concerned about this, you could check for yourself, but…

not everyone will pay attention to unverified warnings

…unfortunately, there are no guarantees when trying to fix human behavior. If you need a messaging app to make it hard for your contacts to do something obviously foolish, then I suggest waiting until Matrix 2.0 is officially released and implemented in the clients. The beta versions of Element X, for example, look like everything is locked down to avoid human mistakes like the one you’re describing.

even with E2EE, the admins of a homeserver can still impersonate you

No, they cannot. Your homeserver admin could create an impostor login session on your account, but it would be pointless with E2EE, because it would be flagged with an obviously visible warning. You and all of your contacts would see that the impostor session was not verified as you (this typically shows up as a bright red icon on the impostor and another one on the room they’re in). Also, the impostor would be unable to read your communications.

Are there any real-world examples where encryption backdoors have been successfully used without compromising cybersecurity?

No. That concept is an oxymoron.

The linked page clearly states this about the Facebook presence:

“The Debian page is non-official. It is maintained by Raphaël Hertzog.”

Debian user here, happy to be running such a low-maintenance OS. Thanks for making me laugh out loud.

I like IRC, too, but I have to admit some of its mechanisms are annoying and not very good. (Nickserv for identity management, for example.)

I don’t think IRC is as good as Matrix for decentralisation, either. If an IRC host network goes down or is taken over, it’s very disruptive to the communities using it, as we saw with the freenode fiasco.

!smartphone_required@lemmy.sdf.org

!smartphone_required@lemmy.sdf.org

Mainly Organic Maps

Occasionally OsmAnd~, though I mostly avoid it because I found building it from source to be more annoying than it should have been, and didn’t care for a marketing campaign they ran a while back.