作者彙整: Toomore Chiang

關於「Toomore Chiang」

一些可能會變成長篇大論的寫作地方。

與「匿名支付」相關的關鍵字整理

發佈留言

匿名網路社群目前缺「匿名支付」領域的實作或場景應用，整理後續需要投入研究的關鍵字，有些關鍵字之前就聽過了，有一些看過但好奇在 web3 是要解決什麼問題，有一些是都沒聽過，要從頭開始了解。多了一些感興趣的領域可以投入！

「匿名支付」這個主題應該會是 2026 年主要研究的重點之一，最後預計可以有一個指引、手冊的方式呈現，可能還是要聲明洗錢的疑慮問題。

基礎

  • Data privacy / 資料隱私
  • Confidentiality / 機密性
  • Anonymity / 匿名性
  • Pseudonymity / 假名制
  • On-chain / Off-chain privacy
  • Metadata privacy / 中介資料隱私（行為、時間點、關聯圖譜等）

密碼學

  • Zero‑Knowledge Proofs（ZKP, 零知識證明）
  • zk‑SNARK / zk‑STARK
  • Homomorphic Encryption / 同態加密
  • MPC（Multi‑Party Computation，多方安全計算）
  • FHE（Fully Homomorphic Encryption，全同態加密）
  • TEEs（Trusted Execution Environments，可信執行環境）
  • Differential Privacy / 差分隱私
  • Mixnet / Mixer（混幣、混合網路）
  • Stealth Address / 匿蹤地址
  • Ring Signatures / 環簽章
  • Confidential Transactions / 機密交易
  • Programmable privacy / 可程式化隱私

使用情境

  • Anonymous payments / 匿名支付
  • Private DeFi / 隱私型 DeFi
  • Private voting / 私密投票、匿名治理
  • Private identity / 隱私身份、選擇性揭露（selective disclosure）
  • Compliance‑friendly privacy / 合規隱私（在隱私與監管間權衡）

隱私風險

  • Deanonymization / 去匿名化
  • Linkability / 可鏈結性（地址或行為能否被關聯）
  • Transaction graph analysis / 交易圖譜分析
  • On‑chain surveillance / 鏈上監控
  • Privacy leakage / 隱私洩漏
  • Side‑channel leakage / 旁道攻擊、側信道洩漏（從性能、結構或行為洩露資訊）

區塊鏈協議

  • Privacy coin / 隱私幣（例如：Zcash、Monero 等）
  • Privacy‑preserving smart contracts / 隱私保護智慧合約
  • Shielded transactions / 隱匿交易
  • Layer 2 privacy / 隱私型 L2、私有 rollup
  • Private set intersection / 私有集合交集（常用於隱私計算場景）

以太坊為何是 DeFiPunk 的主場？從財庫政策看 Cypherpunk 精神落地（Ethereum Privacy Stack, Devconnect ARG）

發佈留言
Ethereum is for DefiPunk ― Hsiao-Wei Wang (Ethereum Foundation)

在 Devconnect ARG 的「Ethereum Privacy Stack」議程軌中，這場題目為「Ethereum is for DefiPunk」，由以太坊執行董事 Hsiao-Wei Wang 所帶來的議程。

Hsiao-Wei 將「DeFiPunk」定義為：把 Cypherpunk（密碼龐克）的價值觀套用到 DeFi（去中心化金融） 的精神，也就是打造一個在 DeFi 世界中，仍然堅持隱私、無許可、開源協作與使用者主權的生態。

她認為，這條路是以太坊未來應該走的方向。為了在實際運作上對齊這些價值，以太坊基金會（Ethereum Foundation, EF）在 6 月發布了一份財庫政策文件（Treasury Policy），說明基金會會如何依據這套政策來配置與管理資產，包括微觀層級政策（micro-policy）與再平衡（rebalancing）機制，以確保財務策略與以太坊的核心價值一致。

