Yes and no. It won’t be the same exact protocol. When you use SimpleX without proxy configuration, SimpleX will most likely connect to a clearnet server through an exit node. That’s much less ideal than the alternative, where you set the app to connect to the SimpleX Onion Services. The main difference is the person running the exit node will be able to tell someone is connecting to SimpleX server and they can mess with the connection. They won’t know who is connecting but still, the Onion Service is slightly better as the SimpleX client and server will have separate Tor-connection specific end-to-end encrypted link. I’m not sure if SimpleX client normally uses pinned certificates for server, but the Onion Addresses are pinned and those pin the server’s public key. The downside is 1-3 more Tor nodes for the proxcy chain (the exact depends on how the onion service is configured, some don’t care about server’s geolocation hiding so they don’t force that many nodes). So my recommendation is to at least test the Onion Service servers and see if it works well enough.
SimpleX has a footgun in that it silently falls back to non-anonymized connections if say someone messes with your app’s proxy settings and disables those. But since you’re always using Tails you’re on safe waters as misconfiguration on Tails is almost impossible. Thus your Tor connection will anonymize who you are from the server. Your contact without Tor will reveal to the server their IP. What is unclear at the moment is, can the server tie together single user’s queue numbers across sessions. That determines whether colluding SimpleX servers can determine that your contact is talking this amount at these hours with some specific anonymous contact (you). My recollection is that the clients deliver the queue addresses through the E2EE link so the servers indeed can’t perform that without end-to-end correlation via IP addresses.
So you should be mostly safe from contacts with less ideal practices, as long as the party interested in your communications isn’t so interested they’d track down all your buddies to read the conversations from their endpoints. That’s unlikely so I think you’re good.
My guess is this is just so that the contact has some time to react to the messages. Designing these apps usually has to be defensive against the inevitable reports of “my contact can’t see my messages”. But it could probably be a bit better in terms of resolution.
Mm, my advice is to spend the extra effort to get them to Signal instead of Telegram, it’ll pay off in the long run. Telegram is quite horrible as I’ve explained here WhatsApp vs Telegram - #8 by Gr86
Apparently it’s about generating a throwaway nickname for you as you join a 1:1 or group conversation. No idea why it’s advertised to contacts. Maybe it’s to reduce confusion spammy looking accounts contacting you might cause.
Depends on your use case. What you want associated with the cool nickname is best done under that. For the rest of the conversations an incognito mode alias might be better. Maybe you want to reveal something identifying but without associating it with your main account. It doesn’t have to be either or, flexibility helps.
Wrt this, it may be better to use the Onion Services for this feature, as if you’re the only person connecting to the server through some exit node on multiple occasions, the server, if present in the room making timing attacks, might be able to infer that the incognito alias belongs to same user as your main account. With Onion Services, all connections appear to originate from localhost on server side, so there’s no network level identifiers tying packets together.