💬 XMPP 與數位基地

(Updated: )
system

This’s a long story… 我來想想看故事要從哪裡說起。

基地建設的構想

最早，我在公司的時候，公司內部有弄私人的通訊軟體 SeaTalk。作為一個 Data Engineer，收發各種 Workflows 的消息也是很正常的：什麼 Task Failed、DQC Failed、SLA Miss 之類的。

在最早的時候，這些訊息真的是滿世界跑：

  • 有的訊息送到 SeatTalk
  • 有的訊息送到 Mattermost
  • 有的是 Dashboard 內部的 Notification
  • 有的只發 Email
  • …

同時，某些基礎建設的功能缺失的（自動調資源等等），後來就手刻了一些 Bot 加入到我的一人群組中。隨著時間過去，這些 Bot 數量開始變多，形成了一種小型生態。

其實不僅僅是工作上。隨著科技公司推出越來越多平台，家人、朋友「常駐」的平台也在改變，現在雖然維持著某些既有的管道。實際上，平台是越來越分散了。

基於這些觀察，我覺得是時候建立一個「數位基地」的東西，就像當初在工作時做的那樣，只是這次更私人化，整體來說大概是這樣的：

  • 同步家人、朋友的訊息到一個私人訊息平台
  • 能處理 Matter 等類似的指令，用來控制智能家具（傳統家電類的洗衣機、烘衣機，興新家電類的掃地機器人）以及控制生產類的 3D Printer、基礎設施類的路由器
  • 能用 AI 搜索 Hacker News 比較有價值的訊息到群組中
  • 串接 Yahoo Finance API 獲得金融資訊，必要還可以透過 IBKR API 直接下單
  • 更重要的是，現在完全可以掛 AI 進群組中（雲端龍蝦）：
    • 所有的指令都已經串接成聊天指令、實際上 AI 能做的事情就大幅增加了
    • 而且，因為是中央訊息控制中心。任何的錯誤，都會「像私訊發到手機上」，就算人在外面，也可以即時遙控（透過聊天命令）
  • 如果有 Network 功能的小模型，專門處理網路訊息搜尋類的任務（避免某些模型偷偷降智，開始胡言亂語；未來還可以避免 UCP 廣告內容入侵）

UCP (Universal Commerce Protocol)

由於 AI 決策存在不確定性，且對 AI 來說，調用腳本的時間成本極低；反之，人類調用腳本的時間成本就高了不少。在這裡，核心的洞見是：同一個指令，對 AI 與人，應該要是同樣方便才對。

這樣的話，即使 AI 出錯，人工介入修正也不會承擔過大的成本。

在 Telegram 的初嘗試

後來，我花一點時間思考，要把這些龐大、可能還有點敏感的資訊集成到哪個平台上？我的候選有 Discord 跟 Telegram。後來，我選擇 Telegram，理由有二：

  • Discord 過於龐大，而 Telegram 更輕巧
  • Discord 的平台規則經歷過巨變（只要他想，他可以隨時改變規則）
  • Telegram 在自由、低監管方面有聲譽

所以，過去幾天，我都在與 Telegram Bot 打交道，Bot 很容易建立，很快就建好兩個機器人，只用來轉傳訊息，模擬機器人間的通訊。

但很快，我發現了一個硬傷：Telegram 不允許 Bot 接收 Bot 的消息

儘管一開始我嘗試使用一個 .jsonl 並且加上 fcntl 來模擬消息同步，接收訊息後，使用 pipe（後來改成 shared memory），但很快我就發現：這之後的維護成本絕對超乎想像。

分散式主權

接著，我就在尋找其他平台。同時也在思考，能不能把資料收回到自己手裡。所以，後來整體想法變成下面這樣：

現狀（碎片化） 目標（數位基地）
訊息散落在各地 單一消息來源
人工查狀態、手動跑腳本 AI Agent 自動化決策與執行
依賴第三方平台規則 分散式主權

因緣際會，我找到 Matrix ，一種分散式的通訊軟體，以及 XMPP（更古老）的通訊協議。然後我先簡單碰了下 Matrix 的客戶端，然後聽 AI 建議，先轉往 XMPP 生態看看。

主要是因為 Matrix 的集中性還是稍微高一點，這引發了我的顧慮。

我選擇使用 prosody 作為伺服器，然後把它掛到 GCP 上，然而中間遇到各種容器化導致的憑證失效的坑（外加我網域已經用在 Github Page 上，所以用子網域來處理。）

