Thanks, this is basically combination of somewhat central servers plus nearly always online model. I need to think about it - on the first glance I am not 100% sure the role Tor plays in this model.
Is this described somewhere in more details? As I said, I clicked around but didn’t see any docs about this.
The role of Tor is it facilitates anonymous, end-to-end encrypted connection between client and server, each messaging app is both a client (or a set of clients) and a server (a Tor Onion Service) that talk to each other through the Tor network. This way the traffic never exists the Tor network*.
The laptop/phone is the client, and Secure Drop is the server. With Briar the client-side Tor socket connects to the messaging app instead of browser, and on server side the socket again connects to the messaging app instead of web server. Whether messages flow from client to server (via POST request) or server to client (GET request) is doesn't really matter. The architecture where each user runs both server and client makes it effectively peer-to-peer.
Because messaging apps are these days expected to be always online, you pretty much need to have the server and client (and thus the app) always running.
---
*This is in contrast to Tor Messenger that, while it defaulted to Tor, used exit nodes unless the XMPP server was also a Tor Onion Service. While with Tor Messenger you were anonymous, XMPP server was usually not self-hosted thus a third party might have aggregated some metadata about when conversations between two accounts took place etc.
Things used to be even worse before Tor Messenger. With Pidgin it was possible to forget to configure Tor (unless you used XMPP Onion Service), and even worse, forget to enable OTR end-to-end encryption for every session, and if that happened the content could easily deanonymize you.
With Onion Service messaging, provided you verified the authenticity of the V3 onion address (or E2EE protocol's key fingerprint), you can be rest assured
1) connection is always E2EE
2) always inside Tor with no possibility to F up by connecting over 'clearnet'
3) no third party has access to communications metadata
Separate topic so replying in a separate sub thread
The clients are not always on, iOS and Android don’t like background processes, connections go down, battery runs out, etc. I understand how to build always on clients but it’s not a practical solution.
The directory service only receives an anonymous notification behind Tor proxyt chain that "hey, if someone asks for this .onion URL, point them to this node as it can provide further directions". It doesn't know "everything". The point of Tor has been from the beginning to compartmentalize what each node knows the the bare minimum.
Is this described somewhere in more details? As I said, I clicked around but didn’t see any docs about this.