I played with @delta and *damn* is it sweet!
It uses my e-mail account as transport, but encrypts using OpenPGP, and feels like IM. Has groups and all.
It's not exactly a @signalapp replacement (yet?): a). it obviously leaks metadata, as it uses e-mail as transport; and b), it uses Autocrypt for key exchange and I have not found a way to *pin* known keys for certain accounts.
But it's interesting! I will keep an eye on it; saga shows why we need to move away from walled gardens.
To be fair, signal also leaks metadata of the form of which-ip-talked-to-which-ip to signal the service (but signal the service promises to throw it away immediately). This case is both worse (because there are more entities involved) and better (because metadata is leaked only to entities somehow related to the sender and recipient as opposed to some single entity that cannot be avoided).
@robryk yeah, fair. #ItsComplicated
What I really wish is for @briar to have store-and-forward and an iOS client. But that's not going to happen anytime soon, as far as I understand.
@rysiek @briar @delta @signalapp
Yeah, it's complicated and I got really annoyed when people claimed that sealed sender made that metadata unavailable to signal the service...
Which part is not going to happen anytime soon?
@rysiek @briar @delta @signalapp
I get the complications around everything related to iOS (or rather: get them vaguely and shy away from learning about their precise nature).
That said, I'm confused about the other part:
On the "why is this even necessary" side: if we use Tor we have some sort of poor protection of metadata. To get a better protection you need store-and-forward via peers that do not happen to also be your contacts. I thought previously that the main point of s&f in briar is to make it work over bluetooth (made into a mesh by having devices move around), not to operate it over Internet. Was I wrong?
My state of understanding (which I should improve, but it's too late today) was that store-and-forward in briar is intended to work for intermediate peers that are in physical proximity, as at least a measure to combat DoS.
I guess I don't see how a store and forward (that I can imagine) that could be usable over the wide Internet would help with metadata protection. You ~can't use peers unrelated to sender or receiver for storing messages (because this invites trivially exploitable DoS issues), and using peers related to either side moves the potentially-exposed metadata from "who's talking to whom" to "who uses whom as an intermediate peer", which admittedly does seem somewhat better (but not as much as I thought you'd want the situation to improve).
@robryk I never said store-and-forward is supposed to help with metadata protection.
It's just something we expect from an IM app: to be able to send a message and have it delivered, even if we can't get online simultaneously with the recipient.
@briar