Egregoros

of course you can. they just won't get it before they come online. which is kind of duh! for instant messaging, isn't it?

now, if you're concerned about the two of us never being online at the same time, install Jami on your home server, or on a VPS, link your account there, and it will get a copy of your messages whenever you send or receive them, and it will transfer them to your peers or to your own device whenever they come online.

now, if that's not good enough for you, I guess you really prefer to share your conversations with third parties for them to do this for you. me, I prefer my autonomy.

CC: @davep@infosec.exchange @rysiek@mstdn.social

nope. I'm told they don't even have access to data, or even metadata, thanks to some technology indistinguishable from magic in its protocol. but I won't pretend I really understand how that works.

the main problem with signal is their insistence on demanding a snoop phone to get started. that spoils the entire experience, and probably exposes its users' conversations, metadata and even secret keys to third parties. see https://blog.lx.oliva.nom.br/2026-02-01-signal-of-awareness.en.html and https://blog.lx.oliva.nom.br/2026-01-25-compromising-encryption-keys.en.html

the secondary problem with signal is its insistence on centralization. this makes the "not being online at the same time" a problem for all its users, when their centralized servers are not online

CC: @feld@friedcheese.us @rysiek@mstdn.social

@lxo @feld @rysiek
I agree with the centralisation risk. But those articles have nothing to do with needing a telephone number. They're more of an indictment of Windows and tend to back up Signal's worry about LLMs embedded into the OS.

If your endpoint is compromised, anything you read is also compromised.

As for the "magic" comment, it's just that they encrypt basically all the metadata that the likes of WhatsApp don't. And with the double ratchet protocol they can't decrypt that data. They *could* make logs of who called or messaged who, but don't. If this were decentralised, what's to stop a bad actor logging such information? Just curious. It may need a rethink of the whole architecture (I'm not saying that's a bad thing by the way).

@davep @lxo @rysiek

> If this were decentralised, what's to stop a bad actor logging such information?

From the DeltaChat perspective, it's assumed that the servers may get compromised.

So if you and another contact are using the same server (relay), and the relay is compromised, the attacker will be able to see the IP addresses of the clients. This is not ideal, but it's about all they get. They can measure message sizes and guess what's inside but it's not very useful in most cases unless they're trying to pin down the transfer of a specific file or something.

If each contact is using a different server (relay), then this is trickier. They can only see the IP address of the user that logs directly into the server they've compromised, and they can't even be sure the same contact is sending the surveilled target messages if the other client's email address keeps changing -- even bouncing around and coming from completely different servers (relays). This is a thing you can do now and will be automated in the not too distant future.