透明之外的安全：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 美金，也還可以接受的費用。

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

到了旅行的最後

發佈留言

有的時候需要關閉所有對外的聯繫，才有辦法反向聽到自己的聲音 ……

2025/07 中的時候去了一趟東京，其實只是想要找一個地方稍微喘口氣，不太像是出國遊玩的心情。東京、是一個熟悉到不需要地圖引導的地區，就在 Airbnb 上找到一個還不錯的房間就訂下了。

不過這趟短期散步走走，我想用倒著的方式敘述，從離開東京準備回台北的前一天說起。

成田

這個「成田」不是機場的成田，而是在快到機場前一站的地方，去年因為隔天要早點前往機場，不太想從東京市區慌慌張張的搭車到機場，發現「成田」這裡離機場只有一站，如果隔天的班機有點早，這裡滿剛好可以前一天住一晚當作收心調適準備回台北的好地方。

這裡一帶很小，熱鬧的地方也大概只有在車站附近，這裡有二個車站 JR 成田、京成成田。我記得從東京搭過來是搭 JR 線，去機場的時候我反而走去京成電鉄搭，也都順利抵達機場。在離開的時候，我拖著行李走去車站的路上，遇到一個來自歐洲地區的外國人，問我他身後的銀行是不是 Chiba Bank（千葉銀行），想要用信用卡領日圓，但不知道為什麼都失敗。我想了一下，其實我身上也有剩的日圓，本來是打算就直接給他借急用，但他願意用 $50 歐元和我兌換日圓，算了一下剛好也足夠，就換給他了。

現在在日本用行動支付或是信用卡付款已經越來越方便了，我這趟日圓現金還滿少用到的，有些小小店也都可以用 PayPay 支付或是直接說無現金支付。

住的地方

想說只是臨時住一個晚上，可以睡覺的地方就好了，況且上次也來過一次，是一個離車站還好的距離。我喜歡他一樓的交誼廳，用電腦、開會，是一個可以不用太拘束講話音量的地方，這次去住遇到一個韓國人，他的職業是私人司機，是一個很酷的職業，聽起來需要帶著顧客跑來跑去，有點像是導遊的工作吧！他說他接下來要飛去歐洲，那裡有接到一個工作，然後又會到下一個城市後才會回韓國。

我好像也沒去過韓國，總是不知道要怎麼玩韓國？

大概是下午的時候抵達的，天色慢慢暗下來，周圍的人好像也都還沒抵達住宿的地方，所以非常安靜。那時候想說如果都把燈關起來，會變得很暗嗎？會暗到哪種程度到完全看不到的狀態嗎？如果是，可以讓我安靜思考一下嗎？因為這趟短暫的半旅行、半工作在明天就要結束了，我有思考到接下來該怎麼辦嗎？

就這樣，原本以為會很暗而看不清任何東西，隨著窗外的路燈、透過窗戶映入，我就這樣靜靜的坐著、想著，然後拍下這個畫面。

窗外透入的光線，讓房間內保留一點點的明亮。
很特別的一個時刻，安靜的回想這幾天的旅行，也沒有到不想回去，只是想說回去還可以做什麼 ……

雖然是倒著述說這段旅行，這一路上也一直在思考接下來該怎麼安排下半年的計畫，需要一個幅度滿大的調整，重新分配個人的開發能量到新的專案上 ……

而這個專案讓我思考很久，決定完全讓它處在社群的狀態運作，不屬於甚至不緣起任何組織或個人，以一個新的品牌與倡議的主題誕生。

在這個不開燈的房間裡我思考好久，把所有可能發生的情況都預想過一遍，如果發生了什麼狀況，我可以用什麼方式不影響結果的呈現。想了半年後的規劃，想了 2026 一整年可以嘗試的方向，再想想它可能可以背負的責任是什麼？

突然覺得，真的動手參與或是重新發起一個新的專案是一件滿好玩的事情。想起之前大學的時候把社團玩很瘋的那一段時光 ……

恩，如同開頭提到的，我會倒著說著這段旅行，會再努力把內容補上。

重新使用文字紀錄

發佈留言

需要一個可以好好把一件事情的脈絡好好的說清楚的地方，原本有一個 blog 的位置，紀錄了好久一段的時間內容，但又不想要只為了紀錄而存在，或許這裡是一個比較像是筆記的地方 ……

但也因為發生一件滿特別的事情，稍微意識到好像還是要真正擁有內容的所有權才有意義，平台其實說了什麼也都是平台說的算，懶得花時間去爭辯，所以看起來自己架設目前是最好的方法。

恩，我的 Facebook 莫名的被停權。看起來沒有明確的理由回覆，想想還是回到自己經營個人網站的那個時代，反正現在 self-host 的技術門檻越來越低，容器化的技術框架很快就可以把環境用好，再搭配個 Cloudflare 檔一下流量與快取服務，好像就差不多了，或許有時間再來考慮一下備份的問題。

這幾天想想，從 2008 年開始使用 Facebook 到現在，好像還真的累積好多東西在上面，但好像也沒有什麼特別、一定要全部收下來的必要。有的時候會覺得經過這麼久還記得的事情、才是重要或值得的，或是從別人的記憶中來回憶自己參與的部分也滿特別的，所以一次清空其實也不錯，換個地方分享，順便讓寫東西這件事情在比較有質感的地方呈現！

接下來我會慢慢找回過往分享文字的節奏，社群媒體就調整到 Mastodon、X、Bluesky 上面。然後下一目標可能也要來思考怎麼脫離 Google 服務！