gsaslis
Joined 11 years ago
Karma
53
Submissions
30
Member since
Jul 7
Recent submissions
Comment · 1 month ago
Comment · 1 month ago
Thank you for noticing. We need to fix that.
Comment · 1 month ago
For the record, that is not what the Zulip announcement wrote. Please don't kick us when we're down.
Comment · 1 month ago
That is the article of the reporter.
I believe the blog post being referred to here is the one linked to in the title (i.e. https://radicle.dev/2026/09/23/disclosure-of-vulnerability-i...)
Comment · 5 months ago
This is a good fit primarily if you want to run a Radicle node that only seeds repos you tell it to. If you want to write code which you publish on Radicle, you need the tool that signs all your work with your private key (of your Radicle identity) - i.e. the `rad` CLI - and running that in a container isn't very useful. (e.g. think about how you'd replace `rad clone`). Having said that, here's a container image I maintain, in case it helps: https://quay.io/repository/radicle_garden/radicle-node
Comment · 5 months ago
In a nutshell, I summarise it like this: I see Open Source Software is a public good. As a public good, it doesn't belong in any proprietary platform, nor should orgs of any kind be in a position to gate keep it. We should rather host it on a public, peer-to-peer network that everyone can have access to.
Comment · 5 months ago
yes, we currently have just the base building blocks (`rad follow` - allowlist / `rad block` - blocklist) for the fancier things to be built on. When you "seed" a repository, by default you seed it only with "followed" scope, which means you would only see issues and "Patches" (our term for PR/MR) from the repo maintainers + other peers you follow (i.e. in your allowlist).
Comment · 5 months ago
Comment · 5 months ago
it's a little of both: on the one hand we're working on CI integrations (through generic webhooks or CI-engine-specific adapters that basically implement the CI engine's API [1]), so you can keep on using your existing CI solution. On the other hand, yes, there is also work towards a new CI engine (Ambient
[2]), which aims to make it safe and secure to run CI on other people's code, which is important when working towards a distributed, community-ran, CI system. We should have more docs regarding the CI story up on radicle.dev in the next week or two.
[1] - https://radicle.network/nodes/index.radicle.garden/rad%3Az3G... , [2] - https://ambient.liw.fi/
Comment · 5 months ago
1. yes, it's in the user guide [1]
2. Git LFS should work, yes. Care to try and report back ? ;) Open a new topic on the Zulip #Support channel [2] if you run into any issues.
[1] - https://radicle.dev/guides/user#4-embracing-the-onion [2] - https://radicle.zulipchat.com/#narrow/channel/369873-Support
Comment · 6 months ago
yes, they're stored in git itself. See https://radicle.dev/guides/protocol#collaborative-objects
Comment · 8 months ago
I didn't think I'd ever be part of any group of 7 people in the world, but today is that day, I guess.
And I know one more of those people already!
5 more to go.
Comment · 1 year ago
It should!
And yet, that's technically not CI.
The whole point we started using automation servers as an integration point was to avoid the "it works on my machine" drama. (Have watched at least 5 seasons of it - they were all painful!).
+1 on running the test harness locally though (where feasible) before triggering the CI server.
Comment · 2 years ago
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? )
Try https://radicle.network/explore and set index.radicle.garden as your search seed.