EF 希望以「永續財庫」的方式來管理資金，一方面確保自身財務穩健，另一方面利用這些資源，長期支持以太坊生態系的健康發展，而不是只是追逐短期的財務報酬。

在實際投資與支持的方向上，財庫政策強調要支持：

  • 最高程度安全的、去中心化的、開源的、具 Cypherpunk 精神的應用
  • 理想中的 DeFi 協議應該是：信任最小化（trust-minimized）、可組合（composable）、重視隱私（privacy-friendly），並且投資的是長期價值，而非單純財務上漲空間。

她也點出現實困境：在今天的 DeFi 生態中，要做到「真正的 Cypherpunk、DeFiPunk 風格」往往成本很高，特別是隱私工具的使用成本。設計協議時會有很多「捷徑」，容易導致中心化傾向，因此目前許多自稱去中心化的專案，其實內部有大量中心化元素。

以下是針對 Hsiao-Wei 演講中提到的 DeFiPunk 作額外的整理，在 Treasury Policy 中有明確的定義。

什麼是 DeFiPunk Criteria？

Ethereum is for DefiPunk ― Hsiao-Wei Wang (Ethereum Foundation)

在這份 Treasury Policy 中，所謂的 DeFiPunk Criteria，是指 EF 在運用財庫資產時，會用來判斷某個協議、資產「值不值得支持或持有」的一套價值導向標準，而不是單純看「報酬率高不高」。

核心是：財庫運用要能同時賺取合理收益，又不背離以太坊的 cypherpunk / DeFiPunk 價值觀。

去中心化與信任最小化（Decentralization & Maximally-Trustless）

  • 是否有明顯的「單一控制點」：協議是否依賴中心化營運方、管理者多簽、可單方面升級合約？
  • 治理與權限設計：升級權、凍結權、參數調整權分散在多方，還是集中在少數人？
  • 信任假設：使用者需要「相信團隊不作惡」的程度有多高？邏輯是否主要寫在合約（code is law），而非 off‑chain 承諾？

EF 傾向支持信任最小化、權限分散、可審計的協議，而不是「一按按鈕就能改規則」的假 DeFi。

安全性與韌性（Security & Robustness）

  • 有沒有經過嚴謹的 程式碼審計（audit）？是否開源、可供社群審視？
  • 智能合約設計是否盡量簡潔，減少複雜度與攻擊面？
  • 對極端市場、黑天鵝事件有沒有防護機制（清算機制、風險參數、保險或安全模組等）？

EF 的 Treasury Policy 明確把「安全性與資產保全」放在首要考量。

隱私友善與 Cypherpunk 精神（Privacy & Cypherpunk Ethos）

  • 協議對隱私的態度：有沒有保護使用者交易或頭寸資訊的設計？是否避免不必要的資料收集、追蹤？
  • 是否符合 Cypherpunk / DeFiPunk 的價值觀：幫助使用者在敵對、壓迫環境下保有金融主權與抗審查能力？不配合任意凍結資產、黑名單式審查，除非在非常嚴格、透明的規則下？

這點是 EF 特別強調的：不是只玩 DeFi，而是要做「對弱勢使用者有實質保護力的 DeFi」

無許可、開源協作（Permissionless & Open Source Collaboration）

  • 是否無許可（permissionless）：任何人都能自由使用協議，不需 KYC、白名單或由中心化方批准？
  • 是否開源（open source）：主要合約與前端程式碼是否公開？是否鼓勵其他協議基於其進行二次開發、整合（可組合性 composability）？

EF 把這些當作 DeFiPunk 的基本條件：沒有開源與無許可，很難談 cypherpunk。

對齊以太坊長期發展（Alignment with Ethereum’s Long-Term Health）

  • 協議是否：建立在以太坊或其 L2 上，強化 Ethereum 的網路效應？有助於提高以太坊的安全性、流動性、基礎設施成熟度？
  • 是否會製造系統性風險：高槓桿、脆弱的清算機制、過度集中風險等，會不會拖累整個生態？

