Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

app.radicle.xyz

Post reply on HN
Print view View original

221–230 of 299 posts

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#221

Post by [deleted] »

k8svet wrote: post #217
__MatrixMan__ wrote: post #214

Earlier quoted context omitted.

It would be neat to define the radicle repo as an input to the flake for a project which used radicle, that way you could add it to the devshell and you'd have pinned the version of radicle to your project such that running "nix flake update" updates that project's version of radicle along with updating its other dependencies (this, among other things, is what having a flake.nix at your repo root makes possible). A w…

Interesting. "fetchFromRadicle" would be insanely cool.

[deleted]

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#222

Post by kamikazechaser »

clemiclemen wrote: post #201
est wrote: post #4

This looks like a fine project for its purpose, but I think git is already open-source and p2p. You don't need sh What's missing in git is code issues, wikis, discussions, github pages and most importantly, a developer profile network. We need a way to embed project metadata into .git itself, so source code commits don't mess up with wikis and issues. Perhaps some independent refs like git notes? https://git-scm.com/…

I think this already exists for issues. git-bug [1] uses git internal files to store the issues. It is distributed and it even comes with a web ui in addition to the usual cli. [1]: https://github.com/MichaelMure/git-bug

A friend of mine wrote a similar tool. https://github.com/nolash/piknik.

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#223

Post by evanharwin »

mdaniel wrote: post #174
zlatan_todoric wrote: post #142

Earlier quoted context omitted.

We are actually working on a number of CI integrations and building our own native one, for our needs.

> building our own native one, for our needs. I realize I'm just some rando on the Internet, but I'm begging you please don't introduce Yet Another CI Job Specification ™ I'm sure you have your favorites, or maybe you hate them all equally and can just have a dartboard but (leaving aside the obvious xkcd joke) unless you're going to then publish a JSON Schema and/or VSCode and/or IJ plugin to edit whatever myst…

Appreciate both the clear feeling and nuanced take here!

It’s interesting, because it’s like the problem is partly that most of the CI offerings out there are at least a little bit gross, but also the vast number of mediocre CI offerings is a factor too.

It feels like it’d be easy to convince yourself that what you’ve built is better than everything that exists already, and hey, maybe it is! But personally I wonder if we really need is a step-change here, not an incremental improvement—something that really does make build and deploy easier, and changes how we all think about it too.

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#224

Post by _flux »

polski-g wrote: post #186
angio wrote: post #73

Earlier quoted context omitted.

If you run their service locally it displays the connected account and you can interact with the app.

Fairly arrogant to assume port 8080 is unused for other things on localhost.

It's just the default, it can be changed.

And it wasn't free on my host me either :). Indeed 8080 is maybe not the best port to select for this app, because it is more likely used than "some other" port.

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#225

Post by mplewis »

always2slow wrote: post #185
zlatan_todoric wrote: post #172

Earlier quoted context omitted.

Here you go [0] - the project hasn't launched yet and there are bits and pieces to be dealt with, the current focus is a bit somewhere else. You can also build from source [1] with Rust's cargo. [0] https://files.radicle.xyz/latest/ [1] https://app.radicle.xyz/nodes/seed.radicle.garden/rad:z3gqcJ...

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?

Yeah, it’s much better to npx something or install a package off the AUR. Definitely much safer.

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#226

Post by mdaniel »

evanharwin wrote: post #223
mdaniel wrote: post #174

Earlier quoted context omitted.

> building our own native one, for our needs. I realize I'm just some rando on the Internet, but I'm begging you please don't introduce Yet Another CI Job Specification ™ I'm sure you have your favorites, or maybe you hate them all equally and can just have a dartboard but (leaving aside the obvious xkcd joke) unless you're going to then publish a JSON Schema and/or VSCode and/or IJ plugin to edit whatever myst…

Appreciate both the clear feeling and nuanced take here! It’s interesting, because it’s like the problem is partly that most of the CI offerings out there are at least a little bit gross, but also the vast number of mediocre CI offerings is a factor too. It feels like it’d be easy to convince yourself that what you’ve built is better than everything that exists already, and hey, maybe it is! But personally I wonder i…

