SOS Protocol: Technical Specification for Intimate SMS Messaging
The SOS protocol defines the structure and logic for intimate text-based communication over SMS. It uses a strict message format with states, flags, and a checksum to ensure synchronization and integrity verification. This document details the message format, finite state machine behavior, and error handling—enabling reliable operation without internet connectivity.
Message Format and Structure
An SOS message follows this schema: SOS-message = start-tag "|" version "|" state "|" session-id "|" flags "|" payload-length "|" payload ["|" checksum]. Fields are pipe-delimited.
- start-tag: "SOS" — protocol identifier.
- version: "1" — current version.
- state: one of (IDLE, SYNS, SYNR, ESTD, FINW, PRMT, BUSY, SUSP, CLSD, MORE).
- session-id: 5-digit number (1–65535), monotonically increasing per session.
- flags: "A" (ACK), "F" (FIN), "R" (RST), or empty.
- payload-length: three digits indicating payload length in characters (0–160).
- payload: plain text, optionally containing control sequences.
- checksum: two hex characters (optional).
Example: SOS|1|SYNS|42||12|Hi gorgeous|3E.
Checksum Calculation
Algorithm:
- Split the payload into words (excluding whitespace).
- Multiply word lengths (use 1 if payload is empty).
- Subtract the number of spaces.
- Take modulo 256 and convert to uppercase hex.
This method ensures simplicity and resilience against common SMS transmission distortions on mobile devices.
Terminology and Control Sequences
Key concepts:
- Initiator: the party sending the first message.
- Target recipient: the party accepting or declining the exchange.
- State: a stage in the protocol’s finite state machine.
- Control sequence: an emotional or functional marker embedded in the payload.
Common control sequences in the payload:
| Sequence | Meaning |
|----------|---------|
| Y | Agreement |
| N | Decline |
| ... | Pause |
| :-) | Friendly hint |
| ;-) | Playful subtext |
| :-D | Laughter |
| ^_^ | Joyful confirmation |
| >_< | Embarrassment |
| ~ | Ambiguity |
| (.)(.) | Reference to physical attributes |
| ¯\\_(ツ)_/¯ | Uncertainty |
Implementations may parse these for automated responses or UI enhancements.
Protocol State Machine and States
Each participant maintains a finite state machine. Synchronization occurs via the state and flags fields.
States:
- IDLE: Initial state.
- SYNS: Awaiting response to invitation.
- SYNR: Invitation received; reply sent.
- ESTD: Active exchange.
- FINW: Waiting for termination acknowledgment.
- PRMT: Premature termination.
- BUSY: Temporarily unavailable.
- SUSP: Suspicious activity detected.
- CLSD: Session closed.
- MORE: Continuation after FIN.
State Transitions
Transitions triggered by sending/receiving SOS messages:
- IDLE → SYNS: send SYNS; timeout after 10 min.
- SYNS → ESTD: receive SYNR + ACK flag (A).
- SYNS → PRMT: timeout or RST flag received.
- ESTD → FINW: send FIN flag (F); timeout after 2 min.
- FINW → CLSD: receive ACK (A).
- FINW → MORE: receive MORE + ACK (A); return to ESTD.
- Any → PRMT: receive RST or timeout.
- IDLE → BUSY: respond BUSY to incoming SYN.
- SYNR → SUSP: anomaly in session-id or checksum.
Timeouts and Penalties
- SYN: 10 min → PRMT.
- ESTD: 10 min without ACK → PRMT.
- FINW: 2 min → CLSD.
- MORE: 10 min → CLSD.
Penalties:
- PRMT: 30-minute block; 3 occurrences → 7-day suspension.
- BUSY: 15-minute wait before retry.
- SUSP: immediate RST + 24-hour suspension.
Collision Handling
If a SYN arrives while a session is active: respond with BUSY and message "session already active." Initiator returns to IDLE. Non-monotonic session-id → SUSP → RST.
Key takeaways:
- SOS standardizes state-aware SMS messaging with built-in checksums for reliability.
- Enables synchronization (SYNS/SYNR/ESTD) entirely offline—no internet required.
- Control sequences streamline expressive, emotionally nuanced exchanges.
- Penalties and timeouts prevent spam, abuse, and protocol anomalies.
- The lightweight checksum remains robust against typical SMS corruption.
— Editorial Team
No comments yet.