irungentoo / toxcore Goto Github PK

Whenever I run nTox it kinda works but than i get a "Segmentation fault" error.

Why not just change the project name to Tox?

We need to figure out what compression format to use. Theora seems like a good bet, since it has no huge patent issues. We could also possibly use WebM.

For audio, Ogg Vorbis is a pretty obvious choice. I think that getting audio support done first makes the most sense. We could use a 64-bitrate and it would sound okay. However, Vorbis is variable-bitrate, which could cause some problems with transmission.

https://github.com/Genshin/PhantomOpenEmoji

An Emoji system like in iOS would be an easy way to gain professionalism points in the eyes of normies.

I'd personally like it to work the same way, where text stays text and the little graphics are extra things you can choose to use.

The IRC link in the readme is incorrect.

I absolutely love the concept of this project but it would be great if I could point people I know to binaries that they could just drop onto their PC and run.

Linking the Download button from your website to this Github repository is not ideal for the majority of users.

Great project though!

While the project is still in early development, I think it would be a good habit to not have any unconditional prints in the library code. At least not without a DEBUG flag of some sort.

Some of us testers (or the just curious people) would require to dig through the whole core looking for these prints if we wanted sensible output while testing.

Hello everybody,
I commented about Your project on this hackernews post.

Here are some of the papers I mentioned. The Stealth-Dht for better performance, reliability and churn resistance. The Sybil-Attack and a survey of preventions.
For your username lookup there is a dht based dns system that basically does what you need (just use the dht as the lookup directory itself).

This line in DHT_hardening.txt:

Each client_id is the public key of the peer so it would be trivial to encrypt
the DHT requests with crypto_box(). This would completely defeat the first
attack.

is only true if you use a centralized loockup/registry service for client id's or require the user to type in the id of the friend he wants to add. See the ecplise attack paper for clarification about another related problem.

If you have some time this is an excellent and detailed survey about some DHT attacks and proposed countermeasures.

The Skype Paper is also quite interesting but note that this paper is old and as far as I know MS uses their own servers instead of the DHT by now.

Greetings,
Zaphot

I'm most definitely not a crypto expert, but after reading the Crypto.md overview, I noticed a possible problem:

There is no MAC code anywhere in the "add friend" message.

This means that an attacker can intercept the friend request packets and modify them by replacing Alice's public key with his own.

I also did a quick review of the code and there does not seem to be any MACing happening there either.

I'm sorry if this is irrelevant, but I couldn't resist in case this was an actual issue as this could result in a major breach of security.

White trying to write an Obj-C wrapper for this (for ease of porting to iOS and OSX), I ran into some issues. Mainly the fact that, by default, the messenger core uses global arrays.

In my mind, a good version of the messenger would be completely independent of the friendlist implementation, and would only deal with client IDs as a result. This would make writing wrappers in other languages easier, in turn making the project more usable.

Of course, this is a major change that is not strictly necessary, so it's very open to debate.

Does anybody agree?

How to fix this?

There are a couple of warnings during compilation, which probably should be addressed. Especially the ones concerning the comparison of signed and unsigned integers might potentially be problematic when it comes to security.

I'm attaching the lines of the output of the compilation, which I think you should take another look at.

