- Hợp tác mã nguồn mở được đặt trên nhận thức rằng tổ hợp giao thức phân tán chia riêng việc truyền mã và giao tiếp sẽ đáng mong muốn hơn so với cấu trúc phụ thuộc lớn vào một nhà cung cấp duy nhất
- Hợp tác mã ban đầu diễn ra với tổ hợp git và email, sau đó chuyển sang tổ hợp git và website GitHub, rồi tiếp nối với ForgeFed là tổ hợp git và ActivityPub, còn Tangled là tổ hợp git và AT protocol
- Tangled có cấu trúc liên hợp các sự kiện giữa các máy chủ git, gọi mỗi máy chủ là một knot; dù khác máy chủ vẫn hỗ trợ cộng tác kho lưu trữ, fork liên máy chủ, và pull request tới kho lưu trữ nằm trên máy chủ khác
- Với Authenticated Transfer quanh phần mã, hệ thống dùng AT, xử lý cùng lúc issues, pull requests, dòng thời gian sự kiện, follows, stars, đồng thời cũng dùng cho lời mời cộng tác và chia sẻ khóa công khai SSH
- Dù giống với luồng tự vận hành một instance cgit và gửi bản vá qua email, hướng đi này cho thấy nỗ lực thoát khỏi mô hình đơn canh GitHub mà vẫn giữ được tính xã hội và sự thú vị của cộng tác
Sự cần thiết của liên minh forge
- Cấu trúc khiến phần lớn hợp tác mã nguồn mở phụ thuộc vào một nhà cung cấp duy nhất là điều không mong muốn, dựa trên quan điểm rằng giao thức phân tán bền vững hơn các hệ thống tập trung
- Hợp tác mã từ trước tới nay luôn dùng song song hai giao thức, một cho truyền mã, một cho giao tiếp
- Ban đầu là tổ hợp git và email
- Về sau chuyển thành tổ hợp git và website GitHub
- ForgeFed theo đuổi khả năng kết hợp git với ActivityPub
- Tangled đang được xây dựng trên tổ hợp git và AT protocol
- Tangled liên hợp các sự kiện giữa những máy chủ git và gọi mỗi máy chủ là một knot
- Có thể cộng tác trên kho lưu trữ dù nó nằm ở máy chủ nào
- Hỗ trợ fork vượt qua ranh giới máy chủ
- Có thể push vào kho trên máy chủ của mình rồi mở pull request tới kho được lưu trữ trên một máy chủ hoàn toàn khác
- Cách làm này ở nhiều khía cạnh khá giống với luồng tự vận hành instance cgit và gửi bản vá qua email
Vai trò của Tangled
- Tangled dùng AT cho Authenticated Transfer của các sự kiện xoay quanh mã
- Được dùng để truyền các sự kiện như issues và pull requests
- Đồng thời xử lý các tính năng xã hội như dòng thời gian sự kiện, follows, stars
- vouches cũng sẽ sớm được bổ sung
- AT cũng được dùng để mời cộng tác viên và chia sẻ khóa công khai SSH, còn các phần khác vẫn giữ nguyên git hiện có
- Mã nguồn mở cần thoát khỏi mô hình đơn canh như GitHub, đồng thời vẫn phải giữ được tính xã hội và niềm vui của việc cộng tác mã
- tangled alpha
- docs
- source
- discord
- bluesky
- twitter (x)
- feed
1 bình luận
Ý kiến trên Hacker News
Không rõ cái này sẽ tốt hơn Mastodon đến mức nào
Có một tầng lưu trữ độc lập với ứng dụng, ai cũng có thể tự lưu trữ dữ liệu của mình, còn các ứng dụng thì thu thập dữ liệu từ mọi host để hiển thị
Vì vậy về bản chất không có khái niệm defederation kiểu Mastodon
Nếu muốn tìm hiểu thêm thì xem https://overreacted.io/open-social/ và https://overreacted.io/a-social-filesystem/
Tài khoản được lưu trữ trên PDS và bản ghi cũng đi vào đó, nhưng nội dung hiển thị trong ứng dụng do AppView cung cấp bằng cách gom dữ liệu từ nhiều PDS
Vì vậy dù nằm ở PDS nào thì trải nghiệm ứng dụng vẫn giống một dịch vụ tập trung, AppView cũng có thể có nhiều cái và tự host cũng được
Cũng đáng cân nhắc về cái giá của khả năng khám phá gần như toàn cục như hiện nay, nhưng cũng khó xem đây đơn giản là một Mastodon khác
Cứ không đứng về bên nào, hoặc đi theo phía mà mình thấy đúng chẳng phải được sao
Tôi dùng khá tích cực bên atprotocol nên có thể hơi thiên vị, nhưng trải nghiệm với Tangled thật sự rất hài lòng
Đây là thứ gần nhất với hình dung của tôi về một giải pháp thay thế GitHub; tính năng thì đơn giản hơn, nhưng suốt một năm qua nó là dịch vụ social/git chính cho các dự án mã nguồn mở cá nhân của tôi
Tài khoản của tôi là https://tangled.org/did:plc:rnpkyqnmsw4ipey6eotbdnnf
Tôi thích việc social graph quen từ Bluesky được nối tiếp sang đây, giúp cảm nhận trực quan hơn về những con người đứng sau commit, PR và issue, mà đăng nhập cũng tiện vì giống các dịch vụ atproto khác
Gần đây còn có hỗ trợ tích hợp static site, nên rất hợp để host trực tiếp từ repo các website client-side hoặc
index.htmlđơn giảnSpindles đóng vai trò như build system/action; dù tôi không phải fan của Nix, với nhu cầu cần thiết thì nó khá phù hợp
open API cũng rất tốt nên tôi có thể dễ dàng dựng phần render thông tin dựa trên các chuẩn atproto, làm bot và gắn thêm vài tính năng của npmx.dev
Bạn có thể tự vận hành knot (git server) và runner (Spindles), hoặc dùng bản được host sẵn; điểm cốt lõi là lớp social được tách riêng, nên dù git server nằm đâu thì hội thoại về issue hay PR vẫn tiếp diễn trên lớp social chung
Nó chưa hoàn hảo, và chữ alpha trên navbar không phải để trang trí, nhưng với công việc mã nguồn mở thì khả năng cao tôi sẽ tiếp tục dùng
Nhưng tôi vẫn chưa chắc đó có phải nỗi lo hợp lý hay không
Không khí phần bình luận khá tiêu cực, nhưng dù bản thân cũng dè chừng vốn VC, tôi vẫn nghĩ nên khuyến khích cạnh tranh trong lĩnh vực này
Ở thời điểm hiện tại, bắt đầu thứ như thế này theo kiểu bootstrap có vẻ rất khó hoặc gần như bất khả thi; đúng là họ cũng canh khá khéo thời điểm với các bài chỉ trích GitHub đang ở đầu HN hôm qua, nhưng tôi vẫn muốn ủng hộ nỗ lực kiểu này
Mong là nó có thể đạt tới quy mô đủ ý nghĩa
Chỉ nhìn tiêu đề thì tôi thấy kỳ vọng, nhưng vừa biết có vốn VC là loại ngay khỏi danh sách cân nhắc
Nếu phải đưa dự án tâm huyết không kiếm ra tiền của mình lên một nền tảng, tôi muốn chọn nơi ít có khả năng rug pull sau khoảng 5 năm hơn
Dự án có VC thì cuối cùng kiểu gì cũng phải hoàn vốn cho nhà đầu tư, nên tôi nghĩ sớm muộn gì cũng sẽ có rug pull theo cách nào đó
Vì vậy hiện giờ tôi thích dùng những dịch vụ mà mình là khách hàng trả tiền, hoặc kiểu thành viên hợp tác xã, đóng phí định kỳ và có quyền biểu quyết trong quyết định vận hành
Vì vậy từ góc nhìn người dùng, cần biết trước khả năng đó
Tôi không thích những dịch vụ đề cao lý tưởng quá mức trong khi thực tế sắp tới lại là như vậy
Thà cứ thu phí dịch vụ, hoặc nếu thật sự theo đuổi lý tưởng thì hãy bắt đầu như non-profit, hoặc ít nhất phải công khai rõ kế hoạch kiếm tiền
Khó thì rõ ràng rồi, nhưng nhất là nếu hướng tới federation thì chẳng phải nó nên có thể được xây bằng hạ tầng rẻ hơn, chứ không phải cùng mức chi phí hay còn cao hơn sao
Nếu tò mò về mô hình dữ liệu atproto, tôi có viết một bài nhập môn ở https://overreacted.io/a-social-filesystem/
Hơi dài một chút nhưng nó giúp nắm bức tranh tổng thể khá rõ
Đây là bài nhập môn ATProto hay nhất tôi từng thấy cho tới giờ
Không biết có thẻ hay danh sách nào gom các bài viết này lại một chỗ không
Theo tôi thứ cần thiết không phải forge federation mà là một git repo phong phú hơn
Fossil đã đi được gần 90% chặng đường khi tích hợp ticket, forum và wiki thành một phần của kho lưu trữ; khi clone thì tải luôn cả chúng về để xem offline
Bạn có thể viết sẵn câu trả lời khi đang ngồi máy bay, rồi nếu đủ quyền thì đồng bộ ngay hoặc để tới khi kết nối hồi phục sau
Tuy vậy, thay vì hardcode từng loại artifact cụ thể vào VCS, tôi thấy tốt hơn là đặt ứng dụng vào trong repo và để ứng dụng đó quyết định loại artifact nào được cho phép, quy tắc nào sẽ được áp dụng, ai có thể upload/download và vào lúc nào
Forge khi đó chỉ cần thực thi chính sách ấy và render cho người dùng web theo cách mong muốn
Làm vậy thì việc chuyển sang forge khác rốt cuộc cũng chỉ như push repo sang nơi khác
Dạo này tôi đang làm mấy thứ như ticket system hay agent bằng flat files trong git repo, và giờ thấy có lẽ nên mở rộng ý tưởng đó sang cả việc quản lý repo luôn
Có vẻ sẽ rất tuyệt
Vấn đề cốt lõi của các federated solution theo cảm nhận của tôi cuối cùng vẫn là cold start
Nếu tham gia các máy chủ lớn đang có sẵn thì lại ôm về chính vấn đề tập trung hóa mà mình muốn tránh, đổi lại là có mạng lưới lớn ngay từ đầu
Còn nếu tự mở máy chủ thì mạng lưới bằng 0, khả năng được tìm thấy bằng 0, feed trống trơn, lại còn phải thuyết phục các site khác liên hợp với mình hoặc đừng chặn chỉ vì đó là máy chủ một người
Không biết chỉ mình tôi thấy vậy hay là tôi đang hiểu sai federation
Có lẽ đây đơn thuần là vấn đề riêng của Mastodon
Nó được thiết kế để các AppView trung tâm gom những máy chủ riêng lẻ lại, tạo ra một góc nhìn thống nhất như mạng tập trung
Ai cũng có thể tự host AppView
atproto không vận hành theo kiểu mỗi máy chủ là một khu vực nửa biệt lập
Bài https://atproto.com/articles/atproto-for-distsys-engineers giải thích khá tốt dưới góc nhìn hệ phân tán
Nếu một máy chủ lớn trở nên đáng ngờ vì moderation, chính sách, nội dung hay vấn đề kỹ thuật, thì bạn có thể tương đối dễ rời đi để phát triển hoặc chuyển sang một máy chủ lớn khác
Tức là vẫn có thể tạo ra nơi trú ẩn với mức độ uy tín và quy mô nhất định ngay từ đầu
Đã có các forge thay thế như GitLab, Codeberg, freedesktop, Fedora, Debian, nên chỉ cần giữ được tính hiển thị và khả năng được tìm thấy của dự án thì đó đã là nơi trú ẩn đủ an toàn
Nhưng mấy ngày trước thấy dự án này thì lại nghĩ cái này có thể thật sự làm được
Vì nhóm người dùng mục tiêu chồng lấn khá nhiều với những người đã quen self-hosting
Không cần cả mạng lưới của tôi đều lên đây; chỉ cần cái tập con vốn thực sự có khả năng dùng nó cũng đã đủ hữu ích rồi
Chi phí cho máy chủ frontend sẽ rất thấp nên có vẻ gần như có thể vận hành vĩnh viễn, còn dữ liệu thực tế thì do các host khác cung cấp
Việc Tangled được VC hậu thuẫn khiến tôi cảm thấy đó là áp lực bắt buộc phải tăng trưởng, hơn là cảm giác yên tâm
Tôi không thấy nó hấp dẫn ở điểm nào
Dù có federated đi nữa, nếu việc phát triển dừng lại thì ai sẽ là người sửa bug và duy trì nó đây
Tức là mọi thứ phải có thể tái tạo hoàn toàn và self-host với chi phí tối thiểu
Vốn VC chỉ là phương tiện chứ không phải mục đích; với hai nhà sáng lập là người Ấn đang ở châu Âu, các khoản trợ cấp trên thực tế mất từ 4 đến hơn 12 tháng mới giải ngân nên gần như không thực tế
Con đường nhanh nhất để lập đội, dựng hạ tầng và tăng tốc phát triển là VC, và họ đã cố gắng căn chỉnh mục tiêu rất chặt với nhà đầu tư, thậm chí mất hơn 6 tháng để tìm được đối tác như vậy
Tangled có nhiều lựa chọn kiến trúc thú vị, nhưng bản thân code thì tương đối đơn giản; theo những gì tôi đã xem, độ khó bảo trì không cao
Phần lớn là các Go modules liên kết lỏng lẻo, kèm static HTML+CSS, một ít TypeScript và Nix để điều phối
Nếu tôi nhớ không nhầm thì yêu cầu phần cứng cũng rất nhỏ, ở quy mô hiện tại một cá nhân cũng có thể tự host
Phần lớn gánh nặng hạ tầng thực tế nằm ở knots, spindles, PDS của người dùng và toàn bộ atproto
Vì sao nhất thiết phải là VC, tại sao không nhận tài trợ doanh nghiệp như Ladybird
Và khi nhà đầu tư kỳ vọng lợi nhuận gấp 10 lần, thì tại sao tôi phải bỏ thời gian cho một công cụ dành cho lập trình viên mà sau này kiểu gì cũng sẽ bị enshittification
Tôi nhớ tới câu đùa rằng khi đã có 4 tiêu chuẩn mà lại muốn thống nhất bằng cách tạo thêm 1 tiêu chuẩn mới thì cuối cùng sẽ có 5 tiêu chuẩn
Đùa là vậy, nhưng tôi vẫn nghĩ cần một lập luận mạnh hơn về việc vì sao ActivityPub là chưa đủ
Trước khi lại đi giải bài toán giao tiếp phi tập trung theo một cách khác nữa
Đem hai cái này đối đầu với nhau cũng giống như hỏi đã có email rồi thì cần gì web nữa
ActivityPub giống email ở chỗ máy chủ đóng vai trò hộp thư đến và gửi thông điệp cho nhau
Ngược lại, atproto giống web ở chỗ kho lưu trữ của người dùng host dữ liệu, còn ứng dụng thì gom dữ liệu từ các kho đó để hiển thị
Khác biệt về topology này tạo ra khác biệt về tính chất: với atproto, trải nghiệm ứng dụng không bị đứt đoạn ngay cả khi người dùng đổi nơi host, và bất kỳ ai cũng có thể tạo ứng dụng mới dựa trên dữ liệu sẵn có
ActivityPub không cho phép điều đó; cuối cùng nó gần với mô hình những dịch vụ tập trung nhỏ, nơi hosting và ứng dụng bị gắn chặt với nhau rồi trao đổi thông điệp qua lại
Cũng có https://gitworkshop.dev/ như một lựa chọn thay GitHub khá trưởng thành chạy trên Nostr
Ý tưởng cốt lõi là repo có thể được đưa lên nhiều nostr relay tương thích GRASP, nên nếu một máy chủ gặp sự cố thì vẫn có thể đồng bộ minh bạch qua nơi khác
Vì vậy nếu chọn được các máy chủ đáng tin thì gần như có thể đạt mức uptime sát 100%, đồng thời repo, hoạt động, issue v.v. cũng đều được ký bằng mật mã
Ngay từ cái tên đã có vẻ vi phạm chính sách nhãn hiệu của git
https://git-scm.com/about/trademark
Có cái thì báo trình duyệt không hỗ trợ URL ssh hay https, có cái chỉ hiện
Failed to load file treerồi loading vô hạnNên tôi không thấy thuyết phục lắm với đánh giá fairly mature
Tôi rất ủng hộ federation, nhưng từ trước tới giờ vẫn khó hiểu công dụng của federation of forges
Rốt cuộc các forge cần trao đổi loại dữ liệu gì với nhau
Tại sao một forge cho Blender lại phải kết nối với một forge cho Ubuntu
Giá trị lớn nhất tôi nhận được từ GitHub là đăng nhập dùng chung, nên tôi nghĩ ngay cả các forge độc lập nếu chỉ hỗ trợ social login mà không cần federation phức tạp giữa các forge thì cũng đã mang lại phần lớn giá trị đó rồi
Nếu tự host forge thì trừ khi đã là cái tên lớn như Blender, còn không sẽ chẳng ai tìm thấy phần mềm đó
Vì thế nếu không muốn code biến mất vào hư không thì gần như bắt buộc phải mirror lên GitHub
Muốn tránh điều này và để các forge nhỏ hơn có thể cạnh tranh như một tập hợp thống nhất, cần có một mạng lưới duy nhất giúp tìm thấy phần mềm bất kể nó nằm ở host nào, và ForgeFed đang nhắm tới đúng điều đó
Nó cũng giảm bớt ma sát khi bắt người đóng góp mới phải tạo tài khoản riêng cho từng forge; đó là vấn đề phụ nhưng cũng có liên quan
GitHub chỉ là nơi giải quyết tốt UI, issue, PR để cả người mới cũng làm việc qua giao diện được, và trong quá trình đó nó trở thành trung tâm hóa
Federation gần với triết lý của Git hơn, nhưng không nhất thiết phải đi tới mức phân tán cực đoan nơi chỉ cần một node tắt là upstream biến mất hoặc thậm chí không còn tìm ra được
Git không giải quyết được bài toán tính sẵn sàng, còn federation có thể bổ sung điểm đó mà vẫn giữ được tinh thần phi tập trung
Cần có cách để dễ dàng tìm thấy các dự án mã nguồn mở nằm rải rác trên nhiều máy chủ
Tìm kiếm dự án trên GitHub chỉ có tác dụng bên trong GitHub
Ngoài ra nó còn giúp hệ thống resilient hơn khi host của dự án biến mất, đổi chính sách hoặc bị chính phủ chặn
Còn AppView sẽ gom dữ liệu từ nhiều PDS và hiển thị trên một màn hình thống nhất
Nếu tangled.org sau này enshittify thì bạn vẫn có thể tiếp tục dùng y hệt ở bất kỳ AppView nào khác, và bản thân tangled.org không có vị thế đặc quyền
Social login cho các forge độc lập cũng có ích, nhưng cá nhân tôi vẫn thích chỉ phải quản lý một tài khoản hơn, và nhờ AT protocol mà ngay cả khi từng forge riêng lẻ biến mất thì dữ liệu vẫn tiếp tục truy cập được qua AppView khác