271–280 of 299 posts
Earlier quoted context omitted.
I might take your comment more seriously if you a) put your name behind it and b) dropped the “just asking questions bro” shtick when you obviously have some sort of axe to grind with this project.
Good luck with your reasoning skillset
Earlier quoted context omitted.
But that’s not what parent meant. Those things should be embedded in the git repository itself, in some kind of structure below the .git/ directory. That would indeed make the entire OSS ecosystem more resilient. We don’t need a myriad of incompatible git web GUIs, but a standard way of storing project management metadata alongside version control data. GitHub, Gitea, Gitlab, and this project could all store their da…
Nothing should be under .git/ except things owned by git (or at least allowed for in an explicit way like the hook scripts). You would have to either add the features to git itself, or at least add to git the knowledge of and allowance for extra features like that. But not just toss non-git data in .git/ simply because the dir happens to exist.
That is exactly what I'm suggesting.
I'm curious why dual license with both the MIT and Apache licenses. 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…
Contributions to the repo have to abide to both licenses, derivative work gets to choose only one.
Earlier quoted context omitted.
The problem I'd like to see solved is source of truth. It'd be nice if there were a way to sign a repo with an ENS or domain withiut knowing the hash. Another thing is knowing if the commit history has been tampered with without knowing the hash. The reason for needing to not know the hash is for cases like tornado cash. The site and repo was taken down. There's a bunch of people sharing a codebase with differing has…
> The reason for needing to not know the hash is for cases like tornado cash. The site and repo was taken down. There's a bunch of people sharing a codebase with differing hashes, you have no idea which is real or altered. > This is also important for cases where the domain is hacked. I think at some point you need to know some sort of root-of-trust to kick off the trusting process. I believe in this case, you would…
A bit of a naiive general question, but why are these things not layered on top of existing technology? 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
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.
Are you planning on adding native support for this to git?
Earlier quoted context omitted.
That's not quite right, we solved this in Radicle. Each change in ownership (adding/removing maintainers) is signed by the previous set of owners. You can therefore trace the changes in ownership starting from the original set, which is bound to the Repository ID.
How do you know the repository id is the correct one? You have just changed the requirement from knowing the maintainers public key, to knowing a different public key. Sounds pretty much the same problem to me.
Earlier quoted context omitted.
That's not quite right, we solved this in Radicle. Each change in ownership (adding/removing maintainers) is signed by the previous set of owners. You can therefore trace the changes in ownership starting from the original set, which is bound to the Repository ID.
It's seems to me that for security reasons it might be a good idea to support separate signing keys for normal commits and commits that change the ownership set. This would allow you to keep the ownership change keys offline under the assumption they are rarely used. This is something PoS cryptocurrencies tend to do by having a separate withdrawal key for accessing stake to the signing key used for block proposals, a…
Earlier quoted context omitted.
And Fossil is an entirely different VCS. 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.)
Yes! That's exactly what I would like to see - come together as a working group, create a PR on git itself, and implement standard support for issues, PRs, discussions, projects, votings, project websites, what-have-you. The community will take it from there. The alternative to that would be the git project itself coming up with an implementation. They have reasonable experience working with the Kernel, and the creat…
Without such a group you might just send a few emails to mailing list, get shrugs about how that plan “looks good” with little real interest, and then have to discuss this big plan in every future patch series that incrementally builds such a thing into Git itself. Mostly why such code should be incorporated and how it will pay off when it’s all ready.
The Git tool itself—and the project by extension—is per now very unopinioated about whole-project solutions like this. The workflow that they themselves use is very loosely coupled and pretty much needs bespoke scripting by individual contributors, which I guess is telling in itself.
Earlier quoted context omitted.
Granted, you've found the one (and only?) notable exception to the "no legitimate torrent use cases" rule that I can think of. :) 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.
Blizzard used BitTorrent for distributing full games, patches and trailers for years. https://wowpedia.fandom.com/wiki/Blizzard_Downloader
Windows Update also allows the user to opt in to use a non-bittorrent protocol for peer-to-peer delivery of updates to other Windows users. But of course, it's not true Bittorrent.