TorX: "Metadata-safe Tor Chat Library"

[TorX]

"it's complicated" "yes, Microsoft and Apple probably know which applications you are running". "yes, Microsoft and Apple probably know which applications you are running"

I want to briefly expand on this:
I said "it's complicated" because to utilize these methods, law enforcement would have to engage with NSA-tier tools of mass surveillance (or ask the companies nicely, since they frequently just comply), which in many countries either would not be legal or at least would not be possible without a concept of a general warrant. I'm not in the EU so I can't say how EU law would apply.
To put it into context, utilizing Google or Apple/Microsoft to request them to check which people in the county/state/country/world are running specific software is about on the same level, or above, asking local ISPs to give lists of anyone in their jurisdiction who were connected to Tor entry nodes or public bridges at a particular time. (I recall a case where someone emailed a bomb threat to their university was caught because they were the only person on the university WiFi who had been using Tor at the moment the email was sent)
If we're in America, short of FISA courts, if a law enforcement agency or the feds obtain this data and utilize it to suspect you have done something, they're probably either going to utilize parallel construction (find some other way to nail you) or just offer a plea bargain rather than directly bring it to court.

Had similar ideas to that in some other situations, I think it's a good model. Implementing it in the backend would probably be the best solution to allow dropping messages from a bad actor early on.

Making subscribable moderation a back-end feature wouldn't drop the messages earlier because ignoring messages (blocking the peer and dropping their messages) is already a back-end feature. How an ignore is triggered (either by a user's click or a user's voluntary subscription to a friendly janny) would not affect how fast or efficiently their messages drop. That being said, where features are generally useful, lightweight, and anticipated to be utilized by all clients, I generally put them in the library for consistency and convenience. I'm just saying, hypothetically speaking, I wouldn't have to, and any client could implement this or other moderation ideas on their own, using custom protocols, or theorize their own "spam detection".

Downside though is that you can't update a dependency without a full rebuild.

Yeah I designed TorX as a library partially because so many things that bundle Tor either have lazy developers, incompetent ones, or end up utlized long after they become abandonware.
It's not uncommon to see months or years old (I think Orbot comes to mind as a particularly bad offender) binaries being shipped in even freshly compiled .APK files because the developers haven't set up a proper build chain to actually build fresh builds of Tor every time they make a release. The recent issues in Europe were connected to abandonware shipping with a long-outdated version of Tor.

How does it synchronize group messages currently? The private chat way of waiting until the peer coming online and sending the message doesn't seem too feasible if there's a bunch of members. Maybe some members can store the messages and send them to peers that come online, but who to encrypt the intermediate message for seems tricky offhand, or maybe you can sign them and relay the message, which seems doable.

The code related to Group Chats (Public Groups, Private Groups, and Private Message) is quite new and is highly-functional spagetti-tier. It needs vast cleanup for readability and then after that features such as automatic relaying of messages can be considered for implemention in the library. Current "Public Group" messages and "Private Messages" are unsigned, so they can never be relayed (and I think it should stay this way, I don't like the idea of signing messages without being very clear about it to the user and allowing an alternative), but "Private Group" (invite-only) public messages are dated and signed, explicitly so they can be relayed. Currently relaying requires user interaction at the UI level (long press a message, click Resend, see function `message_resend()` in the source code), but automatic relaying could be facilitated in the future after the spagetti gets cleaned up. One disincentive is that it would increase how chatty groups are in the background and a lot of thought needs to go into designing if/when/how automated (backend) requests for relaying messages occurs.
If you've built the software, long-press a message someone sent to you and click "Edit" (available except for public messages in Private Groups). Have fun with that and then you'll realize why I don't want messages signed unless there is a clear and well-defined reason.

I'm excited for this project. I'll read through the code for now and will contribute stuff if neccesary.

Your contributions will be much appreciated!