Post AkIdXRyBQd8I6wGXRI by icon_of_computational_sin@mstdn.starnix.network
 (DIR) More posts by icon_of_computational_sin@mstdn.starnix.network
 (DIR) Post #AkHLHagdG70eBCNtdA by icon_of_computational_sin@mstdn.starnix.network
       2024-07-25T05:07:58Z
       
       0 likes, 2 repeats
       
       RADICLESome months ago I learned about Radicle, a truly distributed git forge based on a custom gossip protocol similar to SSB. This allows collaborative code development without the use of any centralised nodes altogether, much less ugly monsters like Github.See https://radicle.xyz for more details about the implementation.My experience with itTL;DR it's almost good, but not quite there yet.Longer version.The Good:Initial setup is easy. Generate keys, run a node, seed your repos, clone others. Despite being fully distributed, Radicle still has a notion of repo ownership, implemented via cryptography. Every repo has one or more delegates, whose versions are considered master copies in case of conflicts.Unlike other git forges, everything about the repo is the part of the repo. Ownership information, access permissions, PRs, issues, everything is implemented via git objects. You won't ever need to open a browser to submit a PR. Furthermore, you can do all of this while being completely offline. Your work will automagically synchronise once you get internet connection.For better availability, Radicle has the concept of Seed Nodes. These are (almost) always online nodes with public IPs that donate their disk space and bandwidth for spread others' repos.The bad:Bugs. Bunch of them. This is what you get for using software with versions like 1.0.0-rc14. Sometimes my two nodes fail to connect, citing some cryptic error as a reason. My seed node froze up a few times, no idea why.Radicle is implemented in Rust, which sometimes adds to it peculiarity. It's still better than most Rust software, but logs and errors are cryptic. I'm yet to see a typical Rust stacktrace vomit, though I'm completely prepared for it.The ugly:Since there is no centralised authority, there are no centralised identities. Every node is represented by a public key. Which means, every one of your computers will have separate identity. While you technically can share keys between them, this isn't advised. This ultimately results in requiring some form of key management system, which I'm yet to explore.Private repo support - while being there - is somewhat lacking. Someone with delegate access must list all nodes allowed to receive the repo, including your seed node. In my case, private repos require just three nodes for me alone. For a group larger than one person this might just turn into a nightmare. Have you ever managed SSH access with public key authentication? Similar story.Seed nodes can either seed everything they touch or they can seed a select list of repos. There is no in-between, i.e. follow a select group of nodes and seed their repos only. Or at least, I couldn't find this feature. Which means, whenever you create a new repo and want to share it between devices using your seed node, you must SSH into it and manually add it to the list.Discoverability is almost non-existent. Someone needs to provide you with a hash for repo to clone before you can work on it. Some seed nodes employ a web interface to list repos and browse code, but it's less than ideal. Same goes for discovery peers.
       
 (DIR) Post #AkHMLWNVJsj7vgsLNA by scathach@stereophonic.space
       2024-07-25T05:12:44.160111Z
       
       1 likes, 0 repeats
       
       @icon_of_computational_sin Oh cool
       
 (DIR) Post #AkHpN7TLmqJdw4iyTg by minoru@functional.cafe
       2024-07-25T10:45:05Z
       
       0 likes, 0 repeats
       
       @icon_of_computational_sin I am pleasantly surprised that not all your posts are rants teeming with hatred :)Nice overview! I should probably look into it as well, just in case ForgeFed never realizes its potential.
       
 (DIR) Post #AkHqVVDdTul3r4w2rI by thomask@social.octet-stream.net
       2024-07-25T10:57:49Z
       
       0 likes, 0 repeats
       
       @icon_of_computational_sin When I looked into it, I assumed the lack of discoverability was a feature. I have a feeling that public seed nodes might be less willing to operate if there was an easy to way to discover and clone all the content that they have agreed to host.
       
 (DIR) Post #AkIDfVPNvhPeHhAZua by icon_of_computational_sin@mstdn.starnix.network
       2024-07-25T15:17:21Z
       
       0 likes, 0 repeats
       
       @minoru hey! I'm trying to be positive. Except computers don't make it easy for me and there is always something broken in them.
       
 (DIR) Post #AkIJGXGSUWheWgTGAS by levitte@mastodon.nu
       2024-07-25T16:20:02Z
       
       0 likes, 0 repeats
       
       @icon_of_computational_sinRe discoverability, you can set the policy of your local node to allow everything, then 'rad ls -a' will list every repository that reached you.
       
 (DIR) Post #AkIdXRyBQd8I6wGXRI by icon_of_computational_sin@mstdn.starnix.network
       2024-07-25T20:07:14Z
       
       0 likes, 0 repeats
       
       @levitte can I allow everything only from a select set of nodes? I.e. i want my seed node to replicate repos from my working machines.
       
 (DIR) Post #AkJvR9oe0Im2P3ueu0 by levitte@mastodon.nu
       2024-07-26T11:02:28Z
       
       0 likes, 0 repeats
       
       @icon_of_computational_sinSounds like you want a closed seeding network. I think that can be done by replacing the default ("preferred") seeds with your own in the config of each involved node.I haven't tested this, though...
       
 (DIR) Post #AkKHJ5OUl3ajMeEphw by icon_of_computational_sin@mstdn.starnix.network
       2024-07-26T15:07:33Z
       
       0 likes, 0 repeats
       
       @levitte did that. i still have to seed every repo manually (rad seed rad:...) from the seed node.
       
 (DIR) Post #AkMHWm6LfnBttpCJEW by levitte@mastodon.nu
       2024-07-27T14:19:24Z
       
       0 likes, 0 repeats
       
       @icon_of_computational_sin Really?  See, I imagined that as long as all nodes only talked with each other, they could have a [permissive seeding setup](https://radicle.xyz/guides/seeder#a-permissive-seeding-policy).  Of course, this is sensitive to "leaks", should someone connect with a public seeding node...  but still.
       
 (DIR) Post #AkMUIr1jrUDCWfjYaO by icst@clubcyberia.co
       2024-07-26T23:19:23.995536Z
       
       0 likes, 0 repeats
       
       @icon_of_computational_sin It sucks that it's buggy and in rust. It would be nice if there were more attempts to make something like this to actually get people away from relying on github and etc. People can say "git is already decentralized" all they want, but there are too many problems with hosting your own repo (or relying on someone else to continue doing so) that inherently push people to centralized slop like github.
       
 (DIR) Post #AkMUIrzeGk8NWTlOy0 by icon_of_computational_sin@mstdn.starnix.network
       2024-07-27T16:42:36Z
       
       0 likes, 0 repeats
       
       @icst i run my own gitea server just fine. Takes 5 minutes to set up, runs fine together with CI and a bunch of other stuff on a 10 euro/mo VPS. Self-hosting these days isn't nearly a problem.The main problem is collaboration. Currently, I have accounts on almost two dozen giteas and gitlabs, most of them I had to create just to send a stray bug report or a minor PR. This just doesn't scale due to the sheer fact of how annoying it is.