gcc -c -pipe -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -Wall -W -D_REENTRANT -fPIE -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/lib/qt/mkspecs/linux-g++ -I../projectfiles/QtCreator -I../src -I../submodules/ProjectTox-Core/core -I/usr/include/qt -I/usr/include/qt/QtWidgets -I/usr/include/qt/QtGui -I/usr/include/qt/QtCore -I. -I. -o DHT.o ../submodules/ProjectTox-Core/core/DHT.c
../submodules/ProjectTox-Core/core/DHT.c: In function ‘sendnodes’:
../submodules/ProjectTox-Core/core/DHT.c:494:12: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if(len != sizeof(ping_id) + num_nodes * sizeof(Node_format) + ENCRYPTION_PADDING)
^
../submodules/ProjectTox-Core/core/DHT.c: In function ‘handle_sendnodes’:
../submodules/ProjectTox-Core/core/DHT.c:600:12: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if(len != sizeof(ping_id) + num_nodes * sizeof(Node_format))
^
../submodules/ProjectTox-Core/core/DHT.c: In function ‘DHT_getfriendip’:
../submodules/ProjectTox-Core/core/DHT.c:664:5: warning: missing initializer for field ‘padding’ of ‘IP_Port’ [-Wmissing-field-initializers]
IP_Port empty = {{{0}}, 0};
^
In file included from ../submodules/ProjectTox-Core/core/Lossless_UDP.h:27:0,
from ../submodules/ProjectTox-Core/core/net_crypto.h:27,
from ../submodules/ProjectTox-Core/core/DHT.h:27,
from ../submodules/ProjectTox-Core/core/DHT.c:24:
../submodules/ProjectTox-Core/core/network.h:82:14: note: ‘padding’ declared here
uint16_t padding;
^
../submodules/ProjectTox-Core/core/DHT.c: In function ‘route_tofriend’:
../submodules/ProjectTox-Core/core/DHT.c:811:91: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if(sendpacket(friends_list[i].client_list[j].ip_port, packet, length) == length)
^
../submodules/ProjectTox-Core/core/DHT.c: In function ‘routeone_tofriend’:
../submodules/ProjectTox-Core/core/DHT.c:839:56: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if(sendpacket(ip_list[rand() % n], packet, length) == length)
^
../submodules/ProjectTox-Core/core/DHT.c: In function ‘handle_NATping’:
../submodules/ProjectTox-Core/core/DHT.c:916:54: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
else if(route_packet(packet + 1, packet, length) == length)
^
../submodules/ProjectTox-Core/core/DHT.c:885:63: warning: unused parameter ‘source’ [-Wunused-parameter]
int handle_NATping(uint8_t * packet, uint32_t length, IP_Port source)
^
../submodules/ProjectTox-Core/core/DHT.c: In function ‘punch_holes’:
../submodules/ProjectTox-Core/core/DHT.c:970:9: warning: missing initializer for field ‘padding’ of ‘IP_Port’ [-Wmissing-field-initializers]
IP_Port pinging = {ip, htons(port)};
^
In file included from ../submodules/ProjectTox-Core/core/Lossless_UDP.h:27:0,
from ../submodules/ProjectTox-Core/core/net_crypto.h:27,
from ../submodules/ProjectTox-Core/core/DHT.h:27,
from ../submodules/ProjectTox-Core/core/DHT.c:24:
../submodules/ProjectTox-Core/core/network.h:82:14: note: ‘padding’ declared here
uint16_t padding;
^
gcc -c -pipe -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -Wall -W -D_REENTRANT -fPIE -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/lib/qt/mkspecs/linux-g++ -I../projectfiles/QtCreator -I../src -I../submodules/ProjectTox-Core/core -I/usr/include/qt -I/usr/include/qt/QtWidgets -I/usr/include/qt/QtGui -I/usr/include/qt/QtCore -I. -I. -o Lossless_UDP.o ../submodules/ProjectTox-Core/core/Lossless_UDP.c
../submodules/ProjectTox-Core/core/Lossless_UDP.c: In function ‘connection_ip’:
../submodules/ProjectTox-Core/core/Lossless_UDP.c:259:5: warning: missing initializer for field ‘padding’ of ‘IP_Port’ [-Wmissing-field-initializers]
IP_Port zero = {{{0}}, 0};
^
In file included from ../submodules/ProjectTox-Core/core/Lossless_UDP.h:27:0,
from ../submodules/ProjectTox-Core/core/Lossless_UDP.c:26:
../submodules/ProjectTox-Core/core/network.h:82:14: note: ‘padding’ declared here
uint16_t padding;
^
../submodules/ProjectTox-Core/core/Lossless_UDP.c: In function ‘handle_SYNC2’:
../submodules/ProjectTox-Core/core/Lossless_UDP.c:483:88: warning: unused parameter ‘sent_packetnum’ [-Wunused-parameter]
int handle_SYNC2(int connection_id, uint8_t counter, uint32_t recv_packetnum, uint32_t sent_packetnum)
^
gcc -c -pipe -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -Wall -W -D_REENTRANT -fPIE -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/lib/qt/mkspecs/linux-g++ -I../projectfiles/QtCreator -I../src -I../submodules/ProjectTox-Core/core -I/usr/include/qt -I/usr/include/qt/QtWidgets -I/usr/include/qt/QtGui -I/usr/include/qt/QtCore -I. -I. -o Messenger.o ../submodules/ProjectTox-Core/core/Messenger.c
../submodules/ProjectTox-Core/core/Messenger.c: In function ‘getclient_id’:
../submodules/ProjectTox-Core/core/Messenger.c:80:19: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if (friend_id >= numfriends || friend_id < 0)
^
../submodules/ProjectTox-Core/core/Messenger.c: In function ‘m_delfriend’:
../submodules/ProjectTox-Core/core/Messenger.c:152:22: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if (friendnumber >= numfriends || friendnumber < 0)
^
../submodules/ProjectTox-Core/core/Messenger.c: In function ‘setfriendname’:
../submodules/ProjectTox-Core/core/Messenger.c:213:22: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if (friendnumber >= numfriends || friendnumber < 0)
^
../submodules/ProjectTox-Core/core/Messenger.c: In function ‘getname’:
../submodules/ProjectTox-Core/core/Messenger.c:244:22: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if (friendnumber >= numfriends || friendnumber < 0)
^
../submodules/ProjectTox-Core/core/Messenger.c: In function ‘m_get_userstatus_size’:
../submodules/ProjectTox-Core/core/Messenger.c:270:22: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if (friendnumber >= numfriends || friendnumber < 0)
^
../submodules/ProjectTox-Core/core/Messenger.c: In function ‘m_copy_userstatus’:
../submodules/ProjectTox-Core/core/Messenger.c:279:22: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if (friendnumber >= numfriends || friendnumber < 0)
^
../submodules/ProjectTox-Core/core/Messenger.c: In function ‘set_friend_userstatus’:
../submodules/ProjectTox-Core/core/Messenger.c:298:22: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if (friendnumber >= numfriends || friendnumber < 0)
^
../submodules/ProjectTox-Core/core/Messenger.c: In function ‘doFriends’:
../submodules/ProjectTox-Core/core/Messenger.c:375:58: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if (friendlist[i].friend_request_id + 10 < unix_time()) { /I know this is hackish but it should work./
^
../submodules/ProjectTox-Core/core/Messenger.c: In function ‘Messenger_load’:
../submodules/ProjectTox-Core/core/Messenger.c:538:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if (length == ~0)
^

gcc -c -pipe -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -Wall -W -D_REENTRANT -fPIE -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/lib/qt/mkspecs/linux-g++ -I../projectfiles/QtCreator -I../src -I../submodules/ProjectTox-Core/core -I/usr/include/qt -I/usr/include/qt/QtWidgets -I/usr/include/qt/QtGui -I/usr/include/qt/QtCore -I. -I. -o network.o ../submodules/ProjectTox-Core/core/network.c
../submodules/ProjectTox-Core/core/network.c: In function ‘sendpacket’:
../submodules/ProjectTox-Core/core/network.c:66:5: warning: missing initializer for field ‘zeroes’ of ‘ADDR’ [-Wmissing-field-initializers]
ADDR addr = {AF_INET, ip_port.port, ip_port.ip};
^
In file included from ../submodules/ProjectTox-Core/core/network.c:24:0:
../submodules/ProjectTox-Core/core/network.h:89:13: note: ‘zeroes’ declared here
uint8_t zeroes[8];
^
../submodules/ProjectTox-Core/core/network.c: In function ‘init_networking’:
../submodules/ProjectTox-Core/core/network.c:148:5: warning: missing initializer for field ‘zeroes’ of ‘ADDR’ [-Wmissing-field-initializers]
ADDR addr = {AF_INET, htons(port), ip};
^
In file included from ../submodules/ProjectTox-Core/core/network.c:24:0:
../submodules/ProjectTox-Core/core/network.h:89:13: note: ‘zeroes’ declared here
uint8_t zeroes[8];
^
gcc -c -pipe -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -Wall -W -D_REENTRANT -fPIE -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/lib/qt/mkspecs/linux-g++ -I../projectfiles/QtCreator -I../src -I../submodules/ProjectTox-Core/core -I/usr/include/qt -I/usr/include/qt/QtWidgets -I/usr/include/qt/QtGui -I/usr/include/qt/QtCore -I. -I. -o friend_requests.o ../submodules/ProjectTox-Core/core/friend_requests.c
../submodules/ProjectTox-Core/core/friend_requests.c: In function ‘friendreq_handlepacket’:
../submodules/ProjectTox-Core/core/friend_requests.c:126:57: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if(route_packet(packet + 1, packet, length) == length)
^
../submodules/ProjectTox-Core/core/friend_requests.c:104:71: warning: unused parameter ‘source’ [-Wunused-parameter]
int friendreq_handlepacket(uint8_t * packet, uint32_t length, IP_Port source)
^
gcc -c -pipe -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -Wall -W -D_REENTRANT -fPIE -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/lib/qt/mkspecs/linux-g++ -I../projectfiles/QtCreator -I../src -I../submodules/ProjectTox-Core/core -I/usr/include/qt -I/usr/include/qt/QtWidgets -I/usr/include/qt/QtGui -I/usr/include/qt/QtCore -I. -I. -o LAN_discovery.o ../submodules/ProjectTox-Core/core/LAN_discovery.c
../submodules/ProjectTox-Core/core/LAN_discovery.c: In function ‘send_LANdiscovery’:
../submodules/ProjectTox-Core/core/LAN_discovery.c:69:5: warning: missing initializer for field ‘padding’ of ‘IP_Port’ [-Wmissing-field-initializers]
IP_Port ip_port = {broadcast_ip(), port};
^
In file included from ../submodules/ProjectTox-Core/core/Lossless_UDP.h:27:0,
from ../submodules/ProjectTox-Core/core/net_crypto.h:27,
from ../submodules/ProjectTox-Core/core/DHT.h:27,
from ../submodules/ProjectTox-Core/core/LAN_discovery.h:29,
from ../submodules/ProjectTox-Core/core/LAN_discovery.c:24:
../submodules/ProjectTox-Core/core/network.h:82:14: note: ‘padding’ declared here
uint16_t padding;
^

I was reading the source code, and the documentation is all over the place. Would it hurt if the documentation and the comments were done in a JavaDoc-style right from the beginning so that the whole thing could be just easily generated using the Doxygen tools? It would ease up maintaining the code and the documentation considerably.

http://www.stack.nl/~dimitri/doxygen/

Examples here:

http://www.stack.nl/~dimitri/doxygen/manual/docblocks.html

Is there a way of doing a decentralized friends list? I keep thinking of creating three hashes, private hash, public hash, and second public hash. I am going to refer to both the first and second public hashes as just first and second hashes. First hash is used as an identifier, anyone can know it. Second hash can be thought of as a secret public key (kind of paradox there) and/or as a shared secret. Only friends can know both. First hash gets sent to the DHT network, asking if anyone knows the identifier. People respond with an encrypted message (that contains their first and second hashes, and other relevant info) that can only be encrypted with the second hash.

If someone responds with an encrypted message that can not be decrypted with their private key then they are ignored.

So, private key, public identifier, and secret public key. Identifier is used to find people who know the key or be found yourself. Secret public key is only given to friends. It is more or less used for when someone is trying to rebuild their friends list and as their actual public key. If a person already has you in your friends list, they automatically send a message off that is encrypted using your secret public key, which when decrypted is verification that they actually know you already.

I think this would work but I am not sure if there is are flaws in it. I can't think of anything better that is not only decentralized but is also not prone to abuse.

Does everyone agree?

1. Can we please get a BSD/MIT License for it.
2. An API that could talk to Tox would be nice.
3. Please replace the mock up on the webpage with an actual screenshot

Hi guys,

I left a comment on #58, but it seems like that discussion is basically a licensing flamewar. And it's hard to have a reasonable licensing discussion if there is no clear plan for how to distribute the software to begin with.

Really what I'd like to know is what the plan is to roll this thing out.

1. To get widespread adoption (and it really isn't clear to me if that's a goal), you're going to need to write UIs for maybe a dozen windowing systems / platforms. Windows has a thing, OSX has AppKit, Linux has GTK, Qt, etc., iOS has UIKit, Android has a thing, etc. Where does this code go? Does it get checked into ProjectTox-Core? Does somebody set up a dozen little repos that consume ProjectTox-Core as a library? What is the vision here?
2. Who do you envision maintaining these ports? Do the current contributors to core have enough time and energy to maintain ports? Is there a search ongoing for a maintainer for one or more platforms?
3. Is the goal here to have a single, unified Tox experience on all the platforms, or is the goal more to create an ecosystem of "Tox-compatible" software? If it's the former, is there a search ongoing to find someone who is willing to form a legal/taxable entity to formally distribute the software through the official platform channels?

My very sincere concern is that the technical work can progress because that is easier than achieving consensus on these questions, but that strategy only delays the problem. And it gets harder to solve as time goes on and more contributors become invested, with potentially conflicting goals. So to avoid becoming yet another failed encryption project, it is super critical to get stuff like this decided and to start already carrying it out.

There doesn't seem to be a policy on how the package should be (ideally) named, and given that there exists plenty of software called "tox" the package can't be called like that.

On a side note, #tox on freenode is completely empty.

Shor's Algorithm is a quantum algorithm for factorizing prime numbers, as such it easily breaks most forms of modern encryption, which is a serious threat to the principles behind TOX.

NTRU is an encryption scheme not vulnerable to Shor's Algorithm, a C implementation of NTRU is available at https://github.com/tbuktu/libntru under a permissive license, and should be integrated(perhaps optionally).

Currently, Tox uses handwritten and ad-hoc serialization and deserialization code on the network. In addition to possibly leading to security vulnerabilities (hand-writing parsers in C is prone to security errors), this makes it hard to extend the protocol in the future or to write implementations in another language.
With something like protocol buffers, we can write a protocol specification (in e.g. the protobuf interface descriptor language) and automatically create all of the network-parsing code from there (reducing the amount of critical hand-written code that could have security vulns).
If the protocol extends in the future, protobuf guarantees some level of backwards compatibility (i.e. the new message would be discarded if it is 'optional').
Furthermore, if someone else wants to implement the ProjectTox core in another library or language, that implementation would not have to reimplement the network parser, guaranteeing that different implementations will be compatible).

