$ 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.
> 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/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://plugins.jetbrains.com/plugin/19664-radicle
https://marketplace.visualstudio.com/items?itemName=radicle-...
As it grows, this type of as system will break down anyways :)
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.
/mgHowever 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.
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.
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]