3 điểm bởi GN⁺ 2025-10-12 | 2 bình luận | Chia sẻ qua WhatsApp
  • Tanglednền tảng cộng tác Git có tính năng xã hội dựa trên AT Protocol, được thiết kế để lập trình viên vẫn giữ quyền sở hữu hoàn toàn với mã nguồn của mình, đồng thời cho phép cộng đồng mã nguồn mở vận hành một cách tự chủ
  • Áp dụng cấu trúc cộng tác mã nguồn phân tán kết hợp ưu điểm của mô hình liên hợp lấy ActivityPub(Forgejo) làm trung tâm và mô hình P2P hoàn toàn của Radicle
  • Khái niệm cốt lõi “Knot” là một máy chủ Git headless nhẹ, hỗ trợ cả self-hosting cá nhân lẫn môi trường multi-tenant ở quy mô cộng đồng
  • App View(tangled.sh) cung cấp góc nhìn hợp nhất cho các kho lưu trữ trên toàn mạng, giúp duyệt, sao chép và đóng góp một cách liền mạch vào các repository nằm trên những Knot khác nhau
  • Hiện đang ở giai đoạn beta, nền tảng lấy quyền sở hữu dữ liệu, rào cản gia nhập thấp và bảo toàn trải nghiệm người dùng làm các nguyên tắc cốt lõi, đồng thời hướng tới việc xây dựng một hệ sinh thái Git phân tán hoàn toàn và mở trong tương lai

Tổng quan về Tangled

  • Tangled là một nền tảng mới cung cấp môi trường cộng tác Git có thể tương tác xã hội, đồng thời giúp lập trình viên giữ quyền sở hữu đối với mã nguồn và danh tính của mình
  • Dựa trên AT Protocol, nền tảng này áp dụng kiến trúc ứng dụng xã hội phi tập trung vào cộng tác Git
  • Mục tiêu là đưa việc cộng tác mã nguồn trở lại thành một quá trình cởi mở và thú vị

Mô hình phân tán và AT Protocol

  • Các mô hình cộng tác mã nguồn phân tán hiện có gồm những cách tiếp cận sau
    • Forgejo(ActivityPub): cộng tác thông qua liên hợp (federation) giữa các máy chủ
    • Radicle: cấu trúc P2P(peer-to-peer) hoàn chỉnh
  • Tangled kết hợp ưu điểm của cả hai mô hình và chọn atproto để có thể quản lý danh tính theo cách tập trung
  • Nhờ đó, người dùng vẫn có thể duy trì ID và cấu trúc xác thực nhất quán ngay cả trong mạng phân tán

Cấu trúc Knot

  • Knot là thành phần cốt lõi của Tangled, một máy chủ nhẹ cho phép người dùng trực tiếp host repository Git
    • Hỗ trợ cả cấu hình single-tenant lẫn multi-tenant
    • Có thể self-hosting ngay cả trên thiết bị nhỏ như Raspberry Pi
  • Tangled về cơ bản cung cấp dịch vụ Knot được quản lý miễn phí
  • Nhờ cấu trúc này, một mạng Git phân tán kết nối tự nhiên giữa máy chủ cá nhân của người dùng và máy chủ cộng đồng được hình thành

App View và mạng hợp nhất

  • App View được cung cấp tại tangled.sh đóng vai trò hiển thị các repository trên toàn bộ mạng dưới dạng một góc nhìn hợp nhất
  • Người dùng có thể dễ dàng clonecontribute ngay cả với các repository nằm trên Knot khác
  • Thiết kế này giữ nguyên quy trình làm việc vốn có của Git, đồng thời loại bỏ rào cản của môi trường phân tán