Treasury Policy 強調：EF 是「生態系的長期管家」，投資要能增強而不是削弱以太坊的長期健康。

財務面：永續、風險可控，而非只拼高收益（Sustainability over Yield-Chasing）

追求的是「風險調整後的合理收益」，而不是最高 APY（年化收益率）。不會為了多幾個 % 收益，去承擔：過度中心化對手方風險、不透明結構性商品、無法評估的合約風險。

財庫要能長期運作（sustainable treasury），支撐多年開發與資助，而不是短線操作。

議程影片

Ethereum is for DefiPunk ― Hsiao-Wei Wang (Ethereum Foundation)
Ethereum is for DefiPunk ― Hsiao-Wei Wang (Ethereum Foundation)

透明之外的安全：Tor 思維如何改變以太坊的隱私設計（Ethereum Privacy Stack, Devconnect ARG）

發佈留言
Devconnect ARG 2025
Onionizing Ethereum ― Vitalik Buterin (Ethereum Foundation), Roger Dingledine (Tor), 2025/11/22 11:30-12:00

在 Devconnect ARG 的「Ethereum Privacy Stack」議程軌中，這場題目為「Onionizing Ethereum1」的對談，由以太坊共同創辦人 Vitalik Buterin 與 Tor 專案共同創辦人 Roger Dingledine 一起討論「隱私」、「去中心化」與「基礎設施控制權」之間的關係，特別放在以太坊與 Tor 這兩個網路層、協議層專案如何互相借鏡。

Vitalik 一方面談到以太坊目前面臨的結構性風險：隨著華爾街大型機構（如：BlackRock）透過現貨 ETF 與公司財報持有愈來愈多 ETH，以太坊的所有權與治理影響力逐漸集中到少數金融機構手中，可能動搖它原本「去中心化、無許可、抗審查」的核心價值。

另一方面，Roger 則從 Tor 的角度出發，說明過去十多年在匿名通訊、流量保護與抗監控方面的經驗：早期只要使用 Tor 就已經算是高標準的隱私保護，但今天僅有「傳輸層隱私」已經不夠，因為網路與應用層攻擊、流量分析、以及大規模監控的技術都大幅進步，必須把隱私視為系統設計一開始就要考量的核心，而不是事後補強。

整場談話的主軸，是把「Onion（洋蔥式分層）」的概念從通訊匿名（Tor）擴展到以太坊的整個技術範疇2：從網路連線、節點運行、交易廣播、到應用介面，如何一層一層地減少可被追蹤與可被控制的節點，讓一般人也能在不犧牲使用體驗的情況下取得強而有力的隱私與抗審查保護。

從「世界電腦」到「隱私優先的世界電腦」

  • 早期以太坊比較聚焦在「可程式化區塊鏈、世界電腦」的能力，隱私多半是事後才想到的議題。
  • 現在社會對監控、人權與數位隱私的關注提高，以太坊社群開始認真面對：「公開鏈上資料＝一切都被永久記錄」，對使用者其實非常不利。
  • 因此需要借鏡像 Tor 這樣的匿名通訊系統，把「隱私」當作設計一開始的核心要素，而不是補丁。

Tor 的經驗：隱私不只是「極權國家」才需要

  • Roger 分享 Tor 多年來的觀察：人們常以為只有「有什麼見不得光的事」才需要匿名，但實際上隱私是基本人權。史諾登揭露稜鏡計畫之後，全世界才驚覺國家級監控的普遍性。
  • Tor 的使用者包含：記者、維權人士、在高風險地區的普通公民、少數族群（例如 LGBTQ 社群）在法規或社會壓力非常大的地方，需要靠 Tor 才能安全溝通、組織行動。

