forked from irungentoo/toxcore
-
Notifications
You must be signed in to change notification settings - Fork 292
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
msgV3 PoC #1781
Draft
zoff99
wants to merge
1
commit into
TokTok:master
Choose a base branch
from
zoff99:zoff99/msgv3_poc_001
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+195
−6
Draft
msgV3 PoC #1781
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,154 @@ | ||
# Tox MessageV3 (alias Hubble telescope glasses) | ||
|
||
|
||
proposal to transpartently patch current text messages to fix double messages and missed messages (and to support history sync in the future) | ||
|
||
|
||
new defines: | ||
------------ | ||
|
||
``` | ||
#define TOX_MAX_MESSAGE_LENGTH (1372) | ||
#define TOX_MSGV3_MSGID_LENGTH (32) | ||
#define TOX_MSGV3_TIMESTAMP_LENGTH (4) | ||
#define TOX_MSGV3_GUARD (2) | ||
#define TOX_MSGV3_MAX_MESSAGE_LENGTH (TOX_MAX_MESSAGE_LENGTH - TOX_MSGV3_MSGID_LENGTH - TOX_MSGV3_TIMESTAMP_LENGTH - TOX_MSGV3_GUARD) | ||
|
||
|
||
#define PACKET_ID_HIGH_LEVEL_ACK (66) | ||
|
||
typedef enum Message_Type { | ||
MESSAGE_NORMAL = 0, | ||
MESSAGE_ACTION = 1, | ||
MESSAGE_HIGH_LEVEL_ACK = 2, | ||
} Message_Type; | ||
``` | ||
|
||
new message type: | ||
----------------- | ||
|
||
``` | ||
typedef enum TOX_MESSAGE_TYPE { | ||
|
||
/** | ||
* Normal text message. Similar to PRIVMSG on IRC. | ||
*/ | ||
TOX_MESSAGE_TYPE_NORMAL = 0, | ||
|
||
/** | ||
* A message describing an user action. This is similar to /me (CTCP ACTION) | ||
* on IRC. | ||
*/ | ||
TOX_MESSAGE_TYPE_ACTION = 1, | ||
|
||
/** | ||
* A high level ACK for MSG IG (MSG V3 functionality) | ||
*/ | ||
TOX_MESSAGE_TYPE_HIGH_LEVEL_ACK = 2, | ||
|
||
} TOX_MESSAGE_TYPE; | ||
``` | ||
|
||
tweak in Messenger.c in m_handle_packet(): | ||
------------------------------------------ | ||
|
||
``` | ||
case PACKET_ID_MESSAGE: // fall-through | ||
case PACKET_ID_ACTION: | ||
case PACKET_ID_HIGH_LEVEL_ACK: { | ||
``` | ||
|
||
tweak in Messenger.c in m_send_message_generic(): | ||
------------------------------------------------- | ||
|
||
``` | ||
if (type > MESSAGE_HIGH_LEVEL_ACK) { | ||
``` | ||
|
||
|
||
|
||
sending and receiving msgV3: | ||
---------------------------- | ||
|
||
|
||
raw data: | ||
|
||
``` | ||
what |Length | Contents | ||
---------------------------------------------------------------- | ||
pkt id |1 | PACKET_ID_MESSAGE (64) | ||
msg txt |[0, 1334] | Message (usually as a UTF8 byte string) | ||
guard |2 | 2 NULL bytes | ||
msg id |32 | *uint8_t hash (what hash function?) to uniquely identify the message | ||
create ts |4 | uint32_t unixtimestamp in UTC of local wall clock | ||
1334 = TOX_MSGV3_MAX_MESSAGE_LENGTH | ||
``` | ||
|
||
sending description: | ||
the client needs to use the new msgV3 format for text messages. | ||
msg id will be a 32 byte hash value calculated the same way as now for filetransfers. | ||
a helper function will be added to do that. | ||
a client needs to save the created msd ig and the timstamp, to be able to resend the exact same data when a high level ACK was not received. | ||
|
||
|
||
receiving description: | ||
|
||
the maximum real text playload will decreae to 1334 bytes. | ||
cients not using msgV3 will just process the message text up to the first NULL byte when interpreted as UTF-8. | ||
if a client is using the data for other things as UTF-8 text, then that client needs to account for that. | ||
|
||
clients using msgV3, will check for the guard and use the remaining data as uniqe message ID and unix timestamp in UTC wall clock time. | ||
after fully processing the message, the client then needs to send the high level ACK with that msd id. | ||
|
||
what happens if a malicious client sends the guard and then some random data? | ||
then a bogus msg id and bogus timestamp will be received. so if messages are ordered by this timestamp, then message ordering will be wrong | ||
for this single message. | ||
are there other possible problematic things that can happen? | ||
|
||
|
||
sending and receiving high level ACK: | ||
------------------------------------- | ||
|
||
raw data: | ||
|
||
``` | ||
what |Length | Contents | ||
---------------------------------------------------------------- | ||
pkt id |1 | PACKET_ID_HIGH_LEVEL_ACK (66) | ||
msg txt |1 | dummy Message always '_' character | ||
guard |2 | 2 NULL bytes | ||
msg id |32 | *uint8_t hash (what hash function?) to uniquely identify the message | ||
receive ts |4 | uint32_t unixtimestamp in UTC of local wall clock | ||
``` | ||
send the high level ACK as new message type. get a new uniqe hash with the new helper function. | ||
|
||
new clients know which messages was received and also get the proper receive timestamp. | ||
old clients will just ignore the unknown message type. | ||
in case some older clients just display any message type from the callback, we include a valid UTF-8 text as '_' with NULL termination. | ||
|
||
|
||
add helper functions for receiving: | ||
----------------------------------- | ||
|
||
``` | ||
bool tox_messagev3_get_new_message_id(*uint8_t msg_id) | ||
will return the msg id | ||
msg_id A valid memory location for the hash data. | ||
It must be at least TOX_HASH_LENGTH bytes in size. | ||
|
||
calculated the same as we do for filetransfers now: | ||
/* Tox keys are 32 bytes like FILE_ID_LENGTH. */ | ||
new_symmetric_key(f_id); | ||
file_id = f_id; | ||
``` | ||
|
||
|
||
### pros: | ||
* does not break API or clients | ||
* prevent double message sending (when a msg id is received again, just ignore it and send a high level ACK again) | ||
* prevent missed messages (low level ACK sent but message not fully processed) | ||
|
||
### cons: | ||
* to be fully used clients need to add functionality | ||
|
||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://en.wikipedia.org/wiki/Year_2038_problem
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i know. but whats the fix? using 64bits is taking 8 bytes.
is there a better solution that 64bits?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unsigned 32-bits should work until year 2106.
If extended to 5 bytes = 40bits, it could store a range of about 34865 years.