Radicle 1.0 – A local-first, P2P alternative to GitHub
radicle.xyz
radicle.xyz
$ sudo chown $(whoami): /usr/local/{bin,man,man/man1}
Also booo for using ~/.radicle instead of ~/.config|local|whatever.
Some quirks and bumps, but the software is good at first impression. I really hope something like this can take off. Needs a good (and somehow trustable/authoritative) searchable index though as that's 90% of what most users want from Github I think.
I do wonder if the protocol could be adopted into something like Forgejo to aid adoption of the P2P idea.
ie:
make
sudo make install
Homebrew assumed it was being installed on a single-user-at-a-time system, and it didn't want the risk of a bug in its ruby scripting being exploited somehow by insisting on running as root, and it chose /usr/local to install to as it was already in the path... all of these are anathema to Linux users.
* A package manager should leave /usr/local alone as its purpose is to host the user's own software, not distributed software (that's /usr) or vendor software (that's /opt)
* A package manager should run as root, or run its install-the-files portion as root, because it should require the user's admin authority _at that time_ to be permitted to install software that will be in the path of _other users of the system_. If the user takes ownership of the system directory instead, then all their other processes can mess with it too, not just the package manager.
The right thing to do is to install to e.g. /opt/homebrew, and then require users to add /opt/homebrew/bin to their own PATH, which is what Homebrew now does. It only did it after Apple fought against them by using System Integrity Protection to prevent users changing the ownership of /usr/local -- for a while Homebrew told users to write "sudo chown ... /usr/local/*" rather than "sudo chown ... /usr/local" to get around that, and that's what we see here.
The right place for this software on Linux is under /opt or /srv, and it should have the equivalent of "sudo make install", where root is required to install the software to the right place (and after installed there, it can't be modified by regular users), and root is _only_ required for that install step, nothing else.
EDIT: I'm unable to reply to the person whose question I answered, but I'd commend the GP for spotting the macOSism, and recommend everybody be alert to these sorts of tells and impedence-mismatches. You can often spot experienced Windows users doing "Windowsisms" in Linux... and vice-versa! You can see people writing Rubyisms in Python, Cisms in Java, and so on. There's a risk that if they don't adopt the appropriate native idioms for the language/environment/OS, they will introduce subtle bugs, sometimes security bugs. Be on the lookout for this.
That doesn't really make the argument that it's a macOS user who wrote it though does it? It just makes the argument that it was potentially inspired by Homebrew, which has existed on Linux for half a decade.
I didn't really read the rest of your spiel in detail. I asked why you have an opinion about a person I didn't ask for a breakdown of package management and software installation best practices for the last few decades.
> ForgeFed is a federation protocol for software forges and code collaboration tools for the software development lifecycle and ecosystem. This includes repository hosting websites, issue trackers, code review applications, and more. ForgeFed provides a common substrate for people to create interoperable code collaboration websites and applications.
It's based on ActivityPub [1], the same protocol that powers Mastodon [2], Lemmy [3], and Pixelfed [4].
Radicle is an open source, peer-to-peer code collaboration stack built on Git - https://news.ycombinator.com/item?id=40166736 - April 2024 (53 comments)
Radicle: Peer-to-Peer Collaboration with Git - https://news.ycombinator.com/item?id=39868504 - March 2024 (10 comments)
How Radicle Works Under the Hood - https://news.ycombinator.com/item?id=39837117 - March 2024 (16 comments)
Radicle: Sovereign code forge built on Git hits v1.0 - https://news.ycombinator.com/item?id=39829736 - March 2024 (3 comments)
Radicle: Open-Source, Peer-to-Peer, GitHub Alternative - https://news.ycombinator.com/item?id=39600810 - March 2024 (284 comments)
Understanding Peer-to-Peer Git Forges with Radicle - https://news.ycombinator.com/item?id=25322584 - Dec 2020 (14 comments)
Radicle: A peer-to-peer alternative to GitHub - https://news.ycombinator.com/item?id=25313010 - Dec 2020 (255 comments)
Radicle-Link: Extending Git with Peer-to-Peer Network Discovery - https://news.ycombinator.com/item?id=24382589 - Sept 2020 (37 comments)
Show HN: Radicle. A decentralized alternative to GitHub built on IPFS - https://news.ycombinator.com/item?id=19591011 - April 2019 (1 comment)
Radicle Architecture - https://news.ycombinator.com/item?id=19511525 - March 2019 (18 comments)
Radicle: A decentralized alternative to GitHub built on IPFS - https://news.ycombinator.com/item?id=19367916 - March 2019 (82 comments)
Is support for NOSTR planned on the roadmap?
Because they have hundreds of relays and with one single identity we can combine git and text publications, as well as combine with the rest of the open ecossystem built around NOSTR.
Right now is OK, just that is makes everyone keep separate key accounts and data.
Project management is done in a plan/ directory which has task entries like
1000-add_logout_button.txt
There is also a directory plan/done/ where tasks go that have been completed. In the plan/done/ directory, the priority gets replaced by the completion date, so it looks like this:
2024-09-04-add_logout_button.txt
Task management does not need any software or logins.
Task management can be done directly in Vim by simply looking into and editing the plan/ directory.
Task history is nicely versioned by git automatically.
All the tooling that comes with bash and git can be used on the plan/ dir. Like finding all tasks that contain the term "rounded corners" in the description is just
grep -r 'rounded corners' plan/ owner: mg
info:
2024-09-03 17:02
I added the logout button. Settled on rounded
corners which we haven't used before but I think
they look good here.
/Joe
owner: Joe
info:
2024-09-03 17:02
I added the logout button. Settled on rounded
corners which we haven't used before but I think
they look good here.
/Joe
2024-09-04 09:10
Fine with the rounded corners. The styles should
go into styles.css instead of the html though.
/mgAs it grows, this type of as system will break down anyways :)
https://plugins.jetbrains.com/plugin/19664-radicle
https://marketplace.visualstudio.com/items?itemName=radicle-...
The first one doesn't really scale beyond a handful of people, since you risk losing work if the same file is being worked on by multiple people. Vim shouting at you that the file you're editing has changed on disk is not good enough.
I can see how this could work with a central repo, though. It does require everyone aligning on the same conventions and workflow, so you likely still need some software to ensure this is done correctly.
Since everybody pulls the changes of the others and sees if something collides with their own changes, its pretty much possible to do it manually. Thats how I started this approach.
It's really just a 0815 git based workflow. Just not for code but for a tasklist.
Meanwhile I wrote a bit of tooling around it. But using it is not at all a must.
https://de.wikipedia.org/wiki/08/15_(Redewendung) (German Wikipedia, there seems to be no English version)
However there are a lot of things that seem more complicated than necessary.
https://radicle.xyz/guides/protocol
I'm reading through the delegate consensus model for branches and I don't see why any of that is necessary. It's encroaching on the P2P that Git already does well, which is who I decide to push and pull from. I think this project could learn a lot from the KeyBase model, which is to just be a transport for Git.
- Nodes in the network should host local Git remotes. In Git you would configure the remote (origin is the conventional default) to be the address of the local Radicle daemon + a public key for the device that owns it + the repository name. Something like `http://localhost:<radicalport>/<device_id>/repository_name`. If the device_id is the local device then it stores the repository internally, otherwise it calls out to the P2P network.
- You can add multiple remotes to a Git repository, so you could have a remote for each copy of the repository on each Radicle device you care to sync with. Git push pull just works.
- You can use the very simple regexp branch protection model that GitHub and friends use on each device. e.g. master in MyRepo on DeviceA only allows pushes from DeviceB. DeviceIDs become the primitive for authentication. Groups of Device IDs become users.
- There is plenty of existing tooling for managing mirroring and syncing on top of Git. What we are missing is a way to securely push and pull between arbitrary devices on the network by cryptographic id. e.g. I'm on my laptop, I want to pull from new-feature4 on my friend's desktop, I know its public key, not its IP address, and I know the branch name, figure it out for me.
- This doesn't mean that the source of truth device has to be online to access the repository. Since there is a single source of truth it can sign any changes, and everyone interested can cache those changes, using the signature to know the refs are legitimate.
What you are saying is basically "why automate things if you can just do them manually". But worse is not better; there is value in having the P2P transport layer work _transparently_. If you intend to force user to manually (or semi-automatically) juggle remotes for every single device on the network, you have already lost.
TL;DR What you describe is just Git on top of a generic P2P overlay network. I'm sure it can be done (and I might even believe it could be enough for some limited use-cases), but it is not Radicle.
That would be the most widely useful functionality, upon which other features can be layered. If the simple functionality can't be used alone, and you have to buy into a more complicated model, then it makes the tool less broadly useful.
Git actually provides a pretty good experience if you have a remote that's always online. I can push and pull branches around to get between all my different devices. GitHub is usually up.
What I would be interested in, is a remote I can host from my house, instead of the cloud. I could leave the public key on my profile and others can checkout the repository.
What exactly are you asking for here? A import/export tool to move all data between the two? AFAIK, both use Git already, so moving the actual code would be trivial and already possible.
Export what? The data stored by git or something else?
That's quite impressive.
It was not clear from the home page what exactly it is and how it works, and I don't really want to read the whole documentation.
For me pesonally Github, Gitlab and Gitea is all about discovery. Their interface is easy to understand, fast to search for repositories and easy to contribute. I am not sure what problem Radicle is solving, other than "reliance on big tech". And it has always been possible to mirror git repos from github and other platforms. You could not mirror issues and CI pipelines, but not sure if Radicle solves that.
The main page[2] seems to be much more useful since it drops you to radicle browser page which is more of showing the actual product as you'd see it in terms of Gitlab/Github.
But I'm just going to say...they really need to drop the blue theming IMO because it's very hard to read and also just...too blue - everything just washes out.
EDIT: Just tried turning off --color-background-default, --color-background-float and --color-foreground-contrast and without changing anything else man does it get so much more readable - black text on white with a pleasant blue high-lighting scheme.
[1] https://radicle.xyz/guides/user
[3] https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z3gqcJUoA...
Naaa just lazy
> Radicle is an alternative for people and organizations who want full control of their data and user experience, without compromising on the social aspects of collaboration platforms.
Since this can be achieved by self-hosting other non p2p solutions I don't see this as a why for the product. I am trying to understand the actual benefit of p2p here that is it.
Sure: you do have to include an identity document, but it didn't give me an overwhelming sense of safety that I couldn't accidentally expose all my private repos to the P2P network.
This looks really nice & polished - love the web ui - but I know there's a pretty active network & community on SSB.
>This seems to work well: the SSB network thrives off of being a group of kind, respectful folks who don't push to each other's master branch. :)
https://github.com/hackergrrl/git-ssb-intro?tab=readme-ov-fi...
Can't imagine that working at any real level of popularity, but maybe that just goes in the "if you have to solve that problem, its a good problem to have" bucket.
The familiar model of "centralised" Git hosts like Github come bundled with their own protocol-specific permissions models. E.g. if you were to imagine a team working from a simple .git directory hosted on a local SMB/whatever LAN share, the permissions model would be file permissions on the networked filesystem.
Blocking users committing to an "owned" branch on SSB would require implementing an ACL-tracking & ownership model attached to namespaces (likely branch prefixes here by convention) - very doable, nothing about the protocol prohibits it architecturally. So if it ever becomes one of those "good problems", it's not an inherently concrete design decision.
[The main use case for this software]
IMHO, this shows the huge dependency of all of the world’s open source software on a single company. (Microsoft, who owns GitHub).
In this context, Radicle - as an alternative way of hosting the world’s OSS - makes a lot of sense to me.
Then you can demand all your money back ; )
But seriously, it would be nice to distribute it. We already have other options coming slowly. The fediverse forges are being worked on and should be available in 2025, like https://forgejo.org/