summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat
-rw-r--r--docs/Crypto.txt58
-rw-r--r--docs/DHT.txt86
-rw-r--r--docs/DHT_hardening.txt70
-rw-r--r--docs/FAQ.txt83
-rw-r--r--docs/IDEAS.txt27
-rw-r--r--docs/Lossless_UDP.txt102
-rw-r--r--docs/Messenger_Protocol.txt33
-rw-r--r--docs/Routing.txt66
-rw-r--r--docs/TODO.txt51
9 files changed, 0 insertions, 576 deletions
diff --git a/docs/Crypto.txt b/docs/Crypto.txt
deleted file mode 100644
index d53c16a8..00000000
--- a/docs/Crypto.txt
+++ /dev/null
@@ -1,58 +0,0 @@
1Draft proposal for how crypto will be implemented.
2
3
4Encryption library used: http://nacl.cr.yp.to/
5
6
7When running the program for the first time the crypto_box_keypair() function is used to
8generate the users public-private key pair. (32 bytes each)
9
10The generated public key is set as the client_id of the peer.
11
12Adding a friend:
13 Alice adds bob to her friends list by adding his 32 byte public key (client_id) to her friends list.
14 2 cases:
15 case 1: Alice adds Bobs public key and bob waits for Alice to attempt to connect to him.
16 case 2: Bob and Alice add their respective public keys to their friends list at the same time.
17
18 case 1:
19 Alice connects to Bob and sends a data packet (friends request) like so:
20 [char with a value of 01][Alice's Public key (client_id) (32 bytes)][Random nonce (24 bytes)][Encrypted message]
21
22 Where the encrypted message is encrypted with crypto_box() (using Bobs public key, Alice's private key
23 and the nonce (randomly generated 24 bytes)) and is a message from Alice in which she tells Bob who she is.
24 Ex: hello bob it's me alice -_- add me pl0x.
25
26 Bob receives the request and decrypts the message using the function crypto_box_open()
27
28 If the message decrypts successfully:
29 If Alice is already in Bobs friends list: case 2
30 If Alice is not in Bob's friends list: Bob is prompt to add Alice and is shown the message from her.
31 If Bobs accepts Alice's friends request he adds her public key to his friends list.
32
33 case 2:
34 Bob and Alice both have the others public key in their friends list, they are ready for the next step: Connecting to an already added friend
35
36
37In the next step.
38only crypto_box() is used for encryption and only crypto_box_open() for decryption (just like in the last step.)
39
40
41Connecting to an already added friend:
42 Alice and Bob are friends.
43 As soon as they connect they each generate a new keypair which will only be used for the current connection (The session keys).
44 They then send themselves the following packet (the crypto handshake) (encrypted part encrypted with the public nonce in the packet
45 the public key of the receiver and private key of the sender)
46 [char with a value of 02][Senders Public key (client_id) (32 bytes)][Random nonce (24 bytes)][Encrypted message containing: [random 24 bytes base nonce][session public key of the peer (32 bytes)]]
47
48 If the packet is decrypted successfully:
49 Each start using the secret nonce, the public key provided by the other and their own session private key to encrypt data packets (adding to it + 1 for each packet.)
50 Each node sends themselves an empty data packet (data packet with 4 encrypted zero bytes)
51 Data packet:
52 [char with a value of 03][Encrypted data]
53 Each data packet received it is decrypted using the secret nonce sent to the other(with +1 added for the first packet +2 for the second, etc...)
54 along with the private session key of the receiver.
55 Every data packet sent is encrypted using the secret nonce we received (with +1 added for the first packet +2 for the second, etc...),
56 the session public key of the receiver and the session private key of the sender.
57
58 The encrypted connection is only deemed successful when the empty data packet is received and decrypted successfully.
diff --git a/docs/DHT.txt b/docs/DHT.txt
deleted file mode 100644
index 088f34ee..00000000
--- a/docs/DHT.txt
+++ /dev/null
@@ -1,86 +0,0 @@
1DHT protocol:
2 Follows pretty much the principle of the torrent DHT: http://www.bittorrent.org/beps/bep_0005.html (READ IT)
3
4 But:
5 Vastly simplified packet format and encryption.
6
7 Boostrapping:
8 The first time you install the client we bootstrap it with a node on our servers.(bandwidth should not be a problem as the client only needs to be sent one reply.)
9
10
11 Basics (All the numbers here are just guesses and are probably not optimal values):
12
13 client list: A list of node ids closest (mathematically see bittorrent doc) to ours matched with ip addresses + port number corresponding to that id and a timestamp containing the time or time since the client was successfully pinged.
14
15 "friends" list: A list containing the node_ids of all our "friends" or clients we want to connect to.
16 Also contains the ip addresses + port + node_ids + timestamp(of last ping like in the client list) of the 8 clients closest (mathematically see bittorrent doc) to each "friend"
17
18 Two pinged lists:
19 -One for storing a list of ips along with their ping_ids and a timestamp for the ping requests
20 -One for storing a list of ips along with their ping_ids and a timestamp for the get nodes requests
21 Entries in the pinged lists expire after 5 seconds.
22 If one of the lists becomes full, the expire rate reduces itself one second or the new ping takes the place of the oldest one.
23
24
25 Entries in client list and "friends" list expire after 300 seconds without ping response.
26 Each client stores a maximum of 32 entries in its client list.
27 Each client in the client list and "friends" list is pinged every 60 seconds.
28 Each client in the client list and "friends" list has a timestamp which denote the last time it was successfully pinged.
29 If the corresponding clients timestamp is more than 130 seconds old it is considered bad.
30 Send a get nodes request every 20 seconds to a random good node for each "friend" in our "friends" list.
31 Send a get nodes request every 20 seconds to a random good node in the client list.
32
33
34 When a client receives any request from another:
35 -Respond to the request
36 -Ping request is replied to with with a ping response containing the same ping_id
37 -Get nodes request is replied with a send nodes reply containing the same ping_id and the good nodes from the client list and/or the "friends" list that are closest to the requested_node_id
38
39 -If the requesting client is not in the client list:
40 -If there are no bad clients in the list and the list is full:
41 -If the id of the other client is closer (mathematically see bittorrent doc) than at least one of the clients in the list or our "friends" list:
42 -Send a ping request to the client.
43 -if not forget about the client.
44
45 -If there are bad clients and/or the list isn't full:
46 -Send a ping request to the client
47
48 When a client receives a response:
49 -Ping response
50 -If the node was previously pinged with a matching ping_id (check in the corresponding pinged list.)
51 -If the node is in the client list the matching client's timestamp is set to current time.
52 -If the node is in the "friends" list the matching client's timestamp is set to current time for every occurrence.
53 -If the node is not in the client list:
54 -If the list isn't full, add it to the list.
55 -If the list is full, the furthest away (mathematically see bittorrent doc) bad client is replaced by the new one.
56 -If the list is filled with good nodes replace the furthest client with it only if it is closer than the replaced node.
57 -for each friend in the "friends" list:
58 -If that friend's client list isn't full, add that client to it
59 -If that friend's client list contains bad clients, replace the furthest one with that client.
60 -If that friend's client list contains only good clients
61 -If the client is closer to the friend than one of the other clients, it replaces the farthest one
62 -If not, nothing happens.
63
64 -Send nodes
65 -If the ping_id matches what we sent previously (check in the corresponding pinged list.):
66 -Each node in the response is pinged.
67
68
69
70
71
72 Protocol:
73
74 Node format: [char array (node_id), length=32 bytes][ip (in network byte order), length=4 bytes][port (in network byte order), length=2 bytes][Padding , length=2 bytes]
75
76 Valid queries and Responses:
77
78 Ping(Request and response): [byte with value: 00 for request, 01 for response][char array (client node_id), length=32 bytes][random 24 byte nonce][Encrypted with the nonce and private key of the sender: [random 8 byte (ping_id)]]
79 ping_id = a random integer, the response must contain the exact same number as the request
80
81
82 Get nodes (Request):
83 Packet contents: [byte with value: 02][char array (client node_id), length=32 bytes][random 24 byte nonce][Encrypted with the nonce and private key of the sender:[random 8 byte (ping_id)][char array: requested_node_id (node_id of which we want the ip), length=32 bytes]]
84 Valid replies: a send_nodes packet
85
86 Send_nodes (response): [byte with value: 03][char array (client node_id), length=32 bytes][random 24 byte nonce][Encrypted with the nonce and private key of the sender:[random 8 byte (ping_id)][Nodes in node format, length=40 * (number of nodes (maximum of 8 nodes)) bytes]]
diff --git a/docs/DHT_hardening.txt b/docs/DHT_hardening.txt
deleted file mode 100644
index d6a6bcf2..00000000
--- a/docs/DHT_hardening.txt
+++ /dev/null
@@ -1,70 +0,0 @@
1List of possible attacks on the current DHT:
2
3create thousands of fake nodes cloning one client_id and flood our DHT with
4them.
5
6create thousands of "real" nodes that do nothing but shit up our DHT with fake
7crap.
8
9...
10
11Possible solutions:
12
13Each client_id is the public key of the peer so it would be trivial to encrypt
14the DHT requests with crypto_box(). This would completely defeat the first
15attack.
16
17Make each peer send the information of at least one of his online friends in
18every send nodes response. (Might be bad as any node can now know who our
19friends are)
20
21Limit the maximum number of peers with identical ips that we keep connected to
22in our DHT. (Not a real solution)
23
24Require each node to solve some kind of captcha in order to connect to the
25network. (Bad idea.)
26
27Require nodes to crack hashes or solve other computationally intensive
28problems in order to be accepted in the network. (Kind of like bitcoin)(This is
29probably a bad idea as our application needs to work on phones which are low
30power devices)
31
32Make each node test other nodes to see if they respond correctly before sending
33them as part of their send nodes response.
34...
35
36
37
38=====
39
40
41
42
43<slvr> DHT_hardening.txt > create thousands of "real" nodes that do nothing but
44shit up our DHT with fake crap.
45<slvr> This can be trivially solved by only storing verifiable data in the DHT.
46<slvr> there is one attack you have not considered, which is based on the Sybil
47attack
48<slvr> I am assuming the DHT does say... a hash of a key in order to determine
49which node to store data in, similar to Kad?
50<slvr> If there happens to be a malicious node at that DHT address, they might
51actively deny storing that data.
52<slvr> This can be reduced by storing data at multiple places in the DHT
53(equidistant points in DHT address space)
54<slvr> Since DHT addresses are public keys, it is computationally infeasible for
55an attacker to actively deny all storage locations.
56<slvr> Recommended reading: S/Kademlia: A Practicable Approach Towards Secure
57Key-Based Routing -- http://doc.tm.uka.de/2007/SKademlia_2007.pdf
58<biribiri> Type: application/pdf; Size: 202KiB; Updated: 2033d 19h 32m 5s ago
59(Tue, 18 Dec 2007 13:28:18 GMT);
60<slvr> Tempering Kademlia with a Robust Identity Based System --
61http://www.di.unito.it/~ruffo/concorso/Papers/p2p08.pdf
62<biribiri> Type: application/pdf; Size: 145KiB; Updated: 1291d 23h 30m 12s ago
63(Tue, 29 Dec 2009 09:30:28 GMT);
64<slvr> Also of interest: "An Analysis of BitTorrent's Two Kademlia-Based DHTs"
65--
66http://www.tribler.org/trac/raw-attachment/wiki/AutoUpgradeToLastestVersion/
67Measurement_of_Bittorrent_DHT_performance_and_deployed_clients.pdf
68<biribiri> Type: application/pdf; charset=iso-8859-15; Size: 1.271MiB; Updated:
691669d 20h 25m 15s ago (Tue, 16 Dec 2008 12:44:08 GMT);
70
diff --git a/docs/FAQ.txt b/docs/FAQ.txt
deleted file mode 100644
index 7ecf1471..00000000
--- a/docs/FAQ.txt
+++ /dev/null
@@ -1,83 +0,0 @@
1TOX FAQ
2=======
3
4Contents
5========
6
7(1). What is Tox?
8(2). Where can I get Tox?
9(3). Tox
10(3.1) Which encryption algorithms does Tox employ?
11(3.2) Does Tox have plugin support?
12(3.3) I want to contribute to the Tox project.
13(3.3.1) I want to be a developer.
14(3.3.2) I want to contribute in UI design/sound.
15(3.3.3) Are there any other ways I can contribute?
16(4). Source
17(4.1) Where do I get the Tox source code?
18(4.2) How do I compile Tox?
19
20(5). Community
21(5.1) Where can I find the latest Tox thread?
22(5.2) Are there any other Tox threads/forums?
23===============================================================================
24
25(1). What is Tox?
26=================
27Tox is a free (as in freedom) peer to peer messaging application that aims to
28replace skype.
29
30(2). Where can I get Tox?
31========================
32It's not done yet.
33
34(3). Tox
35=======
36(3.1). Which encryption algorithms does Tox employ?
37--------------------------------------------------
38Tox uses the encryption algorithms present in the NaCl crypto library.
39
40(3.2). Does Tox have plugin support?
41-----------------------------------
42Maybe.
43
44(3.3). I want to contribute to the Tox project.
45==============================================
46(3.3.1). I want to be a developer.
47---------------------------------
48Join the IRC.
49
50(3.3.2). I want to contribute in UI design/sound.
51------------------------------------------------
52Join the IRC.
53
54(3.3.3). Are there any other ways I can contribute?
55--------------------------------------------------
56Testing the application, reporting bugs and requesting features. Don't be
57scared to criticize something if you think it is done wrong.
58
59(4). Source
60===========
61(4.1). Where do I get the Tox source code?
62-----------------------------------------
63The core library: https://github.com/irungentoo/ProjectTox-Core
64Some front ends:
65(None are in a usable state yet.)
66
67(4.2). How do I compile Tox?
68---------------------------
69You need to build and install libsodium.
70Then just cd in the repo and:
71mkdir build
72cd build
73cmake ..
74make
75
76(5). Community
77==============
78(5.1). Where can I find the latest Tox thread?
79---------------------------------------------
80
81
82(5.2). Are there any other Tox threads/forums?
83---------------------------------------------
diff --git a/docs/IDEAS.txt b/docs/IDEAS.txt
deleted file mode 100644
index d1be2ce6..00000000
--- a/docs/IDEAS.txt
+++ /dev/null
@@ -1,27 +0,0 @@
1A couple of ideas posted in the threads.
2
3#############
4 Prescence (online/offline)
5 - A user's id being present with a valid signature in the DHT implies they have been online recently. A ping to the user would confirm this, as well as notifying them that you are online. If both friends in a pair actively search for the other then disruption due to lag in inserting records will be mimimised
6
7 Username (nick) changes
8 - When a user wants to change their nick they are free to do so, the nick is not cryptographically significant. The nick change could be shared in-band with the chat (ie, each message in the format "username - message") or out of band, perhaps in the dht values or in the ping messgaes.
9
10 File send
11 - I see a file being sent as ultimately the same as an audio stream or a video stream being sent, they could use the same protocol parts. The client would handle what to do with the data whether it is a stream of media data or a stream of b64'd file. both would require explicit verification from the other participant. This would also allow sharing of streamed files, eg incomplete downloads.
12
13##############
14
15- ability to log in with username and password
16 possible implementation: store keys in a server and use user/pass to retrieve keys from server transparently
17 >too centralized
18- looking up people and adding as contacts, etc by name or username
19 possible implementation: store pubkey-hash/info correspondences in a public directory, integrate access into client
20- portable contact list/profile/other account data
21 just store it along with keys in aforementioned server; cost of storage could rise... potential problem
22- POSSIBLY interfacing with regular phones. probably not possible, but plebs might complain (THIS IS EXPENSIVE (hence 'probably not possible')) <3
23
24IMPORTANT: release two major sanctioned UIs, one for autists, one with inbuilt support for the previous list so that plebs can't get confused with setting it up and autists don't complain about it getting in their way. de geso
25 > I would suggest a "Advanced options" where the autists can rejoice with all kinds of options (and it doesn't frighten the normalfags, since it's not shown by default). Also, 2 UIs would be chaos to maintain.
26##############
27
diff --git a/docs/Lossless_UDP.txt b/docs/Lossless_UDP.txt
deleted file mode 100644
index 1159feb6..00000000
--- a/docs/Lossless_UDP.txt
+++ /dev/null
@@ -1,102 +0,0 @@
1Lossless UDP:
2 A network protocol over UDP to transfer data without any loss.
3
4 Problems with conventional UDP:
5 -Packet loss.
6 -Packet mixup.
7 -No flow control.
8
9 Draft of Proposed protocol:
10
11 Connexion example:
12
13 Alice wants to connect to Bob (Connection handshake):
14 Alice generates a random 4 byte number.
15 Alice puts it in the handshake packet (handshake_id1).
16 Alice starts sending handshake packets to Bob (send 10 packets over 5 seconds if no response connection fails.)
17 Bob receives the packet.
18 Bob copies the handshake packet he got from alice but concatenates a random 4 byte number to it (handshake_id2)
19 Alice receives the packet, checks if handshake_id1 matches the one she sent.
20 If it does she starts sending SYNC packets with sent_packetnum = handshake_id2 and recv_packetnum = handshake_id1.
21 Bob receives the packet,
22 if (handshake_id2) matches Bob adds Alice to his connections list and starts sending SYNC packets to alice.
23 Alice receives the SYNC packets and starts sending them too.
24 Connection is now established.
25
26 Alice wants to send packets to Bob:
27 Alice sends packets to bob.
28 If bob receives the packets, his next SYNC packets reflect it.
29 Alice receives the SYNC packets which confirms that bob received them
30 Alice clears the packets from her buffer.
31
32 If bob does not receive any packets, but receives a SYNC packet with a larger sent_packetnum than his recv_packetnum:
33 bobs SYNC packets become request packets.
34 The packet id of the missing packet(s) are added to the end of the SYNC packet.
35 Alice resends the packets whose numbers appear at the end of the request packet.
36
37 If bob receives some packets but some are missing
38 bobs SYNC packets become request packets.
39 The packet id of the missing packet(s) are added to the end of the SYNC packet.
40 Alice resends the packets whose numbers appear at the end of the request packet.
41
42 Alice and bob disconnect suddenly:
43 Alice stops receiving SYNC packets from bob.
44 Bob stops receiving SYNC packets from Alice.
45 Connexion times out if no data is received for 5 seconds.
46
47 Packet handling:
48
49 The client receives a SYNC packet:
50 He checks if the packet is valid(sent_packetnum and counter make sense)
51 If the packet is valid:
52 If the client was currently trying to establish a connection.
53 If the handshake was done:
54 Start sending SYNC packets.
55 Add +1 to the counter of the SYNC packets we send.
56 Check to see if any packets were dropped when sending them to us (compare sent_packetnum with the number of packets we received.)
57 If some were, The next SYNC packets we send will be request packets requesting the missing packets.
58 Check if the other client received what we sent him (compare recv_packetnum with the number of packets we sent) and clear them from the buffer.
59 If the packet is a request packet.
60 Send the packets he requested.
61
62
63
64 The client receives a Connection handshake packet(not initiating connection):
65 If handshake_id2 is zero:
66 use the handshake_id1 in the packet as the handshake_id2 of the response.
67 use our random handshake_id1 as handshake_id1.
68 send the response packet.
69
70
71
72 The client receives a Connection handshake packet(initiating connection):
73 check if handshake_id1 matches what we sent.
74 If it does start sending SYNC packets with sent_packetnum as handshake_id2
75
76 The client receives a data packet:
77 Put the packet in the proper place in the receive buffer using packet_num as the reference.
78 If all the previous packets have been received correctly set recv_packetnum equal to packet_num
79
80
81
82 Keep track of the percent of packets dropped, if it is too high, lower the send rate. If it is low, increase it.
83
84 Have a send packets buffer that we can write to and a received packets buffer that we can read from.
85
86
87
88
89 Protocol:
90 Connection handshake packets:
91 [byte with value: 16 (10 in hex)][4 byte (handshake_id1)][4 bytes (handshake_id2)]
92
93 SYNC packets:
94 [byte with value: 17 (11 in hex)][byte (counter)][4 byte (recv_packetnum)][4 byte (sent_packetnum)][sequence of requested packet ids[4 bytes each](not present in keep alive)]
95
96
97 data packets:
98 [byte with value: 18 (12 in hex)][4 byte (packet_num)][data (arbitrary size)]
99
100
101
102 \ No newline at end of file
diff --git a/docs/Messenger_Protocol.txt b/docs/Messenger_Protocol.txt
deleted file mode 100644
index dc92c303..00000000
--- a/docs/Messenger_Protocol.txt
+++ /dev/null
@@ -1,33 +0,0 @@
1Protocol for messages, data, etc..
2
3Streaming audio/video will not use this protocol as they can absorb some data loss.
4
5The protocol itself will run on top of the encryption which means it should be
6impossible for someone to know what type of data is being transmitted.(Well they
7could just analyze how much data is being transmitted for a pretty good guess)
8
9Because it runs on the encryption which itself runs on our Lossless UDP protocol
10it can be guaranteed that no data will be lost.
11
12Basic packet format:
13[char data_id][data]
14
15data_id represents the type of data.
16
17All strings must be UTF-8.
18
19EX: data_id 64 designates a chat message. so the packet would look like: @Hello WorldNULL
20Where @ is the ASCII character for 64, "Hello World" is the message and NULL is the null string terminator.
21
22Proposed data_ids and what they mean (in decimal)
23
24ids 0 to 16 are reserved.
25
2648 Username (Send this packet as soon as you connect to a friend or to each friend everytime you change names.
27 Username is maximum 128 bytes long with the null terminator included)
28
2949 Status change
30
3164 Chat message
326? File transmission.
33
diff --git a/docs/Routing.txt b/docs/Routing.txt
deleted file mode 100644
index 7548f029..00000000
--- a/docs/Routing.txt
+++ /dev/null
@@ -1,66 +0,0 @@
1Routing Protocol.
2
3The routing protocol will only be used when two clients have difficulty
4connecting to each other. This is usually because of NAT issues. For example,
5two people who are behind symmetric NATs are not capable of connecting to each
6other directly.
7
8The routing protocol severely limits the speed at which two clients can
9communicate. This is so that the user of the software does not feel the need to
10turn it off because it is taking too much bandwidth and to prevent peers from
11using it without good reason.
12
13The routing protocol does not provide any anonymity, only convenience.
14
15#############
16
17Draft of protocol:
18
19Alice wants to connect to Bob.
20
21Alice queries the DHT and manages to obtain the ip_port of Bob from Carol and
22Dan both of who are closest mathematically to Bob in the DHT.
23
24Unfortunately Alice is enable to connect to the ip_port for Bob provided by
25Carol and Dan.
26
27Alice assumes then that Bob is behind a bad NAT.
28
29Alice therefore randomly picks between Carol and Dan. She picks Carol.
30
31Alice connects to Carol using the Lossless UDP protocol.
32
33She then sends a routing request over the connection:
34
35[char with a value of 16][Public key of who to route the packets to(client_id)
36(32 bytes)]
37
38Carol checks if she is connected via the DHT to the person (Bob) who the public
39key appears in the routing request.
40
41If she is not she kills the connection.
42
43If she is, she waits for the next data packet to arrive from Alice.
44
45As soon as she receives it she connects to the person (Bob) and sends it to him.
46
47If nothing is received from Bob within a timeout, the connection is killed.
48
49If something is received from Bob, it is sent to Alice and the connection is
50confirmed and continues until either Bob or Alice disconnect.
51
52#############
53
54Some notes:
55
56If both Alice and Bob are friends they will create two different connections
57when each try to connect to each other witch is good because it means data can
58be sent/received on both which lower the chances of the connection being
59severed because the node shut itself down or data being lost because of a bad
60node. It however doubles the amount of data we send/receive.
61
62If both peers manage to connect to each other, the routing connection is
63killed.
64
65All data transmitted trough this protocol must be encrypted in a way that it is
66only decryptable by the receiver and only the receiver.
diff --git a/docs/TODO.txt b/docs/TODO.txt
deleted file mode 100644
index 5d65e12f..00000000
--- a/docs/TODO.txt
+++ /dev/null
@@ -1,51 +0,0 @@
1Things to do now:
2
3-Network protocol (Done)
4
5-Figure out the best way to do "lossless" UDP. (Done)
6
7-Start work on the im protocol.(simple im part pretty much done)
8
9-Start coding the gui (In Progress (Using Qt5))
10
11-Get a basic im client working using the now completed DHT implementation to find the ips of your friends.
12
13-Find some good encryption libraries.(Done)
14 we will use: http://nacl.cr.yp.to/
15
16-Add NaCl to our build system.
17
18-Make NaCl work on windows (DONE)
19 https://github.com/jedisct1/libsodium
20
21
22-Crypto (Done (needs testing))
23
24-Harden the DHT (Research in progress)
25
26-Find and fix bugs in the code.
27
28Things to do later:
29
30-Figure out the whole sound and video transmission. (encrypted and fast)
31
32-File transfer (encrypted and fast)
33
34Less important.
35
36-Symmetric NATs
37 No UDP hole punching on them so we need to do something else
38 (only if both the clients which try to connect to themselves are behind one)
39
40
41-Decentralized IRC like channels (chatrooms).
42
43
44
45-Offline messaging protocol (text only)
46 Use your friends.(or maybe the people closest (mathematically by comparing client_id's) to you or the friend you want to send the message to).
47 The message will not be very big. Lets say we limit the maximum number of bytes for one to 1024, it means if every client stores 1024 offline messages it only takes 1 MB of ram.
48
49-IPv6
50 Currently the core only supports ipv4
51
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-07 02:28:53 +0000