Initial commit: Hermes skill xmpp-server-prosody

2026-09-29 09:45:02 +00:00 · 2026-09-06 13:51:11 +00:00
commit 3da6c8709b
28 changed files with 2016 additions and 0 deletions
@@ -0,0 +1,56 @@
+# Slidge/Telegram: folders unsupported, channels listable from DB (2026-08-29)
+
+User question context: "как найти каналы на которые я подписан?" / "папки в телеграме
+были, как их вытащить?"
+
+## Telegram folders (папки) — slidge does NOT support them
+
+Checked slidge 0.4.2 + slidgram source: there is **no folder support at all, by design**.
+
+Evidence in `slidgram/session.py`, `_on_tg_UpdateDialogPinned`:
+
+```python
+if isinstance(update.peer, pyro_raw_types.DialogPeerFolder):
+    # TODO: investigate what that is
+    return
+```
+
+- The bridge explicitly ignores `DialogPeerFolder` updates. XMPP has no concept of
+  "chat folders" — the roster is a flat list of contacts/MUCs, so there is nowhere to
+  put folder structure even if read.
+- Pyrogram DOES have `get_folders()` (raw `messages.GetDialogFilters`), but you cannot
+  run a second Pyrogram client against the bridge's `*.session` file while the bridge is
+  live — one MTProto session = one active connection; the second client kicks the first
+  (bridge disconnects). Do NOT spin up a parallel reader.
+- Only honest options: (a) one-time read of folders by briefly stopping the bridge
+  (~30 s) and using the session file — for a report, not for XMPP; (b) client-side
+  folders in Pidgin (Blist groups) as the only XMPP-faithful analog.
+
+## Finding subscribed channels/groups — query slidge.sqlite `room` table
+
+All Telegram chats the account is in are in the bridge DB (no need to touch Telegram):
+
+```bash
+docker exec icq-slidgram sh -c 'python3 -c "
+import sqlite3
+con = sqlite3.connect(\"/var/lib/slidge/slidge.sqlite\")
+con.row_factory = sqlite3.Row
+print(\"rooms:\", con.execute(\"SELECT count(*) FROM room\").fetchone()[0])
+for r in con.execute(\"SELECT muc_type, count(*) n FROM room GROUP BY muc_type ORDER BY n DESC\"):
+    print(\" \", r[\"muc_type\"], r[\"n\"])
+for r in con.execute(\"SELECT muc_type, name, jid_localpart FROM room ORDER BY muc_type, name\"):
+    print(\"%s | %s | %s\" % (r[\"muc_type\"], (r[\"name\"] or \"\")[:50], r[\"jid_localpart\"]))
+"'
+```
+
+Typical profile for a power user: ~131 rooms = 91 CHANNEL + 29 CHANNEL_NON_ANONYMOUS
+(public group/forum channels) + 11 GROUP (small private groups). `jid_localpart` is
+`group-<tgid>` — the exact MUC address to join from XMPP.
+
+## Pitfall: `docker exec` + heredoc `< 'PY'` silently returns nothing
+
+`docker exec icq-slidgram python3 - <<'PY' ... PY` printed **empty output** (the heredoc
+is consumed by the local shell/pty layer, not delivered to the container's stdin).
+Working forms: `docker exec ... sh -c 'python3 -c "..."'` (as above), or write the file
+inside the container then `docker cp` out / redirect stdout to a host file. Always
+redirect output to a host file when >~80 lines — container stdout can be truncated.