- Radicle Heartwood là bản triển khai thứ ba của Radicle Protocol, cung cấp một stack cộng tác và phát hành mã theo mô hình ngang hàng mà không cần code forge tập trung
- Kho lưu trữ bao gồm công cụ dòng lệnh
rad dành cho lập trình viên và network daemon radicle-node
- Được thiết kế để thay thế các code forge như GitHub và GitLab, với mục tiêu cốt lõi là bảo mật và phi tập trung, đồng thời giữ vững chủ quyền của người dùng
- Môi trường cài đặt yêu cầu Linux hoặc hệ điều hành họ Unix, Git 2.34 trở lên, và OpenSSH 9.1 trở lên có kèm
ssh-agent
- Hỗ trợ cả cài đặt bằng binary lẫn từ mã nguồn Rust, nhưng email phản hồi sẽ được tự động đăng lên kênh Zulip công khai, nên tên và địa chỉ email có thể bị lộ
Những gì Radicle Heartwood cung cấp
- Heartwood là phiên bản lặp thứ ba của Radicle Protocol và là một stack hoàn chỉnh cho cộng tác và phát hành mã theo mô hình ngang hàng
- Kho lưu trữ chứa các thành phần chính cần cho việc triển khai Heartwood
rad: giao diện dòng lệnh thân thiện với người dùngradicle-node: network daemon
- Radicle được thiết kế như một lựa chọn thay thế cho các code forge như GitHub và GitLab
- Mục tiêu là bảo mật, phi tập trung, và gìn giữ chủ quyền cũng như tự do của người dùng
- Thông tin chung có tại Radicle home page
- Có thể trao đổi về dự án qua Zulip chat
- Cách Radicle hoạt động được giải thích chi tiết trong Protocol Guide
Cài đặt và chạy
- Các yêu cầu cài đặt gồm có
- Hệ điều hành nền tảng Linux hoặc Unix
-
Git 2.34 trở lên
- OpenSSH 9.1 trở lên có kèm
ssh-agent
- Cài đặt binary cần
curl và tar, và có thể cài bản phát hành mới nhất bằng lệnh sau
curl -sSf https://radicle.dev/install | sh
- Binary cũng có thể tải từ trang [download](https://radicle.dev/download)
- Để cài từ mã nguồn cần **Rust toolchain**, rồi chạy các lệnh sau trong kho lưu trữ
cargo install --path crates/radicle-cli --force --locked --root ~/.radicle
cargo install --path crates/radicle-node --force --locked --root ~/.radicle
cargo install --path crates/radicle-remote-helper --force --locked --root ~/.radicle
- Cũng có thể cài trực tiếp từ seed node
cargo install --force --locked --root ~/.radicle \
--git https://seed.radicle.dev/z3gqcJUoA1n9HaHKufZs5FCSGazv5.git \
crates/radicle-cli crates/radicle-node crates/radicle-remote-helper
- File **systemd unit** cho node nằm trong thư mục `/systemd` và có thể dùng làm điểm khởi đầu để tùy biến thêm
- Để chạy ở chế độ debug, xem [HACKING.md](https://radicle.network/nodes/iris.radicle.network/rad%3Az3gqcJUoA1n9HaHKufZs5FCSGazv5/tree/HACKING.md)
Phản hồi, đóng góp, giấy phép
- Có thể gửi phản hồi qua
rad issue, Zulip, hoặc feedback@radicle.dev
- Phản hồi gửi qua email sẽ được tự động đăng lên kênh #feedback công khai trên Zulip
- Trong quá trình đăng, header
From sẽ được công khai, thường bao gồm tên và địa chỉ email
- Hướng dẫn đóng góp có trong CONTRIBUTING.md và HACKING.md
- Radicle được phát hành theo các điều khoản của giấy phép MIT và Apache License 2.0
- Chi tiết xem tại LICENSE-APACHE và LICENSE-MIT
1 bình luận
Ý kiến trên Hacker News
Tôi là đồng sáng lập Radicle. Nếu tò mò về cách giao thức hoạt động bên trong, bạn có thể bắt đầu từ tài liệu: https://docs.radicle.xyz/
Tài liệu vẫn đang được viết
Về cơ bản, nếu đây là một ứng dụng chia sẻ tệp P2P, tôi thắc mắc việc lạm dụng được xử lý ở phần nào của giao thức. Nếu không thì tôi không rõ nó khác gì các ứng dụng chia sẻ tệp thế hệ trước như BitTorrent hay Winny, nơi người ta tùy ý chia sẻ nội dung có bản quyền như phim, nhạc, phần mềm. Có vẻ chỉ một số ít người dùng độc hại cũng có thể phá hỏng mọi thứ, và tôi cũng muốn biết liệu có thể tách các mạng “cá nhân” để chắc chắn rằng mình không tham gia vào những thứ bất hợp pháp hay không
Trên Crunchbase có ghi là đã nhận đầu tư 12 triệu USD, nên có lẽ sẽ có kế hoạch kiếm tiền
Với kiểu dự án mà tôi hỗ trợ, điều này có thể là điểm chí mạng. Mã có vẻ viết bằng Rust, nên tôi muốn biết có kế hoạch hỗ trợ MS Windows không. Có thể xem Mac OS là thuộc họ Unix, đúng không? Dù không hỗ trợ Windows chính thức, liệu có thể có bản port MSYS2 không
Bổ sung một chút bối cảnh: tôi không ở vị trí ra quyết định như chọn nhà cung cấp dịch vụ, mà có liên quan đến một tổ chức bán chính phủ đang đưa một cơ sở mã nguồn mở khá lớn lên GitHub. Thỉnh thoảng tôi có cơ hội đề xuất một số ý tưởng, nhưng việc có được chấp nhận hay không không thuộc thẩm quyền của tôi. Tổ chức này có động lực lớn để có khả năng phục hồi, không bị chi phối bởi chính sách của nhà cung cấp tư nhân, đồng thời cũng muốn làm những “điều tốt” như tính bền vững hay khả năng tiếp cận rộng rãi. Là một tổ chức chính phủ châu Âu điển hình, GitHub mâu thuẫn với các chính sách như vậy
Cũng có các cơ quan chính phủ khác phụ trách lưu trữ hoặc hỗ trợ mạng, nhưng họ thiếu năng lực hoặc vẫn mắc kẹt trong cách làm cũ, và thường xuyên rơi vào bẫy do nhà cung cấp đặt ra. Chẳng hạn, một dịch vụ lưu trữ đã áp dụng toàn diện DataBricks mà thậm chí không biết đó là một sản phẩm thương mại mã nguồn đóng. Vì vậy tôi ít kỳ vọng tổ chức đó sẽ tận dụng tốt một giải pháp tự host, và một giải pháp phân tán trông có vẻ phù hợp hơn. Tuy nhiên, công cụ không chạy được trên các môi trường PC phổ biến chính thì không thể dùng được
Tôi cũng tò mò trước đây và hiện tại các bạn kỳ vọng mức độ được chấp nhận đến đâu, và kết quả thực tế có khớp với kỳ vọng đó không
Thật thú vị khi theo dõi Radicle đã tiến hóa như thế nào trong khoảng 5 năm qua. Tôi đã tham dự workshop Protocol Berg 2023, và tôi nghĩ họ đã tạo ra một thứ khá mạnh mẽ và mới mẻ
Điểm đặc biệt thú vị là ngay cả các tính năng cộng tác cũng ưu tiên cục bộ. Không có internet vẫn có thể gửi patch và issue, và mỗi khi GitHub gặp sự cố, cả nhóm không cần phải dán mắt vào HN nữa
Có vẻ là một dự án ổn cho mục đích của nó, nhưng tôi nghĩ bản thân Git vốn đã là mã nguồn mở và P2P rồi. Không cần nhận các tệp nhị phân bằng
sh <(curl), chỉ cần kết nối tới một máy chủ Git khác rồi dùng lệnh Git để trực tiếp lấy mã hoặc merge là đượcThứ Git không có là issue cho mã, wiki, thảo luận, GitHub Pages, và quan trọng nhất là mạng lưới hồ sơ nhà phát triển. Cần một cách để đưa metadata của dự án vào chính
.gitsao cho commit mã nguồn không bị trộn lẫn với wiki hay issue. Có thể dùng các tham chiếu độc lập nhưgit noteshttps://git-scm.com/docs/git-notes
Ví dụ, không có cách nào xác minh kho lưu trữ nhận được bằng
git clonecó đúng là kho lưu trữ tôi đã yêu cầu hay không. Vì vậy phải clone từ một nguồn tin cậy, tức là một máy chủ đã biết. Điều này không phù hợp với P2P thực dụngRadicle giải quyết vấn đề này bằng cách cấp định danh kho lưu trữ ổn định[0] có thể xác minh cục bộ, cho phép các bên không đáng tin cậy cung cấp kho lưu trữ
[0]: https://docs.radicle.xyz/guides/protocol#trust-through-self-...
Trên di động, nếu bấm các nút ở cuối liên kết gốc, bạn có thể thấy các tab theo dõi issue, pull request, v.v.
Tôi nhớ Gerrit ngày trước từng lưu code review trong Git
Tài liệu có ghi rằng “điều quan trọng là chỉ đăng các kho lưu trữ mà bạn sở hữu hoặc là maintainer, và trao đổi với các maintainer khác để tránh tạo các định danh kho lưu trữ trùng lặp”
Tôi từng gặp những người lấy code của tôi rồi đưa lên GitHub, và cũng đã thấy nhiều trường hợp dù trong tài liệu sản phẩm hay UI trung gian có ghi “xin đừng làm X, vì sẽ gây vấn đề cho người dùng khác”, chẳng ai đọc, suy nghĩ hay quan tâm mà cứ lập tức làm X. Vì vậy tôi nghĩ nhiều người sẽ không tuân theo yêu cầu này trong tài liệu; thậm chí trang chủ chỉ hướng dẫn cách push code, còn yêu cầu “quan trọng” này lại nằm trong hướng dẫn người dùng mà hầu như chẳng ai đọc
Rốt cuộc, điều khá đáng lo là một hành vi trông có vẻ hợp lý — cứ push mã nguồn mở đang làm theo hướng dẫn trên trang chủ — theo thời gian có thể làm xáo trộn hoặc gây nhầm lẫn điều gì đó quan trọng do cách giao thức và lưu trữ hoạt động
Trên GitHub, số sao có thể mang lại thêm độ tin cậy; còn trong Radicle, thứ tương ứng là số seed của một kho lưu trữ cụ thể
Thường trong một ngày dùng máy tính, ta thấy hàng chục thông báo/hướng dẫn và cũng dùng hàng chục công cụ. Nếu nghĩ đến thời gian cần để đọc hết tất cả các hướng dẫn đó và đọc kỹ tài liệu của mọi công cụ thì sẽ quá lâu
Vì vậy tốt hơn nhiều là không đọc mà dùng heuristic. Ví dụ, khi đóng một tài liệu có thay đổi chưa lưu, ta biết hộp thoại sẽ hỏi “bỏ thay đổi chứ?”, nên không cần đọc. Đây là điều tốt
Kết luận là cần thiết kế phần mềm dựa trên thực tế rằng mọi người hành xử như vậy. Thường thì có thể làm được. Nếu có ví dụ cụ thể, tôi nghĩ có thể đề xuất giải pháp tốt hơn cách “nhờ họ làm và hy vọng họ đọc”
Chúc mừng ra mắt. Tôi đã theo dõi dự án này và thật sự háo hức khi thấy nó trưởng thành nhiều như vậy. Tôi tò mò cách tốt nhất để chuyển các dự án hiện đang ở GitHub sang là gì. Cũng muốn biết có chế độ mirror nào để thử nghiệm không
cronmỗi giờ kéo từ GitHub rồi push lên Radiclegit pull github mastergit push rad masterTôi tự hỏi các kho lưu trữ này sẽ dễ được phát hiện đến mức nào đối với người dùng phổ thông. Có vẻ không có https://app.radicle.xyz/robots.txt, nên có lẽ các công cụ tìm kiếm được phép lấy dữ liệu, và thực tế khi tìm
site:app.radicle.xyztrên Google và DDG thì có kết quảHiện chúng chưa xuất hiện ở vị trí cao nếu không lọc theo site, nhưng thứ hạng có thể cải thiện
Sẽ rất hay nếu có công cụ hỗ trợ và tích hợp CI. Cuối cùng thì có lẽ sẽ là một vòng lặp kiểu
while true; do wait_repo_update; git pull && ./run_ci.sh; done, nhưng cần một hình thức tốt hơn có thể giới hạn chỉ với các push từ định danh đã tin cậyCuối cùng, cũng cần kho lưu trữ artifact. Tuy nhiên có thể Radicle không cần giải quyết mọi thứ. Đặc biệt, một mạng phân tán để chia sẻ các binary lớn có vẻ sẽ khá nhanh chóng bị dùng vào những mục đích không mong muốn
app.radicle.xyzcó lẽ nên cho phép crawler lập chỉ mục toàn bộ tập kho lưu trữ của mạngTôi mong mọi người định nghĩa rõ “P2P” hoặc cách gọi phổ biến hơn là “phân tán” chính xác nghĩa là gì. Hiện giờ nó đã trở thành một buzzword mơ hồ đến mức có thể được dùng với bất cứ nghĩa nào
Vì vậy, hệ thống P2P là hệ thống mà mọi bên tham gia đều có “quyền hạn ngang nhau trong mạng”. Thường điều đó cũng có nghĩa là tất cả đều chạy cùng một phần mềm
[0]: https://en.wikipedia.org/wiki/Peer-to-peer
Hướng dẫn cài đặt lại là
curl -sSf [https://radicle.xyz/install](<https://radicle.xyz/install>;) | sh, kỳ vọng của tôi lập tức sụp đổ trước thứ rác rưởi curl-bashKiểu cài đặt này là một tín hiệu mạnh của việc phát triển thiếu suy nghĩ. Nếu dự án này nổi lên, tôi có cảm giác sẽ được chứng kiến một thảm họa bảo mật. Hy vọng một ngày nào đó sẽ có một “giải pháp thay thế GitHub P2P mã nguồn mở” không bắt đầu bằng cách cài đặt tệ nhất
Rất nhiều người đã biết rõ rủi ro của trình cài đặt qua pipe. Theo logic đó thì phải vứt bỏ Homebrew [1](hơn 38 nghìn sao GitHub), PiHole [2](hơn 46 nghìn sao), Chef [3], RVM [4] và vô số dự án mã nguồn mở dùng trình cài đặt tự động một bước pipe vào
bashCách phản ứng hợp lý hơn là hợp tác với nhà phát triển để cung cấp phương án cài đặt thay thế trong tài liệu hoặc giải thích rủi ro tốt hơn, chứ không phải kiểu đốt cả nhà để bắt rệp
[1] https://brew.sh/
[2] https://github.com/pi-hole/pi-hole
[3] https://docs.chef.io/chef_install_script/#run-the-install-sc...
[4] https://rvm.io/rvm/install
Về vấn đề truyền tải bị gián đoạn, trừ khi hệ thống của bạn có một lệnh nguy hiểm khớp với
^(t(e(m(p(d(ir?)?)?)?)?|a(r(g(et?)?)?)?)?|i(n(_(p(a(th?)?)?)?|fo?)?)?|s(u(c(c(e(s?s)?)?)?)?)?|f(a(t(al?)?)?)?|m(a(in?)?)?|w(a(rn?)?)?|u(rl?)?), thì script vẫn an toànSau khi xử lý chuyện đó, tôi tự hỏi nó khác gì so với việc chỉ cung cấp script mà không cung cấp lệnh chạy. Nếu muốn xem xét, bạn có thể tải script xuống rồi chạy riêng. Hình như có cách phát hiện script được pipe và script được tải xuống, nhưng có lẽ không hoạt động với một script nhỏ như thế này
[0] https://files.radicle.xyz/latest/
[1] https://app.radicle.xyz/nodes/seed.radicle.garden/rad:z3gqcJ...
Cứ mỗi khi thị trường crypto đi lên là tôi lại nghe nói về Radicle. Có ai dùng nó nghiêm túc không?
Câu này bị downvote ngay lập tức nhỉ. Tôi hỏi nghiêm túc đấy, tôi tò mò không biết Radicle đã tiêu tốn bao nhiêu ngân sách, có bao nhiêu người làm, và ai đang dùng nó
Tôi làm trong ngành crypto và cũng có ấn tượng tương tự. Lần cuối tôi nghe về Radicle là ở đợt tăng giá trước, còn trong thị trường xuống thì im ắng. Ai cũng nói thị trường xuống là thời gian để xây dựng, và Radicle rõ ràng là công cụ dành cho developer, nên chuyện này khá lạ
Tôi tò mò liệu có kế hoạch hỗ trợ use case chỉ cung cấp repository cho một tập hợp node nhất định không. Có lẽ sẽ có những người không muốn ở trên GitHub nhưng vẫn muốn cộng tác riêng tư
Tuy nhiên dữ liệu không được mã hóa khi lưu trữ, nên không thể lưu trên các node trung gian không thuộc tập hợp tin cậy