My life experience has been that answering the question is almost always a matter of "easier ... for whom ... to do what?" I think CI/CD systems often run up against the same problem that programming language adoption runs into: trying to be all things to all people for all problem domains is incredibly hard

Even what I mentioned about static typing I'm sure caused a blood-pressure spike in some readers, since some folks value the type safety and others consider it "line noise". Some people enjoy the double-quote free experience of yaml, others pound on their desk about the 7 ways to encode scalars and "but muh norway!!11"

But, taking our ragingly dumbass buildspec friend https://docs.aws.amazon.com/codebuild/latest/userguide/build...> as a concrete example, how in the holy hell did they invent some build language without conditionals?! I'm sure the answer is "well, for our Amazon-centric use case, you're holding it wrong" but for someone coming from GitLab CI and GitHub Actions which both have "skip this job if today is Tuesday" it's a pretty glaring oversight

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#227

Post by creatonez »

computerfriend wrote: post #220
wokwokwok wrote: post #40

Earlier quoted context omitted.

I read the documentation and this stands out to me: > Radicle repositories, which can be either public or private, can accommodate diverse content including source code, documentation, and arbitrary data sets. If this is, basically, a peer-to-peer file sharing application, what part of the protocol handles dealing with abuse? Otherwise, how is this different from the previous generation of file sharing applications (…

Sharing arbitrary copyrighted content did not ruin BitTorrent so I don't see why it would ruin this.

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.

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#228

Post by cloudhead »

doctorpangloss wrote: post #199
alchemist1e9 wrote: post #191

Earlier quoted context omitted.

I’m confused. What does this comment mean?

Let's say you had $12m, with the requirement that it be spent on an "interesting problem." What would you spend it on? These guys picked "distributed source code repositories, with a client idiosyncratically written in Rust and idiosyncratically built with a cryptocurrency idea." Why? I agree it's intellectually stimulating. But besides that, is there a reason they are particularly passionate about distributed source…

It’s simple: I don’t want my code and code collaborators to be using a platform owned and controlled by a third party. Just like I don’t want my OS or text editor, kitchen, furniture, clothing, books or music to be controlled by a third party that can decide to take it away whenever they see fit. Code and open source are integral to my life, as are the other things cited above, and therefore I’m uncomfortable with the idea of using github for the forseable future.

As it happens there are many others like me, and this helps fuel our excitement and drive to get this out there.

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#229

Post by __MatrixMan__ »

k8svet wrote: post #217
__MatrixMan__ wrote: post #214

Earlier quoted context omitted.

It would be neat to define the radicle repo as an input to the flake for a project which used radicle, that way you could add it to the devshell and you'd have pinned the version of radicle to your project such that running "nix flake update" updates that project's version of radicle along with updating its other dependencies (this, among other things, is what having a flake.nix at your repo root makes possible). A w…

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. It would be interesting to get this working without dependency on that bridge.

Anyhow, modify your project's flake accordingly and your version of `rad` will track with that radicle repo. No curl-to-bash required.

Re: Radicle: Open-Source, Peer-to-Peer, GitHub Alternative

#230

Post by bordumb »

mariusor wrote: post #127
cloudhead wrote: post #108

Earlier quoted context omitted.

A CONTRIBUTORS file is easy to change by anyone hosting the repository - it's useless for the purpose of verification, unless you have a toolchain to verify each change to said file. "Sign-offs by maintainers" it not useful either unless you already know who the maintainers are, and you are kept up to date (by a trusted source) when the maintainers change. This is what Radicle does, for free, when you clone a repo.

All good points, but now you moved the trust requirement from me having to trust the people working on the code, to me having to trust the tool that hosts the code. I'm not convinced your model is better. :P

Over time, I’d expect trusting the tool to be more and more trustworthy as more and more eyeballs can review the tool.

Whereas having to trust people, especially as people cycle in and out over time can be inherently stochastic.

Post reply on HN