Nguyên tắc phát triển

  • Để định hướng phát triển, nhóm Tangled đặt ra ba nguyên tắc sau
    • 1. Quyền sở hữu dữ liệu — mọi người dùng trực tiếp sở hữu mã nguồn và metadata do mình tạo ra
    • 2. Rào cản gia nhập thấp — cung cấp cấu trúc và giao diện đơn giản để bất kỳ ai cũng có thể dễ dàng tham gia
    • 3. Tính nhất quán của trải nghiệm người dùng — dù là cấu trúc phân tán, vẫn đảm bảo UX ở mức dịch vụ tập trung
  • Các nguyên tắc này được phản ánh xuyên suốt trong lựa chọn công nghệ cũng như thiết kế UI/UX của Tangled

Truy cập và cộng đồng

  • Ban đầu, nền tảng hoạt động theo hình thức truy cập bằng lời mời (invite-only), và các lập trình viên có thể tham gia qua kênh IRC #tangled (libera.chat)
  • Hiện tại, hệ thống đã mở đăng nhập công khai, và bất kỳ ai cũng có thể sử dụng tại tangled.sh/login
  • Tangled vẫn đang ở giai đoạn đầu, nhưng đang phát triển bằng cách kiểm chứng tính năng thông qua việc tự sử dụng nội bộ (dogfooding)

Kết luận

  • Tangled là một nỗ lực mở rộng cộng tác Git thành trải nghiệm được kết nối như mạng xã hội
  • Nền tảng này đang thu hút sự chú ý như một hệ sinh thái Git phân tán mới kết hợp tính tự chủ, khả năng tiếp cận và văn hóa phát triển thú vị

2 bình luận

 
lamanus 2025-10-12