把 Tor 的思維帶進 Ethereum：Onionizing Ethereum

  • 網路層隱私
    • 現在很多區塊鏈節點、錢包與 dApp（分散式應用程式）都直接暴露使用者 IP，讓鏈上的行為可以與真實身分綁在一起。
    • 構想之一：讓節點或錢包預設就走 Tor / onion service，減少把使用者 IP 直接暴露給伺服器或其他節點的情況。
  • 應用層、協議層的隱私標準
    • 設計 dApp 時，要有新的「隱私標準」，例如：盡量避免把個人相關資料直接寫死在鏈上。如果一定要寫入，也要結合密碼學（零知識證明等）來保護細節。
    • 把「不蒐集不必要資料」當成預設，而不是把所有事情都公開。
  • 從「單一使用者」改成「整體生態系」的隱私防護
    • 過去大家談隱私，常停留在使用者端設定（例如自己開 Tor 自己用隱私錢包）。
    • 這場對談更強調：生態系（協議設計者、dApp 開發者、節點營運者）要共同提高隱私標準，讓「安全、私密的使用模式」變成預設值，而不是進階選項。

現實世界的應用場景與案例

區塊鏈與隱私技術不是 geek 玩具，而是真實世界弱勢族群的生存工具

  • 非洲等地的新興使用案例3：人們用加密貨幣與去中心化服務來逃避惡性通膨、資本管制或金融排除。但如果沒有隱私保護，這些使用者反而很容易被政府或其他勢力鎖定。
  • LGBTQ 等少數族群：在法規敵對或社會保守的國家，個人身份一旦被鏈上資料或 IP 關聯，就可能遭受迫害。所以對他們來說，「金融隱私」與「通訊隱私」都不是抽象概念，而是關乎人身安全。

總結

  1. 問題意識
    • 「公開區塊鏈＝預設所有資料永久公開」，可被追蹤和關聯。
    • 在高風險國家、情境，這種「完全透明」會直接危害人權與安全。
  2. Tor 帶來的啟發
    • 隱私應被視為基本人權，而非犯罪工具。
    • 匿名通訊技術已在真實世界拯救許多記者、行動者與少數族群。
  3. Onionizing Ethereum 的核心概念
    • 在網路層：讓節點與使用者透過 Tor / onion services 溝通，避免 IP 暴露。
    • 在協議／應用層：把「少蒐集資料、強預設隱私」納入 dApp 設計原則。擴大使用密碼學工具（例如零知識證明）來在可驗證與隱私間取得平衡。
  4. 從個人設定到系統性設計
    • 不只叫使用者「自己去用 Tor、自己去開隱私錢包」，而是要讓整個 Ethereum 生態系的預設行為就有高標準隱私保護。
  5. 全球與人權視角
    • 對很多地區的普通人、記者、LGBTQ 等群體來說：沒有隱私＝沒有安全。所以把 Tor 式的匿名性帶進 Ethereum，不只是技術升級，而是人權工程。

對談影片

註解

  1. Onionizing Ethereum ― Vitalik Buterin (Ethereum Foundation), Roger Dingledine (Tor), 2025/11/22 11:30-12:00 ↩︎
  2. 在對談到這裡時，有一個很令人振奮的對話，當 Roger 在解釋 onion 的運作時，Vitalik 突然冒出一句：其實以太坊節點也可以將 Tor 包入一起運作，換句話說，Tor Relay 的節點數量就可以瞬間增加！ ↩︎
  3. 提及 RightsCon 2026 舉辦地點目前面臨到的問題 ↩︎

Roc Camera 透過零知識證明（Zero Knowledge Proofs）驗證資訊

發佈留言

在網路上看到一台很酷的相機 Roc Camera，用 Raspberry Pi 4 再加上 3D 列印出來的外殼組裝起來就可以拍照，如果僅止於此，那和一般相機沒什麼差別。這台相機在拍照完後建立零知識證明（Zero Knowledge Proofs）的資訊，未來可以透過他們的 SDK 來驗證相片是否真實、是否被串改過。

