Ben's Thoughts on Message Structure

Fields

Here are the fields I think we're going to need to include in a message and a brief description:

field	description	comments
dst	destination of the message	I think we should use some type of hashed username for this so it has a standard length. We could do a hash-table to store all the users or something, idk. Update, this should probably be reflective of the device too.
src	source of the message	Same as dst, I think we should use a hash.
tmstmp_lcl	timestamp message was sent from device
tmstmp_srv	timestamp message was received at server	This will initially be NULL when the message is sent.
type	what kind of message it is	See below for possible type values I'm thinking we'll need.
id_no	numerical reference value	A unique number to reference this message.
ref	id_no of message to reference	For use in things like replies or reactions
payload	data to send

Type Values

Possible type values I think we'll need:

value	name	description	Visible to User (Y/N)
-1	ERR	Error message	N
0	MSG	Standard message	Y
1	RPLY	Reply to message	Y
2	REAC	Reaction to message	Y
3	AUTH	Request for authentication to server	N
4	AACK	Authentication acknowledgement from server	N
5	ALIV	Is this device alive?	N
6	ACK	Acknowledgement	N
7	DBM	Database message (for transferring messages b/t devices)	N

Message Examples

Here are some example messages with values (in json format) and what the message means. Some notes:

1. In general, when ACK messages are sent, they will contain no payload and have the ref for the message they are acknowledging. See keep-alive sequence below for an example.
2. I'm using a user|device construct for dst and src in the messages, although in reality we will have to figure some way to track this.
3. The tmstmp_srv field is filled in when the message reaches the Textric server, but will be NULL on the originating device. In these examples (except as noted under Text Message), assume that the message is on the originating device and thus will not have it filled in. Notable exception is administrative messages originating from the server will have tmstmp_srv = tmstmp_lcl and will always have both fields filled in since the server is the local device.

Text Message

From sending device:

message = {
    dst: bob|device1
    src: alice|device1
    tmstmp_lcl: 2021-05-22T23:00:00
    tmstmp_srv: NULL
    type: MSG
    id_no: 0001
    ref: NULL
    payload: "Hello, world!"
}

On receiving device:

message = {
    dst: bob|device1
    src: alice|device1
    tmstmp_lcl: 2021-05-22T23:00:00
    tmstmp_srv: 2021-05-22T23:00:01
    type: MSG
    id_no: 0001
    ref: NULL
    payload: "Hello, world!"
}

Reply to Message

message = {
    dst: alice|device1
    src: bob|device1
    tmstmp_lcl: 2021-05-22T23:05:00
    tmstmp_srv: NULL
    type: RPLY
    id_no: 0002
    ref: 0001
    payload: "Hello, Alice!"
}

Reaction to Message

message = {
    dst: bob|device1
    src: alice|device1
    tmstmp_lcl: 2021-05-22T23:05:30
    tmstmp_srv: NULL
    type: REAC
    id_no: 0003
    ref: 0002
    payload: "😂"
}

Error Message

message = {
    dst: bob|device1
    src: textric
    tmstmp_lcl: 2021-05-22T23:06:00
    tmstmp_srv: 2021-05-22T23:06:00
    type: ERR
    id_no: 0004
    ref: NULL
    payload: ERR_CODE
}

Keep-alive Sequence

message = {
    dst: bob|device1
    src: textric
    tmstmp_lcl: 2021-05-22T23:06:30
    tmstmp_srv: 2021-05-22T23:06:30
    type: ALIV
    id_no: 0005
    ref: NULL
    payload: NULL
}

message = {
    dst: textric
    src: bob|device1
    tmstmp_lcl: 2021-05-22T23:06:31
    tmstmp_srv: 
    type: ACK
    id_no: 0006
    ref: 0005
    payload: NULL
}

Database to new device message

message = {
    dst: bob|new_device
    src: bob|device1
    tmstmp_lcl: 2021-05-22T23:30:00
    tmstmp_srv:
    type: DBM
    id_no: 0007
    ref: NULL
    payload: bobs_message_database
}

Blank message for copy/paste

message = {
    dst:
    src:
    tmstmp_lcl:
    tmstmp_srv:
    type:
    id_no:
    ref:
    payload:
}