For background on why hand written parsers are bad, see this awesome talk: http://prezi.com/rhlij_momvrx/langsec-2011-2016/

While I am in way an expert in cryptography the code for "random_int" appears to be designed to be cryptographically secure only on windows. Specifically on windows you use libsodium's randombytes_random(), a function that draws it random numbers from

/dev/urandom or /dev/random on *nix and the cryptographic service provider on Windows

(all of which are at least decent for cryptography as I understand it) according to https://github.com/jedisct1/libsodium/blob/master/README.markdown . Despite this function being programmed for *nix as well as windows, on non-WIN32 os's you use random() seeded with the system time during the last run of init_networking. This is, unlike randombytes_random(), just a simple pseudo random number generator that is not even intended to be cryptographically secure (for a description of the algorithm random() uses see: http://www.mathstat.dal.ca/~selinger/random/ ) .

Also in examining this I noticed that on non-win32 systems you set the seed with both srand and srandom in init_networking. The linux C library runs both rand and random off of the same random number generator so this results in only the latter call (srand currently) actually doing anything on linux.

Would be good to get this audited by an external person/group/company so the public can have a bit more faith in the security of the application, especially after the recent Cryptocat failures stemming from the developers having a lack of understanding of cryptographic principles.

The threads on /g/ seemed to agree that SQL would be a good choice for friends storage. I would personally pick SQLite for ease of licensing, and because it's really the best tool for this job.

