RFC 9001 - The Feelings Transport Protocol (FTP)

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.