作者覺得以前照片可以擔任事實呈現（證據）的重要角色，但是現在越來越多 AI 產出的虛假影像，已經讓拍照真實呈現失去其功能，需要一個驗證的方式來加強。目前這台相機還在 Beta 測試階段，看起來之後也會與 IPFS 整合，拍攝完成的作品直接上到 IPFS 鏈紀錄。

這台相機我覺得可以有其他用途，如果只是用在一般生活拍照，稍微有點可惜。例如這相機是用在特定現場的取證，需要關注在影像的正確性的場景下，這台相機才能發揮他的重要性。

撇除以上軟體的部分，透過 Raspberry Pi 4 建立起來的相機模組，這台看起來不錯，前陣子有考慮要不要來添購一台 3D 列印機，滿想建立一些模組板塊來自建一個機房！

持續關注這個小產品，一台 $399，運送預計 2 ~ 3 週的時間。

Stalwart 開源郵件伺服器即將發佈 1.0 版本，成為第一個實作 JMAP 協議的郵件伺服器

發佈留言

雖然現在已經很少人自架郵件伺服器了，但是一款開源的郵件伺服器軟體 Stalwart 完成了 JMAP 的實作！這篇文章介紹了 Stalwart Labs 一個重大里程碑：完成 JMAP 用於行事曆、聯絡人、地址簿、檔案儲存及分享的完整實作，使 Stalwart 成為首個支援完整 JMAP 協作協議的郵件伺服器。

完整的文章內容： https://stalw.art/blog/jmap-collaboration

  • 新一代協議：JMAP 包括用於行事曆、聯絡人、檔案儲存及分享的新協議，目標取代傳統的 WebDAV 技術如 CalDAV 和 CardDAV，並引入 JSCalendar 和 JSContact 作為 iCalendar 和 vCard 的繼承者。這些新標準提供一致且優雅的生態系統。
  • 舊技術的限制：傳統的 WebDAV 及其延伸技術因 XML 設計的複雜性，導致實施困難且互通性差。iCalendar 和 vCard 的技術負擔也使這些格式難以維護。
  • JMAP 的現代解決方案：JMAP 協議以 JSON 為基礎，透過 HTTPS 提供高效且清晰的 API，用於郵件、行事曆、聯絡人及檔案分享，簡化協作技術實作，提升可讀性與解析效率。這次發佈不僅帶來新功能，更改變了群件協議的設計和實作方式，對開發者和組織而言意味著更簡單、更少的互通性問題，並加速創新。
  • 客戶端支援與生態系統：目前已有幾個專案（如 Mailtemi、Parula 和 OpenCloud）在開發 JMAP 的客戶端實作，預期 JMAP 會快速被採用。
  • 感謝及未來展望：感謝 NLNet 對 JMAP 開發的支持。Stalwart 開發團隊將致力於性能優化和增強功能，目標在未來幾個月內推出正式的 1.0.0 版本，樹立開放且現代化的郵件通信伺服器新標準。

前幾個月有把 Stalwart 架起來，很難想像在此刻架一台郵件伺服器能有多難，但再往前跨一步出去後發現，很多雲端服務如 AWS、DigitalOcean 將 25, 465, 587 連線埠給關閉或不提供 IP 反向解析1（PTR/RDNS），即使架好了也無法與其他郵件伺服器溝通，或許當越來越多人使用 Stalwart 後這個問題有可能會被克服，我很期待可以自己架設郵件伺服器！

  1. 設定 IP 反向解析（PTR/RDNS）有助於驗證發信伺服器的真實身份，提高郵件的可信度並減少被標記為垃圾郵件的風險，確保郵件順利地送達收件者的主要信箱，提升整體郵件的可交付性。 ↩︎

開源自架服務 immich 被 Google 安全瀏覽誤判為「危險」網站

