> For this guide, we recommend installing Radicle under /usr/local. This will require you to have write permissions to /usr/local/bin and /usr/local/man. You can give yourself these permission by changing ownership of these directories to the current user and group:
Seems kinda weird to chown all that in the install instructions? Or am I the weird one. Edit: This is from the seed guide, the user guide suggests installing to ~/.radicle.
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.
FYI the guide they're quoting is not for the usual installation but for hosting a seed box. Presumably the kind of thing you would spin up on a VPS and not use for anything else.
Yeah, I wonder how much of the long-standing Unix philosophy & consistency is lost by breaking with best practices. autotools seems to be written off by many younger (and non- C) developers and maintainers, but still, it would be good to stick to consistent conventions on that platform.
The author of the install instruction, because "sudo chown -R $(whoami) /usr/local" first gained popularity in how to install Homebrew in macOS.
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.
> first gained popularity in how to install Homebrew in macOS
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].
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.
These days when I collaborate with other developers, we do it all in a git repo that is simply hosted on a VM everyone has ssh access to.
Project management is done in a plan/ directory which has task entries like
1000-add_logout_button.txt
Where 1000 is the priority.
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
This has a bunch of nice consequences. Some of them are:
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
I like the simplicity, but does everyone actually log in to the server and edit the files directly in the same repo, or is the repo exposed over SSH and everyone works in forks on their own machines?
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.
That is a really cool system, thanks for sharing it! I've been looking for a text based way to do project management and this is giving me a bunch of ideas.
Yes. Say Joe just finished the 1000-add_logout_button.txt task and committed it with the following content:
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
I might change the file like this and commit it, so it goes back to Joe and he sees my comment:
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.
/mg
Yep, i use fossil for small to mid customer-projects, documentation, code and task all in one single file, it's just excellent for jobs like that. Personal projects however are all on bitkeeper.
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.
This strikes me as entirely missing the idea of Radicle.
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.
+1. Also GitHub is more than a git storage, it’s a forge [0]: people use it to store their code, manage changes, track issues, publish releases, and so on. That’s what Radicle wants to be.
> What you describe is just Git on top of a generic P2P overlay network
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.
Forgjeo/Gitea support would be nice. I was waiting for Radicle for long but for our self hosting needs we are using Gitead then moved to Forgejo and never looking back.
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.
It's great to collaborate on code in a P2P way. I think in the end, we also need a way to share binaries in a P2P manner using Git (so we can track history with the beloved Git). Maybe it's a good idea to integrate git-annex into this?
Would be great if there was a short video/asciinema/charts or some other short form guide on how you are supposed to use it.
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.
From the linked page here I couldn't find an obvious link through to the docs except by clicking "Install" which dropped me onto the user guides where I found this[1]. It looks like the main page[2] has the site map but I don't know why that top banner isn't on every page.
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.
As far as I understand there is no the why in the faq?
> 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.
The P2P is honestly a bit of a negative because the provision model looks very "default open" - which is not want anyone who wants to own the hosting experience wants.
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.
So, if I understand correctly, you’re not so much concerned about the p2p architecture, rather than the default seeding policy? (You’d prefer that to be selective rather than open by default? )
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.
It seems odd at first until you realise that it's a host setting & a convention, rather than an inherent limitation.
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.
Thank you, I've been looking for a CardDAV server to replace an entire NextCloud install that was used only for that purpose. Serendipity at its finest!
GitHub effectively contributes a significant amount of money and work hours by hosting close to all the open source software for free, including some CI time and the collaboration features. For some projects like Nix that's a really non-trivial system on its own. It's not just the code that counts towards FOSS contributions.
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/
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.