TOX – A New Kind of Instant Messaging
tox.chat
tox.chat
I'll admit I'm not a networking guru here, and I'm absolutely in favor of decentralized communications ...so my question above is not at all to knock on Tox; its me really wanting to know how the above scenario would play out...because I often need to bounce between a few different computers. Anyone know how this would work?
Side note: I am currently using matrix protocol via a synapse/matrix.org home server (using the chat client from https://riot.im/), so for any computer that I use/jump to, I'm represented by my home server (up in the cloud)...so that makes sense to me. I just don't get how jumping computers would work on Tox. Anyone know?
I sometimes get up and walk away from a computer mid conversation, expecting to continue the conversation on my phone. It's the same reason I won't be using google allo. I need conversations to "sync" across mobile and PC.
I'm not going to sit at a desk all day chatting on my phone, and I'm not going to miss messages just because I went mobile.
I saw somewhere in a previous tox chat, that a possible solution would be a way to pin identities together (i say from desktop "this mobile is me" and from mobile "this desktop is me" and when they match, allow them to pair). And then send every message encrypted to both peers. If you have 5 devices linked, tox would behind the scenes send the message to 5 different destinations.
They havent done anything like this yet as far as I know.
I dislike existing systems that implement this kind of model since it is too easy for a ghost device to be getting copies of everything. My phone transitioning to different UX clients with notifications/verifications of transitions on its own UX is better.
But, I dont think a client should transition from one to the other either. I often just get up and walk away from my computer with chats in the background. I wouldnt want to have to tell it to transition.
If you treat multiple devices equally (even when you routinely leave them unatended) then things quickly fall apart and no paranoia helps.
You could look at kerberos for an example of this style of loaning limited tickets for credentials.
Yet, it's written in C, it hasn't had a security audit, it does not publish a list of security risks and mitigations, and, regarding its roots in 4chan, see for yourself: https://github.com/irungentoo/toxcore/issues/1186
As for the fact that it's written in C, GPG, Tor, Psyc, and many other pieces of security software that you trust are written in C. It's dangerous, but writing secure apps isn't impossible.
My point exactly. It's dangerous and if it's not paired with many good security practices, it's better not to advertise it as "protect you from XYZ".
As for security risks and mitigations, I'd like to do that when we have a web presence with space for it. Right now, the web presence is fairly poor (http://toktok.github.io/). The specification contains some security risks and mitigations.
P.S. Now I see activity in new core repo,that's cool
Look in the profile or settings panel of your client to get your Tox ID which should look something like:
56A1ADE4B65B86BCD51CC73E2CD4E542179F47959FE3E0E21B4B0ACDADE51855D34D34D37CB5"
Yuk! I see this flaw so many products like this, just about anything p2p, blockchain addresses, commit ids, etc. I think there is zero chance of getting anyone who is not technology elite to adopt a product with UX that rotates around these untypeable/unpronounceable/immemorable identifiers. Why aren't Identicons(https://en.wikipedia.org/wiki/Identicon) or QR codes used more?
Nothing stops you from turning that hash into a QR code (afaik Antox does) - but then how do you copy & paste it?
Human-meaningful: Meaningful and memorable (low-entropy) names are provided to the users.
Secure: Any entity in the system can act maliciously, including the majority of the entities or the available computational power.
Decentralized: There is still only one, unique and specific entity to which a name resolves.
Edit: Ah, I see; "including the majority of the entities" would exclude Namecoin from being a proper solution to Zooko's Triangle.
Are suggestions?
Things like OTR: https://en.wikipedia.org/wiki/Off-the-Record_Messaging Actually stops these people though, and is even labelled in some of the Snowden Files as being "Catastrophic" to their efforts. But you are right, if they can't get chat on you they can just target you inside the Internet and send a malware payload disguised as an update to your browser.
[1] https://riot.im/ [2] https://matrix.org/docs/spec/olm.html
That's (UX) my biggest concern, honestly. UX is just too important, and it's becoming an increasingly fast moving bar. Simple things like hitting up arrow to edit your message, to more complex things like stickers and gifs, these are (unfortunately) requirements for me in my peer circles.
They sound silly, i know, but Telegram has (mostly) a great UX, and for such an important tool i can't currently give up features.. let alone convince my friends to likewise give up features.
(Fwiw, i love Matrix in design)
Granted it depends on how chatty a P2P system is and how much it depends on intermediate nodes for network assist. Ours is pretty idle when nothing is happening, so it doesn't impact battery life or bandwidth quotas very much.
The best design for a P2P network with more involved nodes would probably be to allow nodes to elect their level of availability to perform network assistance roles. Another alternative would be to build a network with two kinds of nodes: 'large' and 'small.' Large nodes could assist small ones.
It's a solvable problem. To some extent "you can't do P2P on mobile" is a dated idea that came from the era when phones were pretty tiny CPU and RAM wise, networks were slower, mobile OSes were more restrictive to background processes, and the battery cost of things like CPU and network I/O was higher. All these things have improved dramatically in recent (past 1-2 years) phone models. The iPhone 7 and the latest Samsung phones have near-desktop-class processors and radios have become more power efficient.
You do have to do a few things differently. One thing we do is to temporally group / quantize background I/O. Instead of sending packets whenever we feel like it, we do it in longer spaced batches when the network is otherwise idle. This saves a lot of battery power by causing the radio to only wake from sleep once for a batch of routine network traffic instead of waking constantly.
So just hand the data right to them?
"I'm more concerned about Facebook/Google/Microsoft/Apple tracking me, reading my private conversations, and selling my data to the highest bidder."
End-to-end encryption is the only solution to that problem. Open source software and decentralization is nice and all but to become a mobile app it'll have to be compiled and run on a closed platform and will almost certainly use APIs of that platform.
Presently, mobile devices aren't (effective) general purpose computers. That must change.
That's not necessarily true. End to end encryption doesn't need to be a compiled mobile app or send messages over a closed platform.
We built a decentralized, open source, freely distributable, browser-based Twitter client utilizing end-to-end encryption at www.seecret.io specifically to address that.
I don't want something that is perfectly secure, I want something I can run on servers I control, so that every message I send doesn't go through, and be stored on, servers controlled by the big four.
TOX is a great example, as all the services like this try too hard to be perfectly secure, rather than trying to be user friendly. Most people just want something that lets them easily message their friends, and are willing to sacrifice privacy (quite possibly because they are oblivious to it) to have that.
Even OTR + ICQ/AOL/MSN Messenger were better than what we have now in terms of security and privacy, but people gave those up for simplicity.
Tech that provably prevents one will provably prevent the other.
The Tox protocol is really the core tool. As long as the protocol is well-defined and maintained, I think developers should be free to make whichever clients that they want.
I used tox ages ago, and I used the Blight client or whatever it was called, and I liked it pretty well.
I think a bigger issue is convincing people to use it in small groups. My whole team is just fine using Mattermost/Hipchat/IRC and the majority of them don't see the need for something like this.
His position is that it’s better if everyone gets a little safety, than if a few people get full safety.
It's a solution that probably makes sense if you try to solve the problem from within the gilded cages of Google/Facebook/Apple, but it is a kind of exclusionary thinking that to me goes against the spirit of open standards and user freedom on the internet.
I see this "it's open source, make pull request" type of comment quite a lot but don't understand how you'd know if the person you're saying it to could do it. If not, it's kind of a dick move, isn't it?
Edit: here's a possibly better response than the "do it yourself" response:
XXX is a free and open source project. That means the developers put in the majority of their time on the issues that they want and enjoy coding the most, even if other good features are left out. If you're unable to help out with coding yourself, you could look through the open and closed issues and see of others have thought about your feature request too. If an open issue exists, a short "while I don't have the ability to code this, I'd like this feature too," added to the list would let the developers gauge interest and may sway someone into giving it a try. Thanks.
Edit 2: It's a bit long. This sentiment but shorter.
Okay, what about money? They also take donations.
> I see this "it's open source, make pull request" type of comment quite a lot but don't understand how you'd know if the person you're saying it to could do it. If not, it's kind of a dick move, isn't it?
No. Trying to make people feel bad for not wanting to work for free, is what I call a dick move.
GrayHatter has implemented a prototype and will deliver a design document for the full implementation likely by the end of Q4. It includes profile and contact sync as well as message history sync. If we follow the intended timeline, that feature would likely land somewhere in 2017Q1. uTox and qTox have preliminary support for the prototype.
You and everybody else are invited to review the proposal when it comes out. Be sure to follow the issues on https://github.com/TokTok/c-toxcore/issues. You are also invited to join #toktok on Freenode to bounce ideas around.
Offline messaging will be partially solved by message log sync, as mentioned in milestone 4. The idea is that if you have a desktop computer at home, you could sync the message from your phone to it, and the desktop computer will deliver the message to your friend when they come online. It could be that your desktop syncs with their desktop at some point, and later their desktop syncs with their phone which is the actual delivery. In any case, this solution requires at least one of your and their devices to be online at one point. So far, we have shied away from storing large amounts of data in the network itself. I think the described solutions are sufficient for a large group of users. Federated (email-like) server-based (still distributed, just not p2p) solutions could be used for the remainder.