The database structure would be fairly simple. It would only have to contain a public key, a nickname (assigned by the user), possibly a domain (if, as some people suggested, we are going to allow people to create registrars for TOX usernames), and maybe a picture and a status.

Advantages of this:

• Database and be queried by other applications
• Very Very portable
• Flexible to changes

Disadvantages:

• Might be slightly less secure
• Requires some work to implement
• Will be marginally slower

This is up for debate, but I think it's a good way to move forward.

Are there any useful things we could do/borrow with/from Web RTC, or has development gone too far for Web API to be useful at this point?

https://www.youtube.com/watch?v=p2HzZkd2A40
http://www.webrtc.org/

While usually this might go in multiple issues I thought that, since it's a single thread on reddit, it'd probably be best to keep it all in a single thread here as well.

Here's the link: http://redd.it/1jcn6r

Be a dear to your fellow debater and quote and link what comment you are talking about!

In order to look more professional, and at least help people find us better, I suggest either making a new GitHub account or renaming irungentoo's account to something like Tox.

I wonder why you folks try to reinvent the wheel when it comes to symmetric, serverless NAT traversal? Why not use pwnat which is simpler than the existing proposal and an implementation is readily available?

http://samy.pl/pwnat/

https://github.com/samyk/pwnat

Starting the test-client results in 100% CPU usage.

