[ home / rules / faq ] [ overboard / sfw / alt ] [ leftypol / edu / labor / siberia / lgbt / latam / hobby / tech / games / anime / music / draw / AKM ] [ meta ] [ wiki / shop / tv / tiktok / twitter / patreon ] [ GET / ref / marx / booru ]

/tech/ - Technology

"Technology reveals the active relation of man to nature" - Karl Marx
Name
Options
Subject
Comment
Flag
File
Embed
Password(For file deletion.)

Not reporting is bourgeois


File: 1730980319240-0.png (126.31 KB, 1102x856, desktop_grandma.png)

File: 1730980319240-1.png (150.05 KB, 1102x856, desktop_group.png)

File: 1730980319240-2.png (192.73 KB, 402x884, mobile_grandchild.png)

File: 1730980319240-3.png (137.04 KB, 402x884, mobile_group.png)

File: 1730980319240-4.png (51.52 KB, 402x884, mobile_peerlist.png)

 

So I'm made a Tor Chat C library and two proof-of-concept UI clients (one in GTK4 for Windows/Linux/MacOS/etc, and one in Flutter for Android).

https://torx-chat.github.io/

https://github.com/TorX-Chat/​​​

tl;dr:

Tor hidden services with V3 authentication
Fully P2P. The project runs no servers.
Public groups (share by QR code or string, then join requests get encrypted and promulgate anonymously through the network until someone can decrypt it and facilitate your connection), which utilize unsigned messages
Private groups (send an invitation card to a friend you already connect to), which utilize signed messages (which other people can re-broadcast)
Single-use onions for friend requests (once you connect to your friend the first time, their onion gets destroyed and you both create fresh onions. This makes it safe to share friend requests over insecure methods like telephone, Twitter, etc, without the glowies being able to monitor them once your friend connects the first time)
SQLCipher for encrypted storage of messages, settings, whatever.

It supports:

Signed / unsigned Text
File Transfers ( full duplex, pretty fast )
Custom text/binary/streaming/etc protocols (Currently implemented in the UI: audio messages, animated gifs)

How it differs from every other Tor Chat:

You have a unique onion for everyone you connect to, except in groups.
Single-use OnionIDs for connecting
It's far faster, better, more reliable.
It's a C library, so you can write your own UI.
UI devs can design and implement their own protocols, without needing any modifications to the library.
Mining of onions, so instead of 56 character long onions, you can share 48 character long ones (or shorter if you have lots of time or CPU)

I'm currently the sole developer. I've reached a plateau where development is stable and so I'm looking for devs.

Here is a multi-use TorX-ID. You can add me for the lulz. (Warning: copy it, type it right, or scan the QR code; there is no checksum)
6rsnbdkgdokwziggtba2s35ifcnvna4fxmgricujlzirjqgf

File: 1730980571636.png (856 B, 248x248, leftypol.png)

Hit the image limit with screenshots.

Anyway, if you are interested, I'll try to answer questions here for a couple days and you can also hit me up on IRC. ​https://torx-chat.github.io/#support​​​

How does this compare to briar?

>>27029

"TorX" is a library, not the two proof-of-concept clients, so I'm not going to talk about "we have audio messages, but not voice chat and video chat" those features only exist or don't yet exist in the user interface, which is outside the scope of the library.

TorX, the library, supports P2P and group chats, and supports pushing any type of data, in the form of file transfers and custom protocols, over those connections to groups, individual peers (private messages), and individuals.

Regarding Briar:

So I haven't used Briar (it failed to install on my phone last time I tried), but based on my recollection of reviewing some of the source code and documentation, Briar is designed more with "resilience" in mind than anonymity. It's a P2P encrypted mesh network more than anything else, which is a cool concept aimed at developing countries.

However, they've taken a "kitchen sink" route of feature development, and developed everything in the user-land, so alternative clients (and desktop clients) lag vastly behind their "mobile first" clients. Their code-base is bloated and the underlying protocols are (as far as I can tell) not well separated.

My development method has been a focus on simplicity, separation, and non-redundancy to ensure auditability, both in the proof-of-concept UI layers and the library layer. (do one thing and do it well, at least in the library)

Importantly:

The main conceptual difference with Briar and Tor chats such as cwtch.im, AnonymousMessenger, Seek, or Ricochet-Refresh, which is the critical basis of my library, and the inspiration for it in the beginning, is that you have no global persona. You don't have one hidden service that identifies you as one person. To everyone you connect to, you are a different person. You have a unique hidden service. You don't have an avatar, and your friend sets your name. To one person you are "Bob", to another person you are "Frank", and in some group you might be "Sally". This applies both to your "name" (which your friend sets on their own device) and your onion (which you exchange at the first hand-shake).

Additionally, there are single-use hidden services used for the initial connection (the first hand-shake). I create a single-use hidden service, you connect to it, then it we exchange two fresh hidden services (one for you, one for me, unique to us) then my initial hidden service gets destroyed and we connect to each other over the fresh onions (you connect to mine, I connect to yours, and then we have two pipes for full-duplex data transfer). So, you don't need to share it over an impenetrably encrypted medium. You only need to make sure it gets to your friend without being modified.

(Note: there is also the option of "multiple use" onions, like that which I posted the QR code for. With those, each time a new person connects, we still create fresh onions and therefore fresh personas, but if I share this QR code here and on Facebook, obviously the glowies can make the connection. So I would either generate a separate multiple-use onionID for Facebook/Grandma, or much preferably, a single use onion for Grandma. With Briar or throw-away email accounts, this isn't an option. If I share my Briar account with you and on Facebook, I'm doxxed.)

Correction: ", which is outside the scope of the library. The library can send any type of data, any type of protocol, streaming or otherwise."

Correction: "The main conceptual difference between TorX and Briar / other Tor chats" …

>>27026
good job anon

>Single-use onions for friend requests (once you connect to your friend the first time, their onion gets destroyed and you both create fresh onions. This makes it safe to share friend requests over insecure methods like telephone, Twitter, etc, without the glowies being able to monitor them once your friend connects the first time)
Really interesting concept for a messaging app anon. I wonder if spinning up a lot of onions in that way would attract attention from the ISP or other threats.
>I'm currently the sole developer. I've reached a plateau where development is stable and so I'm looking for devs.
Imagine if 50 devs got involved and quickly got it operational and usable by normies.


Unique IPs: 5

[Return][Go to top] [Catalog] | [Home][Post a Reply]
Delete Post [ ]
[ home / rules / faq ] [ overboard / sfw / alt ] [ leftypol / edu / labor / siberia / lgbt / latam / hobby / tech / games / anime / music / draw / AKM ] [ meta ] [ wiki / shop / tv / tiktok / twitter / patreon ] [ GET / ref / marx / booru ]