Vì không có container chính thức nên phần thiết lập ban đầu hơi rườm rà.

 
GN⁺ 2025-10-12
Ý kiến trên Hacker News
  • Là đồng sáng lập của Tangled, gần đây khi thay thế thư viện OAuth đã phát sinh vấn đề khiến người dùng mới không được thêm vào knot và spindle mặc định (máy chủ git hosting nội bộ và CI runner), vừa áp dụng bản vá nên chỉ cần đăng xuất rồi đăng nhập lại là có thể tạo repository bình thường, nếu có câu hỏi thì tôi sẵn sàng trả lời bất cứ lúc nào
    • Câu hỏi đầu tiên là liệu có thể đổi handle hoặc xóa tài khoản trên PDS của tngl.sh hay không; câu hỏi thứ hai là cần những tài nguyên nào để tạo và vận hành một AppView mới, ví dụ nếu làm một AppView dựa trên PDS theo kiểu chỉ tải lên thư mục website tĩnh như Cloudflare Pages rồi phục vụ nguyên trạng thì liệu người vận hành AppView có phải gánh toàn bộ chi phí traffic lớn hay không, muốn biết gánh nặng vận hành trong cấu trúc như vậy sẽ ra sao
    • Tangled dùng cách diễn đạt “social-enabled”, có vẻ liên quan đến AT Protocol; tôi muốn biết liệu Tangled có dự định bổ sung thêm nhiều tính năng mạng xã hội trong tương lai hay chỉ đơn giản có nghĩa là hỗ trợ AT Protocol
  • Tôi thấy dự án này thực sự rất tuyệt, tôi thích nỗ lực phá vỡ cấu trúc độc quyền của các dịch vụ code forge hiện nay; lý do tôi quan tâm lĩnh vực này là vì cảm thấy code forge đang cố giải quyết quá nhiều vấn đề cùng lúc nên lại trở nên kém hiệu quả; phần lớn forge gộp git repository, web viewer, công cụ cộng tác, pipeline CI/CD, quản lý công việc và nhiều chức năng khác vào một chỗ; nhưng tôi nghĩ những thứ này không nhất thiết phải bị buộc thành một khối, ví dụ nếu không cần truy cập trực tiếp vào git storage thì có thể cung cấp một web viewer hoàn toàn tĩnh như https://pgit.pico.sh, còn cộng tác thì có thể có một máy chủ riêng để chia patch, review và quản lý cục bộ (https://pr.pico.sh); chỉ cần đưa bare git repository lên VPS là đủ, mà việc đó rất dễ; Git vốn đã là một hệ thống phân tán, nên việc lại bị tập trung hóa vì các dịch vụ phụ trợ là một phản mẫu
    • Mọi người hay nói rằng “Git vốn đã phân tán”, nhưng trên thực tế khái niệm phân tán ở đây vẫn khá mơ hồ; bản thân Git không tập trung mạnh vào phân tán mà thường dựa trên giao thức kiểu master-slave (HTTP chẳng hạn), nên cuối cùng vẫn có xu hướng lặp lại sự tập trung hóa
    • Khi có nhiều dịch vụ thì sẽ nảy sinh vấn đề niềm tin; cần cân nhắc giữa việc thẩm định một dịch vụ duy nhất đáp ứng 80% nhu cầu hay xác minh 10 dịch vụ riêng lẻ; ngoài ra cũng không thể bỏ qua lợi thế về quy mô hạ tầng và những điểm cộng khi tích hợp nhiều chức năng, vì thế đến nay vẫn có nhiều người thích mô hình monolith; đây chính là bài toán đánh đổi về trải nghiệm nhà phát triển
    • Việc thiết lập git remote trên VPS thực sự rất dễ, chỉ cần truy cập bằng ssh là chạy ngay; thực ra vấn đề cốt lõi theo tôi là 'lock-in' (sự phụ thuộc vào dịch vụ); tại sao Github và các dịch vụ tương tự lại tập trung vào lock-in hơn là bản thân dịch vụ? Đằng sau đó là câu chuyện gọi vốn và mô hình kinh doanh; vòng lặp tập trung hóa → lock-in → doanh thu cứ lặp đi lặp lại ở nhiều dịch vụ; nếu không có cấu trúc tạo doanh thu từ chính dịch vụ thì hiện tượng này dường như khó tránh khỏi
    • Xét về mặt kỹ thuật thì không phải không thể tách chức năng ra, nhưng còn có vấn đề về tính kinh tế (mỗi chức năng không tạo ra doanh thu đủ để được duy trì riêng) và tính tiện dụng (mọi người muốn sự tiện lợi kiểu 'batteries included'); mã nguồn mở cũng vậy, có nhiều trường hợp phớt lờ tính kinh tế, nhưng cuối cùng phần lớn đều biến mất khi một người bảo trì không thể tiếp tục nữa; ngay cả những dự án mã nguồn mở thành công nhất cũng đa phần được chống lưng bởi nhà tài trợ doanh nghiệp hoặc các kỹ sư hỗ trợ
    • Không phải là bắt buộc phải tách ra, nhưng đúng là tích hợp sẵn thì tiện hơn rất nhiều
  • Gần đây tôi biết tin hỗ trợ Jujutsu tại JJ Con, có thể xem thêm tại https://blog.tangled.org/stacking
    • Dịch vụ này thực sự hỗ trợ stacked PR, điều mà Github đã không làm được suốt hàng chục năm; nếu cần dùng riêng tư trong nội bộ thì hơi tiếc là chưa rõ cách cấu hình để một instance Tangled không kết nối ra mạng ngoài
  • Tôi nghĩ Github giờ không còn đáng tin nữa; ít nhất với stack OSS, chuyển sang AT Protocol hoặc một mạng mở khác là cách tốt để tránh rủi ro từ các tập đoàn lớn, kiểm duyệt và những yếu tố tương tự; tôi rất mừng khi thấy những nỗ lực như thế này
    • Nhưng đa số mọi người không muốn tự vận hành máy chủ; có lẽ chỉ những tổ chức OSS lớn mới gánh nổi; thậm chí ngoài email ra thì còn khó cung cấp cả PR
  • Tôi là một trong 100 người đầu tiên đăng ký tangled; lộ trình review PR theo kiểu stacked patch và tốc độ cải tiến tính năng đã gây ấn tượng mạnh với tôi, tôi cũng cảm nhận được năng lượng tích cực từ cộng đồng; tôi rất mong chờ xem nó sẽ phát triển thế nào trong tương lai; nếu tiếp tục tiến lên đều đặn theo hướng này thì tôi nghĩ hoàn toàn có thể đạt được trải nghiệm tốt hơn nhiều, quyền kiểm soát căn bản hơn và tính bền vững dài hạn
  • Tôi rất quan tâm đến cách cộng tác git mang tính phân tán hơn; theo bạn, trở ngại lớn nhất để cách làm này lan rộng là gì? Là vận hành máy chủ, quản lý khóa riêng, hay cuối cùng vẫn là hiệu ứng mạng?
    • Rào cản lớn nhất là spam, nội dung bất hợp pháp và vấn đề kiểm duyệt nói chung; vì PDS có thể nằm trên bất kỳ domain nào và một PDS có thể chứa số lượng người dùng không giới hạn nên rất dễ dẫn đến trải nghiệm mất niềm tin; nếu mọi người đẩy đầy ebook hay TV show vào git repo thì phải xử lý thế nào, hoặc nếu một dự án bị tấn công spam vì lý do chính trị thì cũng là một bài toán; điểm hay của khái niệm AppView là, giống BlueSky, một đội ngũ kiểm duyệt trung tâm có thể áp dụng chính sách nhất quán; ai cũng có thể đăng bất cứ gì, nhưng cuối cùng frontend vẫn có thể chọn lọc hiển thị; tuy vậy, các quyết định kiểm duyệt tập trung cũng luôn gây tranh cãi; đó là lý do tôi không muốn gánh toàn bộ chi phí và trách nhiệm của một mạng hoàn toàn phân tán; tính mở của AT Protocol là ưu điểm so với các dịch vụ như Twitter, nhưng đổi lại vẫn cần một hệ thống tập trung cho việc quản trị thường nhật và phân quyền; cá nhân tôi hiện khá tò mò liệu có ai sẵn sàng tình nguyện vận hành một radicle seed node “thoáng” (cho phép tải git ẩn danh) hay không
    • Github miễn phí, còn phân tán hóa thì tốn tiền
    • Tôi rất hài lòng vì Tangled cho phép dùng git một cách độc lập mà không cần tự vận hành máy chủ; nhược điểm lớn nhất là dịch vụ này vẫn còn quá mới; hiện chưa có độ nhận biết đại chúng, và cũng còn nhiều người không biết Bsky và PDS cung cấp điều gì; sẽ tốt hơn nếu có thêm tính năng và các alternate client; dù vậy tôi vẫn nghĩ người dùng sớm đã có trải nghiệm đủ tốt rồi, và đang chờ đến ngày nhiều lập trình viên hơn được trải nghiệm điều này
  • Tôi mừng vì có hỗ trợ pipeline CI, nhưng hơi tiếc vì hình thức của nó có vẻ giống GitHub Actions; tôi không nghĩ việc mô tả thực thi tuần tự đơn giản bằng YAML là cần thiết, bash script cũng đủ; YAML cho pipeline chỉ thực sự có ý nghĩa khi dùng để biểu diễn phụ thuộc (DAG) chứ không phải luồng chương trình; Buildkite làm điểm này tốt hơn nhiều
  • Ngày mai có lẽ sẽ xuất hiện một nền tảng kinh doanh no-code tên là “Spaghetti”, cùng một dịch vụ két lưu trữ dữ liệu quan trọng tên là “Lock-in”
  • Ở công ty tôi bắt buộc phải dùng GitHub public org, vậy có thể review code (CR) trên tangled rồi đồng bộ sang Github sau không, và liệu có giữ được nguyên trải nghiệm review với công cụ jj không?
  • Tôi muốn biết liệu có thể triển khai Tangled cho mục đích enterprise/private hay không; quy trình review stacked diff có vẻ rất hợp với công việc doanh nghiệp
    • Có khả năng, hiện đang bàn về một phiên bản Tangled hoàn toàn airgapped và tách khỏi AT; đây là việc khá lớn nên khó triển khai ngay
    • Hiện vẫn chưa có một giải pháp doanh nghiệp riêng biệt thật sự rõ ràng; có thể xem thảo luận issue liên quan tại https://tangled.org/@tangled.org/core/issues/60