發佈留言

Google 提供一項名為「安全瀏覽（Google Safe Browsing）」的服務，用來檢測網站是否存在惡意軟體、不受歡迎的軟體或從事某種社交工程行為。不過，對於如何判斷網站是否「危險」的細節仍然不太清楚。這導致使用 Google 安全瀏覽服務的瀏覽器（如 Chrome 和 Firefox）會自動警告使用者，除非少數人忽視這樣的警告，否則這些網站幾乎無法被訪問。

而近期一款開源自架的照片、影片管理軟體 immich，因為自家的 Demo 網站被標記為危險，影響到整個網域的使用。immich 解釋如何透過 Google 的申訴管道提出恢復，但恢復之後所產生的頁面也再次被標記危險。結論提到目前像是可自架服務的 NextCloud、n8n、Jellyfin …… 等，都會有這樣發生的可能，對於開源、自架環境是一個潛在的阻礙。

有興趣可以閱讀完整內容：https://immich.app/blog/google-flags-immich-as-dangerous

查了一下 Google Safe Browsing 沒有公開名單讓人查閱哪些網站被放入，只有一個查詢的網站可以使用，雖然我自己不是用 Chrome，但其他使用者以目前 Chrome 的市占率，其影響不容小覷。

這樣的審查模式與臺灣之前討論 RPZ 類似，一樣也是不公佈名單，但 Google 比較麻煩的部分是評判標準不明，然後又常常誤判，申訴後也不知道何時可以恢復，如果真的遇到誤判，還真的不知道該如何面對。

之前作過一個內部系統，也是遇到這樣的問題，想說臨時換一個網域應該可以解決，但又馬上被判定「危險」，最後只能請使用者關閉「安全瀏覽」檢查的功能，還好不是面對外部的使用者，可以這樣一一通知暫時解法使用。

Signal 服務中斷，僅 AWS 一個資料區域故障

發佈留言

在 10/20 15:11（UTC+8），AWS 在 N. Virginia（us-east-1）的資料中心的 DynamoDB 服務無法連線，導致該區許多與 DynamoDB 相關連的服務無法使用。Snapchat、Slack、Perplexity、Canva …… 等一些網路服務因此也受到影響，其中 Signal 也因為這個事件而無法使用。

比較讓我意外的是 Signal 沒有其他區域的備援系統，而第一時間也沒有看到官方提出任何公告目前的狀況如何，最後只能到 reddit 上看看有沒有人提到是什麼狀況。才確認是 AWS 的問題，而僅是一個資料中心的問題。

覺得 Signal 在這次事件後應該要好好思考一下服務韌性的問題，Signal 的使用者可能都有其服務在線 100% 的需求，臨時要找一個替代的服務可能還沒辦法那麼快找到。或許要重新思考去中心化的通訊服務如：Matrix，既能達成端到端加密，也能達成服務的可靠性（也不太一定）。

之前，大家會把 Signal 當作注重隱私、安全的替代品，現在是不是要開始幫 Signal 找他的替代品了？

mkdocs-material on Github Actions

發佈留言
Material for MkDocs 網站截圖
Material for MkDocs 是一個專為 MkDocs 設計的主題，都用來生成美觀且易於瀏覽的靜態文件網站。它結合了現代設計美學和豐富的功能，使得技術文檔不僅易於閱讀，還能夠輕鬆地進行導航和查找內容。這個主題提供了多種自訂選項，支援多語言以及進階搜尋功能，讓使用者能夠快速建立專業級的文件網站。對於開發人員和技術作家來說，Material for MkDocs 不僅提升了文件的可讀性，還大大簡化了文件的維護和展示工作。

滿喜歡用 Material for MkDocs 來產生文件網站，嚴格來說，這是一個建構在 MkDocs 之上的一個樣式套件，只是又加入了滿多設計樣式，相對於原始 MkDocs 來說在文件閱讀排版上更清晰。