strace:

recvfrom(4, 0x7fff16250df0, 65507, 0, 0x7fff16250da0, 0x7fff16250d9c) = -1 EAGAIN (Resource temporarily unavailable)
rt_sigaction(SIGTSTP, {SIG_IGN, [], SA_RESTORER|SA_RESTART, 0x7f0233108450}, {0x7f02336cacb0, [], SA_RESTORER|SA_RESTART, 0x7f0233108450}, 8) = 0
select(1, [0], NULL, NULL, {0, 0})      = 0 (Timeout)
select(1, [0], NULL, NULL, {0, 0})      = 0 (Timeout)
rt_sigaction(SIGTSTP, {0x7f02336cacb0, [], SA_RESTORER|SA_RESTART, 0x7f0233108450}, NULL, 8) = 0
select(1, [0], NULL, NULL, {0, 0})      = 0 (Timeout)

this repeats all the time.

It would be nice if there were a language-independent API between ProjectTox-Core and applications on top of it, and a concise statement as to what the core handles and what it does not. Ideally, the core would expose nothing but an interface to establish different types of connections (unreliable, reliable) with different types (should be an arbitrary tag, like 'chat', 'video' , 'remote desktop') between and relay presence information about DHT nodes identified by their public key. Just like sodium provides us with a very small and simple crypto_box api, core should just provide a simple API, e.g. (rough draft, should probably change)

