dd8a568141
**What are we doing?** We are moving towards stateless callbacks. This means that when registering a callback, you no longer pass a user data pointer. Instead, you pass a user data pointer to tox_iterate. This pointer is threaded through the code, passed to each callback. The callback can modify the data pointed at. An extra indirection will be needed if the pointer itself can change. **Why?** Currently, callbacks are registered with a user data pointer. This means the library has N pointers for N different callbacks. These pointers need to be managed by the client code. Managing the lifetime of the pointee can be difficult. In C++, it takes special effort to ensure that the lifetime of user data extends at least beyond the lifetime of the Tox instance. For other languages, the situation is much worse. Java and other garbage collected languages may move objects in memory, so the pointers are not stable. Tox4j goes through a lot of effort to make the Java/Scala user experience a pleasant one by keeping a global array of Tox+userdata on the C++ side, and communicating via protobufs. A Haskell FFI would have to do similarly complex tricks. Stateless callbacks ensure that a user data pointer only needs to live during a single function call. This means that the user code (or language runtime) can move the data around at will, as long as it sets the new location in the callback. **How?** We are doing this change one callback at a time. After each callback, we ensure that everything still works as expected. This means the toxcore change will require 15 Pull Requests. |
||
|---|---|---|
| auto_tests | ||
| build | ||
| dist-build | ||
| docs | ||
| m4 | ||
| other | ||
| super_donators | ||
| testing | ||
| toxav | ||
| toxcore | ||
| toxdns | ||
| toxencryptsave | ||
| .gitignore | ||
| .travis.yml | ||
| autogen.sh | ||
| CMakeLists.txt | ||
| configure.ac | ||
| COPYING | ||
| DONATORS | ||
| INSTALL.md | ||
| libtoxav.pc.in | ||
| libtoxcore.pc.in | ||
| Makefile.am | ||
| README.md | ||
| tox.spec.in | ||
Current build status: 
Current Coverage: 
Website | Wiki | Blog | FAQ | Binaries/Downloads | Clients | Compiling
IRC Channels: #tox@freenode, #toktok@freenode
Q&A:
What is Tox?
Tox is a fully encrypted, censor resistant, private, distributed network library with a focus on personal communications.
No, really, what's Tox?
It's a VERY secure Instant Messenger that supports Text, Audio/Video calls, group chats, audio group chats, and file transfers.
What are your goals with Tox?
We want Tox to be as simple as possible while remaining as secure as possible.
Toxcore Roadmap
This Roadmap is somewhat tentative, but should give you a good idea of where we're going, and where we've been.
Currently unsorted, the following is intended to function as a discussion guide to developers/contributors.
In Progress
- 100% unit testing
- Make toxcore stateless
- Allow a single toxcore instance to handle multiple keypairs
- Implement usable group chats
- Improve A/V implementation
- Multiple device support
- Consistent naming scheme throughout toxcore
Done
- Create Toxcore
- Create DHT
- Create Onion
- Implement Crypto
- Create Messenger
Documentation:
The Complex Stuff:
UDP vs. TCP
Tox must use UDP simply because hole punching with TCP is not as reliable. However, Tox does use TCP relays as a fallback if it encounters a firewall that prevents UDP hole punching.
Connecting & Communicating
Every peer is represented as a byte string (the public key [Tox ID] of the peer). By using torrent-style DHT, peers can find the IP of other peers by using their Tox ID. Once the IP is obtained, peers can initiate a secure connection with each other. Once the connection is made, peers can exchange messages, send files, start video chats, etc. using encrypted communications.