Status of This Memo

This memo defines an experimental protocol for the unreliable, lossy, and emotionally stateful transmission of feelings across human and semi-human systems. Distribution of this memo is unlimited; comprehension is not guaranteed.

1. Abstract

The Feelings Transport Protocol (FTP) specifies a mechanism for transmitting subjective internal states (“feelings”) between endpoints that lack a shared ontology, clock, or emotional checksum. FTP is optimized for ambiguity, latency, and misinterpretation, while providing optional extensions for regret, sarcasm, and overthinking.

2. Terminology

  • Feeling: A payload whose meaning changes upon inspection.

  • Sender: An endpoint that believes it knows what it is feeling.

  • Receiver: An endpoint that believes it understands what was meant.

  • Silence: A control frame with infinite interpretations.

  • “I’m fine”: A reserved keyword indicating protocol failure.

3. Design Goals

FTP is designed to:

  • Maximize expressive bandwidth while minimizing clarity

  • Allow retransmission of old feelings without warning

  • Support out-of-order delivery (“By the way, three weeks ago…”)

  • Fail gracefully into awkward pauses

FTP explicitly does not guarantee:

  • Mutual understanding

  • Timely acknowledgment

  • Emotional idempotency

4. Packet Structure

An FTP packet consists of the following fields:

+----------------+----------------+
| Header         | Mood Flags     |
+----------------+----------------+
| Payload        | Subtext        |
+----------------+----------------+
| Unsaid Data    | Regret Trailer |
+----------------+----------------+

4.1 Mood Flags

Common flags include:

  • HAPPY – May be misread as SARCASTIC

  • TIRED – Overrides all other flags

  • FINE – Signals critical error

  • JUST_JOKING – Set after damage is done

5. Handshake Procedure

  • Sender: “Can I tell you something?”

  • Receiver: “Sure.”

  • (Protocol state irreversibly changes)

No cryptographic guarantees are made at this stage.

6. Encryption and Trust

FTP supports End-to-End Vulnerability (E2EV) by default.

Trust establishment follows a Trust On First Overshare (TOFO) model:

  • The first deeply personal disclosure permanently alters the trust graph.

  • Revocation is possible but socially expensive.

Key rotation occurs during:

  • Long walks

  • Late nights

  • Car rides with no music

7. Error Handling

7.1 Common Errors

  • MISINTERPRETATION
    Receiver decodes payload using personal trauma codec.

  • OVERREACTION
    Receiver allocates excessive resources to a low-priority feeling.

  • UNDERREACTION
    Sender retries with increased volume and historical examples.

  • GHOSTING_TIMEOUT
    Receiver fails to ACK within an undefined emotional window.

7.2 Recovery

Recovery often involves:

  • Apologies

  • Snacks

  • Time

  • Or pretending nothing happened (deprecated but widely implemented)

8. Backward Compatibility

FTP is backward compatible with:

  • Passive aggression

  • Polite nodding

  • “That’s interesting” responses

It is not compatible with:

  • Mind reading

  • Perfect timing

  • Telepathy (still draft)

9. Security Considerations

FTP is vulnerable to:

  • Replay attacks (“You always do this”)

  • Man-in-the-middle advice

  • Side-channel leaks via tone

Implementers are advised to:

  • Validate assumptions

  • Rate-limit venting

  • Enable the LISTEN extension

10. IANA Considerations

No port number has been assigned.
FTP typically tunnels over:

  • Coffee

  • Walks

  • Text messages sent at 2:13 AM

11. Conclusion

FTP remains the most widely deployed protocol in human history despite:

  • Poor documentation

  • Undefined semantics

  • No reference implementation

Its continued use suggests that perfection is optional, but sincerity is not.