joinDHT(bootstrap-node)
isPresent(clientID) - true if node is known in the DHT, false otherwise
openChannel(clientID, reliable, type) - establish a 'connection' in core
sendMessage(channel,Message) - send message to connection
closeChannel(channel) - abandon a connection

while a 'connection' is established, the core will perform and maintain UDP hole punching, mask IP changes, etc.

This API could either be provided as a C-interface, or possibly via some sort of remoting interface (i.e. protobuf-rpc on stdin/stdout), so that the core can be properly sandboxed (being the only component dealing with priveleged information) or implemented in a safer language (rust, go or haskell).

May be it would be reasonable to add at some point mechanics to use friend's instances as proxies for cases of very prohibitive NAT? If this will be configurable (on/off + bandwidth, perhaps?) I think users will accept.

https://gist.github.com/devinsba/6113964

This feature allows people to create and run custom scripts along with allowing developers to create their own UI instead of being stuck with the default one. Also, people without a GUI will still be able to use the program; maybe not for video chat but maybe for the IM. This will appeal to more people, specially the GNU/Linux users. The main package should ship with the default GUI for normal users but let people have the ability to remove or just not use the default GUI. Just take a look at GitHub; since they have a CLI back-end people can make their own GUI and accomplish their goals.

Not to be too pedantic immediately, but less than 10 hours in and there's already an editor war starting.

