241–250 of 299 posts
It's been fascinating watching Radicle evolve over the –what seems to be– last 5 years. I attended the workshop at Protocol Berg 2023 and think they built something really powerful and novel. Perhaps the most exciting aspect is that even the collaborative aspect of the protocol is local-first which means you can submit patches and issues without internet and that your team isn't on HN every time GitHub is having prob…
Earlier quoted context omitted.
> a standard way of storing project management metadata alongside version control data Emphasis mine. Doesn't seem to be it seening as this is yet another home grown issue storage.
Yeah, exactly. Radicle doing it this way, Fossil another - see here why that is a problem: https://xkcd.com/927/
What’s the alternative? That at least N projects cooperate and agree on a common design before they do the implementation? (Then maybe someone can complain about design-by-committee.)
This is not a criticism, and I could be wrong about this, but doesn't the mit license allow anyone to essentially bypass any extra responsibilities provided for in the Apache license? Specifically I'm thinking of the patent license grant provisions. I don't think the MIT license has anything to say about patents.
And if that is the case then why not just license it MIT?
Earlier quoted context omitted.
Thanks but... no thanks, you've missed my point entirely. Why would I want to run peer to peer software built by developers whose security stance starts with curl-bash? Would you curl-bash a webserver? an email server? No? Probably even worse for your source code repository then right?
The problems with curl-bash are overblown. You are pretty much exactly as vulnerable running pip install, npm install, or cargo install. Not that curl bash is great, but it's not uniquely horrible when the goal is to run some unvetted code on your machine. If you care about security, you have to either vet the code or trust the source. When you install through your package manager, you're trusting the maintainers. Wh…
Earlier quoted context omitted.
Indeed. Radicle is "tiny root", a noun, while "radical" is "pertaining to root, root-level, deepest possible", an adjective.
Sorry for nitpicking but "radical" is also used as a noun, particularly when looking for roots of an algebraic expression, as well as in chemistry (free radicals).
But what you can expect from a language that allows one to tape a talk, or to circle back about an ask?
Hi HN. I am the co-founder of the project. If you are interested in how the protocol works under the hood, start here: https://docs.radicle.xyz/ Docs are still WIP though.
also, i'm curious, what kind of adoption were you anticipating (some time ago and now) and did the result align with it?
Earlier quoted context omitted.
Interesting. "fetchFromRadicle" would be insanely cool.
It seems like you can define radicle repos as flake inputs like so: https://gist.github.com/MatrixManAtYrService/b527300542b6fdd... Although maybe this approach is cheating because it's relying on https and not some kind of hash-linked P2P magic (which would definitely require modifying nix to make work). I guess there's something similar to the IPFS gateway going on: somebody is hosting a bridge into radicle space.…
Seems to work for git-remote-hg, anyway:
nix-repl> (builtins.fetchGit { url = "hg::https://www.public-software-group.org/mercurial/lfapi/"; rev = "34366bf575c8c77c8d3b76d32940c1658cb948a4"; }).outPath
"/nix/store/8dwyms22iwy4fq0b1593i34m88jk574j-source"
[0]: https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z3gqcJUoA...
You already have Bittorrent for distributing files P2P. We "just" need an extra layer for discovering new updates/patches so that files can dynamically update/grow. These two problems seem fundamentally decoupled. The "git forge" aspect seems to be another fundamentally separate layer on top of that
Earlier quoted context omitted.
Did it not? I would consider Bittorrent traffic to have a very high risk of being blocked or viewed as suspicious, and as a result almost never gets embedded in other use cases. Even the simple use case of using torrents to have peer-to-peer delivery of software updates has flopped.
It looks like there’s still an Arch Linux BitTorrent tracker; maybe I’m out of touch but I think this is not a very uncommon way of distributing distros (?).
And this has a legacy roughly as long as BitTorrent itself. The fact that BT never established a footing in other use cases (even those where you would think it would be a great solution) is telling.
Earlier quoted context omitted.
Is there nice interop with BitTorrent for those cases, similar to how Git Annex adds large binary support to git? For example, if I use Radicle to version a machine learning project, can I use a Magnet link for multi-GB model files?
You can already use it with git-annex to store binaries using the git-annex-remote-git-aafs[1] special remote. Although I would be careful and make sure you understand what it is doing to your branch namespace. Even though in the worst case it would not save any space over directly committing binaries, they are in orphan branches that can be pruned without rewriting history. But even so, you can just use any number o…