JSQ transport
JSQ is a transport protocol for chat, mail, files, groups, and network services. Here is why I built it—and how those operating ideas fit together.
Why I built JSQ · Jerome Goddard II, W4IJG
I was an avid user of FSQ, JS8, and AX.25 packet on APRS. I loved the freedom of keyboard-to-keyboard conversation in FSQ. Its commands also let us build an ad hoc network: relay a message, repeat my message, store and retrieve files, ask for heard lists, and check signal reports. We could check in, cooperate, and work out who could hear whom. JS8’s weak-signal reception, heartbeats, and signal checks were another part of what drew me in.
I liked the speed of APRS packets over AX.25 and the idea of exchanging files through a packet BBS. I wanted that usefulness without tying the workflow to a persistent connected-mode modem link.
But each system had its own modem and quirks. For the way I wanted to operate, the interfaces felt dated and centered on the modem. I wanted conversations, files, mail, and the network to be the starting point.
That became JSQ: bring those useful operating ideas together in a transport protocol above the individual modems. OpenJSQ is the application that puts that approach in front of the operator.
Two foundations
The name tells the story: J from JS8, and SQ from FSQ.
Messages with somewhere to go.
Directed messages, acknowledgements, stored messages, and relays help a conversation continue when the operator is away or the direct path is missing.
The shared design goalA channel where stations cooperate.
Live keyboard conversation sits alongside relay, repeat-my-message, file storage and retrieval, heard lists, and signal reports. Those commands let operators build and check an ad hoc network of cooperating stations, with relay paths chosen by the operator.
The FSQ-derived actionsThese traditions overlap: JS8Call also supports conversation and station queries; FSQ also has stored-message and relay commands. JSQ brings those operating ideas together without tying them to one waveform.
More digital modes give us more signals to choose from. The goal of JSQ is to make those signals useful through a shared way to converse, exchange files, leave mail, and work with other stations.
JS8’s weak-signal reception is an inspiration for the project. OpenJSQ does not use the JS8 waveform and is not over-the-air compatible with JS8Call. Peer compatibility · Performance evidence and limits
Receive and reply
On an audio connection, enabled FSQ, AX1200, and JG25 decoders listen concurrently at their supported speeds. The selected transmit waveform is not a receive filter.
Choose a caller, then play the exchanges or step through one. Watch the request reach JSQ and the permitted automatic reply return on the caller’s mode.
Your station · OpenJSQ · one audio link
Station A asks for a signal report on FSQ-3. The matching enabled decoder receives it.
Listening across enabled modes · transmitter idle
Your manual transmit choice stays JG25 · 2400/F0 in this example. Each automatic reply follows its caller’s supported mode and profile.
Stations need an audio connection, a usable path on the shared radio channel, enabled receivers, and support for the requested services. They do not need matching transmit modes or speeds; automatic responses must also be permitted. Only one waveform transmits at a time. A KISS-only link receives AX1200 rather than all three modem families. Multi-receive setup → · Try it with two stations →
FSQ, AX1200, and JG25 acquire and frame each transmission as it arrives. They do not require JS8-style time-aligned intervals or a persistent connected-mode modem session; reliability is handled by the relevant JSQ service.
Manual messages, including replies you type, use your selected modem. The shared transmitter sends one waveform at a time, and reception pauses during local transmission.
Full multi-receive needs radio audio; an external KISS TNC receives AX1200 only. Legacy waveform compatibility does not provide JSQ services: the peer application must support the service too.
Adapters translate common operations into each link’s representation and report capabilities, timing, integrity and transmit-completion evidence. The modem handles modulation, frames, channel access, and payload limits.
For example, sending a file uses different over-the-air formats on AX.25 and FSQ. JSQ handles those differences while keeping the same rules for recovering missing pieces, resuming a transfer, and checking that the complete file arrived intact.
Adapter contractLayer responsibilitiesShared encodingsModem choices
In OpenJSQ, Verified direct chat on AX1200 and JG25 uses acknowledgements and retries. FSQ chat is best effort; groups, Allcall and relayed chat use Live. An optional end-to-end receipt is a separate service, not the Verified chat mode.
These are different kinds of evidence, not five guaranteed steps for every message. A receipt does not prove that a human read the message or authenticate the operator.
Verified packet chat uses service acknowledgements and automatic retransmission. JSQ Delivery Receipt v1 instead reports acceptance of an identified message at the destination application, when supported and advertised; it does not itself add retransmission. Broadcast and group traffic is not receipted. A missing optional receipt is not proof of non-delivery and does not itself trigger a retry.
On AX1200 the receipt is an OFQ2 packet type; on FSQ it is carried in a directed jsqr1: envelope. This does not turn FSQ chat into Verified packet chat.
Your station can hold a letter until its recipient is heard. A capable mailbox can accept custody for later delivery; the sender keeps its copy until that handoff is accepted and stored.
“Leave the meeting details for the station joining later.”
Mailbox custodyRecover missing blocks, resume an interrupted transfer and check the complete file. A station can advertise a shared folder for direct browsing and retrieval within its access policy.
“Fetch the updated roster from the club station.”
Reliable files · Sharing in OpenJSQUse a callsign for a direct conversation, a shared group destination for a net, or Allcall for everyone listening. Groups are self-enrolled; there is no membership server.
A peer advertises what it supports. A modem capable of moving a file does not prove that its operator is serving shared files. Sharing is advertised only while available under the station’s policy.
Groups use @GROUPNAME. A callsign checksum detects errors; it is not authentication. Received content remains untrusted input and is not executed.
Service names such as file.reliable and mail.custody express meaning. AX1200 uses a 16-byte capability payload; FSQ carries a compact token in presence or version replies; JG25 uses its own capability response.
Station identityGroupsCapabilitiesAX1200 encodingFSQ tokensJG25 capabilities
Choose a willing station that can hear both ends. It receives the message and transmits it onward, preserving the original sender and final destination.
In the current app, AX1200 and JG25 use one relay; FSQ can carry a chain. Relayed chat is Live, and shared-file browsing requires a direct connection. Each hop takes airtime and depends on the relay’s settings.
JSQ application relay is separate from AX.25 link-layer digipeating. The service model requires provenance, bounded hops, duplicate suppression and loop prevention.
The architecture allows a relay implementation to receive through one modem and forward through another. That is an architectural possibility, not a claim that the current OpenJSQ app runs a simultaneous cross-modem bridge.
Current relay behavior and limitsRelay serviceRelay architecturePacket limits
Automatic behavior is bounded, visible and governed by station policy. Some replies transmit information; other enabled services store or forward traffic.
Answer requests for signal reports, heard stations, location, status and software information.
Accept notes and files, hold mail, serve shared files or relay traffic according to your settings. AX1200 relay has a separate forwarding switch.
OpenJSQ shows automatic activity. Net mode holds automatic traffic for a directed net while leaving deliberate operator messages available. Operating controls
Adapters map semantic requests to each bearer. Legacy FSQ uses punctuation such as ? for signal reports and $ for heard lists. Do not assume every trigger has identical legacy behavior: OpenJSQ’s repeat action repeats its last transmission to the requester, while FSQCall echoes supplied text.
Automatic services have limits and must not create reply loops. Protocol actions do not authorize arbitrary software execution.
Read the specifications, or see these ideas in OpenJSQ.