DAPPS is "Distributed Asynchronous Packet Pub/Sub", a proposed overlay over amateur packet radio, with the intention of making it easier for application developers to leverage "the network" without having to solve many of the same problems again and again.
In a nutshell, DAPPS discards the concept of a "connected session" between two stations potentially separated by multiple unreliable hops, and instead facilitates "eventual delivery" message passing. The application interface at each end is MQTT, facilitated either by installation of a DAPPS instance alongside the existing packet node software, or perhaps in future by the node software itself.
(Its implementation can still make use of AX.25 connected sessions to pass messages between neighbour nodes, but there is no session per se.)
Passing messages between instances over the air will require a new protocol which is intended to be implemented using the binary-transparent sessions made available, albeit fairly fiddly to utilise, by existing node software. i.e. this can be implemented within existing AX.25 using existing, unmodified, software.
You might think of this scheme as a bit analogous to packet mail, but with structured messages intended to be produced and consumed by human-facing applications rather than humans.
This is a request for comments on a proposed on-air protocol for DAPPS.
Within a session established between two DAPPS nodes, there is a need for a compact but, for ease of debugging, human-readable (and maybe even human-writeable) protocol.
A message passed on-air is expected to be passed, byte for byte, to the body of a message sent to the corresponding MQTT topic at the destination system.
When a DAPPS instance wishes to pass a message to another DAPPS instance, it sends a message like:
msg topic@system fmt=plain len=9 sha1=aaaa
msgis constanttopicis the MQTT sub-topic to which to deliver the message on the destination system.systemis the callsign/ssid of the destination instance of DAPPS. We could borrow hierarchical addresses from packet mail, even follow their routes? This may be the system to which we are connecting right now, or it may be a distant system.
a series of key=value pairs follows:
len=specifies the number of bytes, analogous to HTTP'scontent-lengthheader. This is not optional.fmt=allows the format of a payload to be specified. This might includeplain,base64,binetc. If omitted we might default toplain?sha1=is the hex-encoded SHA1 hash of the payload, allowing it to be integrity checked. Borrowing from git hashes, this could be truncated down to as few initial characters as desired.
The msg line is terminated with a newline (\n) to allow for convenient human use for debug/testing from a terminal.
The remainder is even simpler:
- the response to the
msgline is a simple "ok", with anything else considered an error, do not send the message - the sending station then sends the number of bytes they have specified in
lenand stops- there is no delimiter and thus no escaping - the receiving station responds with an
okperhaps with a receipt uuid of some kind, this forming a message id.
The session state returns to "waiting for msg".
In summary:
> msg myapp@gb7rdg fmt=plain len=11 sha1=7b50 # > I would like to send a message
< ok # < go ahead
> Hello world # > [the message]
< ok b84268d0 # < ok, here's an id
A message could go either way through a connected session at any time.
Instances should coordinate with each other to only have one message in transit at a time between each other- in case of a
collision the ok could be a simple standby.
One could imagine a "fire and forget" variant of this simple scheme using UI frames, perhaps used for one-to-many traffic.
One might consider a cryptographic message signature to be added later as another key/value pair, allowing for authenticity.
One might might consider adding a multi-part mechanism.
A TTL (either an actual time or a number of hops) could be implemented as a key/value pair on the msg line.