> since gmail requires TLS i highly doubt that there are many servers out there that don't support it.

Gmail doesn’t require TLS, unless by that you mean that their webmail interface is TLS only. Like every other mail provider, they do opportunistic TLS on external delivery, and TLS on MUA connections (SMTP and IMAP) is largely at the mercy of user configuration.

The fact that people seem to think that TLS is a mainstay of the email ecosystem is clearly part of the problem here.

As for the rest of this: I’ve hammered on about Signal because it’s the naive right choice, but it’s ultimately up to you to decide whether your phone number is an acceptable public identifier. But even if it isn’t, there is so much out there that’s indisputably better than this mess: Matrix or even iMessage (with an email identifier instead of a phone) would be better.

▲

em-bee 7 hours ago | parent [-]

Gmail doesn’t require TLS

according to this article it does:

https://www.valimail.com/blog/the-new-requirements-for-email...

and for one i think this is a good thing.

otoh, according to this it doesn't:

https://support.google.com/mail/answer/6330403

but https://transparencyreport.google.com/safer-email/overview shows that by now almost all emails sent and received by google go through TLS which i believe can be used as a proxy to assume that most servers out there now support TLS.

signal fixed their phone number problem, so that is no longer an issue.

matrix is not reliable enough. the encryption can break in the sense that messages can no longer be read. i am basically required to have a second unencrypted backchannel (or use a different app, but then why even bother) to make sure i can reach someone. (the issue i experienced could be due to a misconfiguration of a matrix server, but that's a bug in itself. it should not be possible to change the configuration of a server in such a way that my messages arrive but can not be decrypted anymore.)

▲

Arathorn 7 hours ago | parent [-]

matrix encryption reliability should be fixed (at least on element x/web + synapse combos) as of Sept 2024.

what server & client are you using?

	▲	em-bee 2 hours ago \| parent [-]
		the client is fluffychat 1.26.1. server A and B below are both synapse 1.132.0, server C i don't know. the situation is as follows: there are multiple servers and users involved. let me name the servers A, B, C and matrix.org. i have accounts on A and B, and my friend has an account on C. others have accounts on matrix.org. all of us are in a group on matrix.org (i am in the group with both of my accounts from A and B). with both my accounts i can see but not decrypt messages from before i joined. yet the groups chat history setting is "visible for all participants" and not "visible from joining" on account A i can read messages since joining, except for those from my friend on C. my friend on C also can not read messages from A in the group. nor can we talk to each other directly. now, A is a very restricted server that blocks many other servers as a spam protection measure. as far as i can tell, it does block server C but it does not block B. B doesn't have any blocks. that i am unable to open a direct connection to C from server A is expected because of the block. from server B this is not a problem. B can also read all messages in the group (after the join date) what bothers me is this: even if server A blocks server C, why does it block messages that C sends into a group on matrix.org? groups should either be allowed fully or not allowed at all. it doesn't make sense that groups break for members on blocked servers. now, A blocking C is not intentional and i could ask the admin to remove the block, but lets assume that it is intentional because maybe there are many spammers on C and my friend is an exception. what i wonder is why even allow blocking in this form at all? i am the only member from server A in the group. what benefit does server A have from blocking users from C in the group i joined on matrix.org? i could understand if A doesn't want people from C to join groups on server A, or connect to people on server A. so block directly incoming connections. but why block messages in a group that's not on server A? i joined that group. dealing with C should only be my problem. also, the messages aren't even blocked. they just can't be decrypted. so traffic is not even reduced. this is not encryption randomly breaking. this looks more like a problem with how blocking works to me. also i think it would make sense that despite blocks, individual members from A should be allowed to initiate connections to users on blocked servers. it's connections from C to A we don't trust, but connections from A to C should be fine, because everyone on A is trusted. the way i see it, if i am allowed to join a group, i should be able to see all messages in the group, and everyone should be able to see my messages, even from people on blocked servers and no blocking rule should be able to prevent that. if i should not see those messages then i should not even be allowed into the group. once i am in a group, there should be no blocks getting in the way. users from blocked servers should not be able to access groups or contact people on the blocking server. and maybe users from the blocking server should not be allowed to join groups or talk to people on blocked servers. but that would ideally be a separate permission. another issue is the key handling. i find it confusing as to what i need to back up so that i can reopen a connection from another device. deltachat has a simple export profile. i save that and i import it on another device and i am done.