Protocol

Direbox is powered by a new protocol called APRSChat that sits atop the legacy APRS protocol in order to enable unique features.

This protocol enables many new capabilities on APRS, including encrypted messaging, encoded messaging, a common standard for message concatenation, and increased packet unique identifiers, all while retaining backwards-compatibility with existing APRS hardware and software implementations.

APRSChat

The APRS spec for messaging and bulletins allows for a five character metadata payload.

In message packets, these characters are appended to the end of the payload and segregated by a { character. For bulletins, they are inserted after the bulletin ID and before the bulletin text. This spec is defined in Chapter 14 of the APRS specification.

Most APRS applications use this metadata payload for either proprietary message concatenation or as a simple counter variable. APRSChat instead defines an open standard that encompasses these traditional use-cases, expands their functionality, and publishes it open-source for others to use as they see fit.

APRSChat follows a very simple format:

  1. Payload Type: The first character defines the payload type. Accepted arguments are one of p, e, b (all lowercase). p is a plaintext packet, e is an encrypted packet, and b is a Base64-encoded packet. See Encryption for information on valid encryption algorithms.
  2. Current Packet Count: The second character defines the position of the current packet for concatenation. For example, if a 268 character message is sent with the default character limit of 67 bytes, the first 67 byte packet would include the character 1, the second chunk of data would be 2, etc.
  3. Total Packet Count: The third character is the total size of the message or bulletin payload. This signals to APRSChat how many packets to expect before a concatenated message is finished transmitting. The longest possible count is 9, which would enable APRS's default 67 character limit to be extended to 603 characters or the more modern limit of 255 characters to 2295 characters! However, due to network congestion, Direbox limits this max count variable to 4 and we would suggest that other apps do the same.
  4. Random Alphanumeric Characters: The last two characters are reserved for two random alphanumeric characters. These characters can be any valid ASCII or UTF-8 uppercase, lowercase, or numeric characters. If a long message or bulletin is being sent, these random characters should be the same in order to properly "group" packets that require concatenation. By introducing a pseudo-unique identifier to every packet or groups of packets, APRSChat greatly reduces the odds of packets being re-assembled out of order and also allows for disposal of concatenated messages where delivery of any given part is unsuccessful.

The to or destination field for APRSChat packets should always be APCHT. This signals to the receiving station that any additional message or bulletin metadata uses the APRSChat protocol.

As the majority of packets transmitted over APRS at present are plaintext packets, some kind of standard to identify encrypted and enocded communications is required. Receiving stations need to know how to decrypt and/or decode packets on a packet-by-packet basis.

As most encrypted block ciphers increase the output length of a payload, this also requries novel means of message concatenation. While a human can discern a plaintext message that's out of order, a machine requires packets to be in order 100% of the time for decryption to take place.

APRSChat is also an extensible standard - while e currently defines a Fernet AES-128-CBC encrypted packet, any number of characters could be used to define other encryption or encoding schemes. For example, c could be used to specify a ChaCha20-Poly1305 packet, or a could define an AES-256 encrypted packet.

There are many possibilities for expanding APRSChat functionality using this protocol!