從集中式託管轉向基於開放協議的聯邦架構

過去二十年間，程式碼託管平台（Code Forge）主要提供集中式的代管服務，雖然帶來了便利性，但也讓開發者依賴單一供應商的穩定性與功能維護。Tangled 團隊認為這種模式已顯疲態，並指出 Email 與 Git 這類開放協議因其長期穩定性而經受住時間考驗，儘管其使用者體驗較差。

Tangled 試圖結合兩者優點：利用 AT Protocol 的長期存續能力，同時提供現代化託管平台的精緻介面與便利性。該平台被宣稱為首個真正聯邦式的程式碼託管服務，允許使用者在自有伺服器上託管程式碼，並與其他節點的使用者無縫協作。

這種架構採取務實的路線，使用者可以根據需求選擇自架部分元件（例如僅 Git 託管或 CI runners），或是包含 API 伺服器與 UI 的完整堆疊。無論選擇何種配置，都能透過 AT Protocol 與其他節點進行通訊。

重構底層架構以解決延遲問題並提升效能

在這次更新之前，Tangled 的網頁介面與後端是一個名為 appview 的單一 Go 語言單體應用，負責處理 AT Protocol 索引、快取及 UI 渲染。該服務運行於瑞典的一台中型伺服器上的單一 SQLite 資料庫中，這導致距離瑞典較遠的使用者面臨顯著延遲。

為了解決此問題，團隊重新設計了架構，將前端改為使用 Svelte 開發的獨立應用程式，並部署於邊緣節點。後端則引入了一個名為 bobbin 的新服務，這是一個完全基於記憶體、無磁碟依賴的索引器，由 Rust 語言編寫。

bobbin 服務已在全球超過 11 個區域進行部署，旨在確保全球各地的使用者都能獲得最佳的 API 與 UI 效能。值得注意的是，bobbin 僅處理唯讀的 AT Protocol 資料，其他功能則委派給一組新的支援服務處理。

將協作資料直接儲存於 Git 倉庫以確保可攜性

Tangled 引入了新的資料模型，所有記錄均遷移至 org.tangled.* 命名空間下，取代舊有的 sh.tangled.* 記錄。第二版節點伺服器 Knot2 同樣由 Rust 重寫，內建自訂的 Git 伺服器與 SSH 伺服器。

在新架構中，議題、合併請求、評論、反應及標籤等協作資料不再儲存於中央資料庫，而是作為「協作物件」（Collaborative Objects, COBs）直接儲存在節點（Knot）上，緊鄰程式碼本身。COB 本質上是 Git 倉庫內的一串 Git 物件鏈。

這種設計使得節點的行為類似於 AT Protocol 中的個人資料伺服器（PDS），儲存包含完整歷史的簽名記錄，並透過標準的 AT Protocol firehose 進行同步。團隊強調，專案的議題與合併請求應與程式碼共存亡，這樣才能確保專案的最大可攜性，無論使用者選擇在哪裡託管。

為了防止節點擅自修改使用者的記錄，系統引入了 attestation（認證）機制。當使用者在節點上建立或編輯記錄時，網頁應用會同時在使用者自己的 PDS 上寫入一個 org.tangled.graph.attestation 記錄，指向該記錄的特定版本及其背後的 COB 變更，實現雙向驗證。

自架服務的使用者需要將節點升級至 v1.20.0 版本以支援這些新功能。

新增組織帳戶與優化合併請求工作流程

Tangled 正式推出組織帳戶功能。在 Tangled 上，組織是一個真實的 AT Protocol 帳戶，擁有獨立的 DID（去中心化識別符）和 handle，並託管於 Tranquil PDS 實例上。這些帳戶是無密碼且委派式的，使用者可透過新頁面建立組織，獲得 <name>.tngl.sh 的網址，並由建立者作為擁有者管理成員邀請與權限。

如同其他 AT Protocol 帳戶，組織帳戶也可以將預設 handle 替換為使用者擁有的網域。對於之前使用個人帳戶作為組織替代方案的使用者，團隊表示正在開發遷移工具。

合併請求（PR）的流程也經過全面 overhaul。新的流程允許所有使用者，無論是否使用 Jujutsu (JJ) 或標準 Git，都能提交和審查堆疊式合併請求（Stacked PRs）。對於使用標準 Git 的使用者，現在可以在不同版本之間進行差異比較（interdiff）；而 JJ 使用者則可以在個別變更之間進行差異比較。

社群回饋與未來開發計畫

Tangled 共同創辦人 icy 在社群討論中表示，團隊對此次發布感到興奮，因為他們穩定了 AT Protocol lexicons，徹底重構了架構與 UI，並簡化了自架整個堆疊或部分元件的流程。他們也確認組織支援已上線，私有倉庫功能將在未來幾週內推出。

部分使用者對新介面提出具體回饋。用戶 paaloeye 指出，雖然更新後的程式碼審查介面比舊版好很多，但評論區缺乏顯著的「Comment」按鈕是一個嚴重問題，因為 Shift-Enter 被設定為提交動作，這可能導致使用者在不知情的情況下意外關閉合併請求。

用戶 stryan 表示期待 Tangled 的發展，並計劃將自己的專案從自架的 Gitea 遷移至 Tangled，同時保留 GitHub 作為發現管道與備份。他提到需要 git-bug 工具增加對 Tangled 的橋接支援，以便同步議題。

開發者 pksunkara 詢問 lexicon 的最終化是否包含將議題、PR 和評論記錄從使用者範圍移至倉庫範圍，這對於他希望讓自己的程式碼託管平台 juju.bi 與 Tangled 互通並作為節點伺服器運作至關重要。

Tangled 團隊表示發布將分階段進行，接下來幾週將推出私有倉庫、CLI 工具、多語言 SDK 以及針對 AI 代理的技能支援。