xmpp stack decision

pm/xmpp-lib-decision.org

@@ -0,0 +1,62 @@
+#+title: 0.1.3 XMPP Event Model and Library Choice
+#+created: [2026-04-14 Tue 15:05]
+#+updated: [2026-04-14 Tue 15:20]
+
+* initial research and recommendation
+Slixmpp is an MIT-licensed XMPP library for Python 3.11+.
+
+It is a fork of SleekXMPP and uses Rust for some performance-sensitive modules. In practice that means:
+- Python app, not Rust app
+- usually installable via PyPI wheels
+- if wheels are unavailable, cargo may be needed to build the extension module
+- maintained enough to be a sane v0 choice
+
+For this bridge, slixmpp is the best MVP pick.
+
+* minimum viable raw xmpp
+If we do not use a library, we would need to implement the XMPP client plumbing ourselves:
+- TCP + XML stream handling
+- SASL auth
+- TLS
+- stanza parsing/serialization
+- MUC join/leave semantics
+- keepalive/reconnect handling
+- duplicate/self-message suppression rules on top
+
+Pros:
+- maximum control
+- fewer dependencies
+- easier to trim down to exactly what we need
+
+Cons:
+- you are writing a mini XMPP client anyway
+- more edge cases
+- slower to reach a reliable relay
+- easier to get auth/reconnect/MUC details subtly wrong
+
+For v0, that trade is not worth it.
+
+* event model we actually need
+| event                | use                              |
+|----------------------+----------------------------------|
+| connect/auth         | establish session                |
+| self-presence        | confirm MUC join before relaying |
+| groupchat message    | relay input                      |
+| presence join/part   | ignore or log only               |
+| subject/topic change | optional log only                |
+| disconnect/error     | reconnect handling               |
+
+* recommendation
+Use slixmpp for the XMPP side.
+
+Why:
+- it covers the protocol plumbing we do not want to hand-roll
+- it is a straightforward bot/daemon fit
+- it lets us focus on bridge behavior, not XML socket mechanics
+- it is good enough for a single-room relay MVP
+
+* summary
+Use slixmpp unless we deliberately choose to prototype a raw XMPP client first.
+
+The bridge only needs a narrow slice of XMPP. Slixmpp gives us that slice without forcing us to reinvent session management, MUC join semantics, or reconnect logic.
+