以前常用 Sphinx 寫 rst 格式的純文字內容，後來 Markdown 成為主流，延伸出許多靜態網頁套件或是對應 Markdown 轉換其他文件格式的應用。我記得我是在使用 FastAPI、Pydantic 的技術文件注意到為什麼有一套很美的文件產生樣板，使用後就決定採用在當時做的專案，建構文件資訊給予其他貢獻者參與、閱讀。

以往所建立 Material for MkDocs 的文件專案，大部分都會將建立好的靜態網頁上傳到 AWS S3 存放，直接透過 AWS S3 的網站設定或是透過 nginx 路徑轉址合併到原有的網站中（如：/docs）。反而發現從來沒嘗試過直接用 Github Pages 來建立 Material for MkDocs 文件專案。

在 Github Actions 中有三種方式可以實現 Github Pages 的發佈，可以參考這份 yaml 檔案的描述。這裡用的套件管理是 uv。

MkDocs 有整合 Github Pages 的發佈，可以透過 mkdocs gh-deploy 來佈署，直接一行指令就可以完成。

- name: Build MkDocs
  run: |
      uv run mkdocs gh-deploy -b gh-pages -d ./docs

直接將產生出來的靜態檔案 ./docs 內的檔案上傳到 gh-pages 分支的頂層位置。

第二種方式是每次都從 main 建立一個新的分支 gh-pages 然後產生靜態文件後，強迫上傳覆蓋遠端原有的 gh-pages，這樣的方式是只會看到最新的文件提交紀錄。

- name: Build MkDocs
  run: |
      uv run mkdocs build -d ./docs
      git checkout -b gh-pages main
      git add -f ./docs
      git commit -m 'Deploy MkDocs to GitHub Pages'
      git push -f origin gh-pages

第三種方式是用 worktree 的方式將 gh-pages 建立在 ./docs，然後把靜態文件產生到 ./docs 中完成提交與推送。