Commit 1f5fba0 erased b24bb23's EOF newline, leading me to question whether or not @irungentoo actually runs gentoo.

What's a good set of guidelines for cross-platform C projects?

After brief googling, I found http://www.jetcafe.org/jim/c-style.html, which says nothing about trailing newlines. Still, without them, dealing with files on Linux is pretty unpleasant, and most tools will attempt to add them back in for you (leading to even more needless hunks)

Here's the original list of sounds asked for:

• Log in
• Log out
• Contact comes online
• Contact goes offline
• Incoming call
• Outgoing call
• Incoming video call
• Outgoing video call
• New message received
• Contact accepts add invitation
• Pending file transfer
• File transfer complete

Proposed possible sounds needed:

• Error
• Disconnection
• Message not sent / Failed to send message

Hi,

I'm intereste in this software and willing to package for Fedora.

Can you provide a tag/release from now on?

Thanks.

I think witheld said it won't be too difficult.

There aren't many good simple holepunchable VNC solutions that are FOSS. Most just use proprietary solutions.

In tox website, I saw a tox online software with a quite good GUI, but when I finished building the ProjectTox-Core, I just some exe files and I don't know how to use them. Is there any documentation for using this exe files?

Output from debian

Scanning dependencies of target nTox
[ 70%] Building C object testing/CMakeFiles/nTox.dir/nTox.c.o
[ 75%] Building C object testing/CMakeFiles/nTox.dir/misc_tools.c.o
Linking C executable nTox
[ 75%] Built target nTox
Scanning dependencies of target toxic
[ 80%] Building C object testing/CMakeFiles/toxic.dir/toxic/main.c.o
[ 85%] Building C object testing/CMakeFiles/toxic.dir/toxic/prompt.c.o
Linking C executable toxic
/usr/bin/ld: cannot open output file toxic: Is a directory
collect2: error: ld returned 1 exit status
make[2]: *** [testing/toxic] Error 1
make[1]: *** [testing/CMakeFiles/toxic.dir/all] Error 2
make: *** [all] Error 2

Solution:

1. change folder name ( testing/toxic )
2. change exe_name in testing/toxic/CMakeLists.txt to something other then toxic
3. maybe something even better?

This thread will have updates regarding graphic design work for future use:

First question: are we using NaCl or libsodium?

Website updates will be posted here.

I'm sure this is awaiting inclusion, but I thought it weird that it had mac os x build instructions with ./configure with no file named 'configure'.

Thanks for doing this. I hope to contribute once I can get it built.

What color scheme you guys like the most ? I have some ideas for the program icon, even if the name is going to change I don't care, I got a plenty of free time.

There has been a similar project that has gotten attention, but has not been developed yet:
http://www.gullicksonlaboratories.com/bitphone-executive-overview/

Quick description like "Encrypted, P2P messaging library and client"

A segfault can be triggered when you add someone, do not sucesfully connect to them, add another person, and do sucessfuly connect to them using nTox

Whoever has created the concept GUI, could you upload the art assets and document the properties.

I had a friend with an id of 0. I can message him at 4294967296 and it sends it to him even though he is 0.

Also, sometimes people get added as a negative integer like -1 and then you can't message them at all.