經歷各種坑後，這邊我感受 prosody 是未來資料流處理會很麻煩，而且 docker image 的權限處理其實沒有弄的很好（似乎沒有考慮過 podman rootless 情況的等問題，我是 13.0 版），我在那邊東改改 entrypoint.sh，然後再改改 config.cfg.lua。

由於涉入不深，解法可能不是很漂亮，如果你各位有正在用 prosody + podman 導致 LTS 出問題的話，我的做法是像下面這樣。

先由宿主機產生 letsencrypt 憑證：

1
2
3
4
5
6
7
8
9
10
11
# certbot (venv) 初發簽證
sudo certbot certonly --authenticator dns-gandi \
     --dns-gandi-credentials /etc/letsencrypt/gandi.ini \
     -d <yourdomain>

# Or

# certbot (venv) 續簽新證
sudo certbot renew --authenticator dns-gandi \
    --dns-gandi-credentials /etc/letsencrypt/gandi.ini \
    --server https://acme-v02.api.letsencrypt.org/directory

複製憑證進宿主機的目錄（我是放在 prosody/config/certs 對應容器內 /etc/prosody/certs）：

1
2
sudo cp -r -L /etc/letsencrypt/live/<yourdomain>/. \
    ./prosody/config/certs # 對應的容器內位置是 /etc/prosody/certs

然後改權限，因為容器啟動之後，是以 prosody 身份運作，你這邊要確保系統能抓到裡面的憑證：

1
2
3
4
SUDO_USER=$USER
sudo chown -R $SUDO_USER:$SUDO_USER ./prosody/config/certs/
sudo chmod 644 ./prosody/config/certs/*.pem
sudo chmod 755 ./prosody/config/certs/

原版的 entrypoint.sh 是這樣：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#!/bin/bash -e
set -e

# 檢查 data 目錄（預設掛在 /var/lib/prosody）擁有者是誰
data_dir_owner="$(stat -c %u "/var/lib/prosody/")"

# 如果 prosody 不是 data 目錄的 owner
# 就讓 prosody 的 UID 變成 owner 的 UID
if [[ "$(id -u prosody)" != "$data_dir_owner" ]]; then
    # FIXME this fails if owned by root
    usermod -u "$data_dir_owner" prosody
fi

# 讓 prosody 成為 owner
if [[ "$(stat -c %u /var/run/prosody/)" != "$data_dir_owner" ]]; then
    chown "$data_dir_owner" /var/run/prosody/
fi

...

我的想法是，既然你都暴力改 owner 了，那乾脆直接改一改：

1
2
3
4
5
6
7
8
#!/bin/bash -e
set -e

chown -R prosody /etc/prosody/     # 對應宿主機的 config 目錄
chown -R prosody /var/lib/prosody/ # 對應宿主機的 data 目錄
chown -R prosody /var/run/prosody/

...

原始碼的 BUG 註解，應該是這樣的：

1
2
# FIXME this fails if owned by root
usermod -u "$data_dir_owner" prosody

當憑證檔案 xxx.pem 的擁有者是 root 時，被宿主機映射進容器。這一行想要把 prosody 改成 UID=0 就出錯了（因為 UID=0 只能是 root）。

可是我的做法比較粗暴：我直接複製憑證，然後改憑證的 owner，映射進容器後，owner 一律改成 prosody 就可以解。

本地測試，可以使用這些方便的指令：

1
2
3
4
5
6
7
8
# 建立 localhost 的憑證，產生好之後放進宿主機目錄
mkcert localhost "*.localhost" localhost 127.0.0.1

# 啟動 prosody 後，檢查憑證是不是正常
openssl s_client -connect localhost:5222 -starttls xmpp

# 類似 watch 的 podman 看 log 訊息的指令
podman-compose logs -f --tail 30

高整合性的權衡

架設時，能體會到 XMPP 的古老氣味（不是批評，而是彷彿「推開石門後，原始草原映入眼簾」的那種感覺。）

I-330 帶著 D-503 來到保留古代文物的「古宅」（Ancient House），打開了一個隱藏在地板下的密道。兩人沿著幽暗潮濕的地下通道一路前行，最終從綠牆外的地面鑽了出來。— 《我們》葉夫根尼·扎米亞京

但又想到，如果整合性太差，未來數據沒辦法串在一起的話，那「數位基地」就得打「一堆補丁」，那下雨的時候，恐怕就會到處漏水了。

這時 Matrix 的現代性又有點吸引我。

總之，我打算回來架架看 Matrix 再做決定。