- name: Build Mkdocs
  run: |
      git worktree add ./docs gh-pages
      rm -rf ./docs/*
      uv run mkdocs build -v -d ./docs
      cd ./docs
      if [ -n "$(git status --porcelain)" ]; then
        git add .
        git commit -a -m 'Deploy on ${{ github.ref_name }} ${{ github.sha }}'
        git push origin HEAD
      else
        echo "No changes to commit."
      fi

歷史紀錄

如果有使用 mkdocs-git-revision-date-localized-plugin 套件，應該會發現每次產生出來的文件建立日期與修改日期都會是一樣的，那是因為 Github Actions 在使用 actions/checkout 的時候不會擷取過往的 git 歷史提交，需要指定參數來提示擷取完整的 git 紀錄。

- uses: actions/checkout@v5
  with:
      fetch-depth: 0

以上，透過三種方式來建立 Material for MkDocs 靜態文件，看起來多行的指令是可以保留一些彈性操作的可能，例如在最後更換 og 預覽圖，當使用免費版本，都只能呈現預設的樣式。

Material for MkDocs 是一個很好快速建立靜態文件或是針對專案類型的說明網站，建立在 Github Pages 上也不用擔心主機安全性或流量問題，覺得這是一個值得投入瞭解與應用的靜態文件套件！

轉折點

發佈留言

最近大概遇到一個我覺得可以代表我自己的「轉折點」事件，算是投入 10 多年的認知被顛覆。

先說結論好了，最後我自己決定直接跳脫、離開這樣的領域，有些人或環境雖然看起來都建立很久的聯繫，但立場與所認知的目標差距越來越遠了，可能就不需要再維護這樣的夥伴關係。

我不懂的事情是、還是有很多人很眷戀「頭銜」這件事情，這其實對我來說是一件非常尷尬的情況，當我在發現你是在建立很多「履歷」或是「發起人」、「頭銜」時，這一類型的人我會避而遠之。因為和這一類型的人講話會感覺到非常的空，沒有一個發自內心的遠大目標，只是針對你說的領域隨意附和而已。

當然還有一些人是深怕自己作過什麼大事而別人不知道似的，一直幫別人前情提要或補充敘述，和這些人溝通會非常的累，有得時候會覺得你其實在浪費大家的時間。

曾經為了證實我的假設，刻意花了多年的時間在找夥伴時設定一些觀察指標，以後來的成效是顯著卓越的，只要避開上述所提及類型的人與他們所衍生的團體，其實就可以找到「值得信賴」與「放心託付」的夥伴。

接下來我必須徹底遠離這個已經走偏的「生態系」，可能這 10 年來的假象會在未來的 1 – 2 年浮現出來，我選擇從外圍的方式來參與，重新建立我所認為的樣態與倡議的方式，說真的，我還以為建立一個「社群」會有多困難，當這件事情走了一遍之後，你會開始懷疑有些「組織」的存在是不是只是為了一個狹隘的目標（說不定也只是一個頭銜）而已。

可能吧，說不定，也可能我說錯了。

Signal Proxy

發佈留言
Signal 首頁截圖

什麼是 Signal？Signal 是一個注重隱私的即時通訊應用程式，提供端對端加密功能，讓使用者在發送訊息或視訊通話時，都能確保通訊的內容是安全加密。

也因為如此，Signal 在一些國家是無法正常使用，但 Signal 基金會提供一個代理伺服器的功能，透過任何人協助建立代理伺服器來協助無法使用的用戶轉介、建立連線。

Signal-TLS-Proxy

官方提供一個 Docker 版本的代理伺服器，需要一個網址、可以開啟 80、443 連線埠的主機。初次啟用的時候要取得 SSL 憑證：

./init-certificate.sh  # 取得憑證
docker compose up --detach  # 啟用代理伺服器

如何設定

在這篇文章中有提到，Signal 應用程式有設定解析 signal.tube 網域，所以可以透過像這樣的網址分享給其他人：

或是手動在應用程式中設定：

  • iOS：點左上角頭像 > 設定 > 隱私權 > 進階 > 代理伺服器 > （點擊後設定）
  • Android：點頭像 > 設定 > 資料與儲存 > 代理伺服器 > （使用設定）

分享

官方給予的建議是留下 #SignalProxy 的標籤，讓大家透過搜尋或是社群媒體的標籤搜尋，找到你有提供代理伺服器的服務，並請對方私訊取得伺服器的連結資訊。但後來大家覺得這樣太麻煩，要處理的訊息會很多，索性就直接把伺服器的資訊直接放置在公開找得到的地方，提供給大家使用。

我自己也有架設一台 Signal 代理伺服器，如同上面的網址。本來一開始伺服器是架設在新加坡（DigitalOcean）的地區，後來發現還真的越來越多人有需求而使用。稍微好奇是哪裡來的連線，就透過 DNS 被查詢的來源區域發現幾乎都是來自烏克蘭、俄羅斯的連線查詢。但直覺告訴我，新加坡的主機離他們實在太遠了，所以我就把這台伺服器移到阿姆斯特丹（DigitalOcean），離大部分的使用者較近的地區。

來自 Cloudflare 的 DNS 查詢次數，一天也有 15K 的查詢紀錄。

雖然 DNS 查詢數量看起來很多，但實際主機 CPU 使用量都不高，傳輸的容量也都沒有超過 DigitalOcean 所附的每月 500GB 傳輸用量，一台最小的機器約每月 $4 美金，也還可以接受的費用。

由於這一台算是第一次架設還不太清楚究竟會有多少人使用，曾經也作過不同地區用同一個網域網址來分散連線，但後來發現一台就足夠用了，只是比較靠近人多的地方的區域。之後可能會找離亞洲地區近一點的地方架設，要不然連去阿姆斯特丹也覺得有點延遲感很重！