6 ms·

This looks like a fine project for its purpose, but I think git is already open-source and p2p. You don't need sh<(curl) a bunch of binaries, instead simply con

• e12e 3y ago
  Fossil has a few of these.
• codetrotter 3y ago
  > What's missing in git is code issues, wikis, discussions, github pages and most importantly, a developer profile network. Radicle adds issue tracking and pull requests. Probably some of those other features as well. On mobile there are buttons on the bottom of the screen in the op link, click those and you get to the issue tracking tab and the pull request tabs etc
  • 9dev 3y ago
    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 data in there instead of proprietary databases, making it easy to migrate projects.
    • gsaslis 3y ago
      Yes, this is how radicle stores this data. ; ) https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z3trNYnLWS11cJWC6BbxDs5niGo82/tree/0003-storage-layout.md https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z3trNYnLW...
      • gsaslis 3y ago
        https://docs.radicle.xyz/guides/protocol https://docs.radicle.xyz/guides/protocol is probably a better resource (but this guide is still Work In Progress)
        • est 3y ago
          > Radicle’s predefined COB types are stored under the refs/cobs hierarchy. These are associated with unique namespaces, such as xyz.radicle.issue and xyz.radicle.patch, to prevent naming collisions. This looks like an interesting approach. I have question, to avoid copy a large .git project, we have partial cloning and cloning depth. If `cobs` grows too large, how can we partially clone it? Like select issues by time range?
          • sebastinez 3y ago
            The COB types are located in the Stored Copy, you would still be able to partial clone the working copy repo without the issues and patches, with your current git commands. There is a better explainer here: https://docs.radicle.xyz/guides/protocol#storage-layout https://docs.radicle.xyz/guides/protocol#storage-layout
      • account42 3y ago
        > 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.
        • 9dev 3y ago
          Yeah, exactly. Radicle doing it this way, Fossil another - see here why that is a problem: https://xkcd.com/927/ https://xkcd.com/927/
          • avgcorrection 3y ago
            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.)
    • zlatan_todoric 3y ago
      Radicle does store such data in git - issues, patches (PRs) etc. Also, the entire project (protocol, cli, web ui etc) is fully open source.
    • Brian_K_White 3y ago
      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.
      • 9dev 3y ago
        > You would have to either add the features to git itself, That is exactly what I'm suggesting.
        • Brian_K_White 3y ago
          I don't think I would agree. Well it depends exactly what you imagine. There are probably an infinite and always growing and changing number of repo-adjacent things similar to the handful of added features that github currently tacks on to git. I think it doesn't make sense for git, already complicated enough, to try to do all of that other related stuff, however related. Maybe in fact git is already doing too much meaningful metadata work directly itself, and should instead try to switch it's current metadata into some kind of generic interface that other software could hook in to better? So rather than git managing, say, issues, git just manages data. Not merely a db, it would facilitate associating high level feature data like issues and ci and conversations with low level commit data. An issue tracker would just be one of many clients using the interface. git itself should probably not know very much about the data other than how it is associated to some commit. IE, the actual meaning of the data is either only in the consumer, or perhaps is some agreed standard that multiple consumers adhere to and understand, or perhaps comes with it's own schema definition like dtd or protobuf. Or all of the above, a paid product could have data only it understands, and other software could use standardized data, all stored in git at the same time. Multiple different consumers could use the same generic interface to their own data. Because these add-on related functions are probably not universal or done being invented. Tomorrow there will be 5 new things you want to attach to a repo besides what github provides today, and so without even knowing what they are, that's how I know it's wrong for git to provide the features itself. But managing the data without caring what the data is, that could totally be a new built in git function, where you give git itself one new function and interface, and an open-ended number of new feature-providing consumers all just use the same underlying git feature in whatever way they want. Other than that the only other new thing I think that might be right to add to git itself is a proper way to manage large binary assets.
• viraptor 3y ago
  You're missing the discovery part. You want to get the repository X from user Y cloned - how do you find it? Especially if you don't know Y and their computer is off? Also radicle does want to tackle the issues / prs and other elements you mentioned as well.
  • BlueTemplar 3y ago
    How do you find a website ? And presumably the person hosting it will make sure that the computer hosting it is often on, for instance ISP routers and TV boxes are a good way to popularize it, since they often come with NAS capabilities : https://en.wikipedia.org/wiki/Freebox https://en.wikipedia.org/wiki/Freebox (Notably, it also supports torrents and creating timed links to share files via FTP.)
    • gsaslis 3y ago
      Depends on what you mean by finding : - finding what the domain name is ? - resolving the DNS to an IP address ? Radicle solves both problems in theory, but more the latter than the former right now: - there is some basic functionality to search for projects hosted on Radicle, to find the right repo id (I expect this area will see a lot more activity and improvements in the near future), - given a repo id, actually getting the code onto your laptop. This is where the p2p network comes in, so that the person hosting it doesn't always need to keep their computer/router/tv box on, etc.
• bawolff 3y ago
  > and most importantly, a developer profile network What has the world come to where that is the most important part? -- I think gerrit used to store code reviews in git.
  • blueflow 3y ago
    Welcome to the era of self-promoters and narcissists.
  • IggleSniggle 3y ago
    Repositories and code-sharing are inherently about trust. Even if you personally audit every line of code, you still need to trust that the owner isn't trying to slip one past you. Identity is a key component of trust.
    • vaylian 3y ago
      What you say makes sense. But that trust needs to extend to the hosting platform itself, because the platform can manipulate all non-signed data. I don't see how a GitHub profile by itself is trustworthy. You need some additional, external and independent verification that that GitHub profile is really authentic and doesn't contain compromised code. There is nothing stopping me from creating the accounts IggleSniggle or Iggle5n1ggle on github.
      • chaorace 3y ago
        I mean... yeah, you obviously have to trust someone to vouch for the authenticity of an identity. In the case of Github, that's the platform owner. In the case of a digital signature, that's the root certificate authority. With that being said, your example feels pretty far off the mark. You might be able to phish using a similar looking identity, but that's completely unrelated to the trustworthiness of the platform. It's not as though you'll manage to somehow phish Github into showing someone else's trustworthy work history on a spoofed identity.
        • bawolff 3y ago
• cloudhead 3y ago
  While Git is designed in some way for peer-to-peer interactions, there is no deployment of it that works that way. All deployments use the client-server model because Git lacks functionality to be deployed as-is in a peer-to-peer network. For one, it has no way of verifying that the repository you downloaded after a `git clone` is the one you asked for, which means you need to clone from a trusted source (ie. a known server). This isn't compatible with p2p in any useful way. Radicle solves this by assigning stable identities[0] to repositories that can be verified locally, allowing repositories to be served by untrusted parties. [0]: https://docs.radicle.xyz/guides/protocol#trust-through-self-certification https://docs.radicle.xyz/guides/protocol#trust-through-self-...
  • ianopolous 3y ago
    How do you handle the SHA1 breaks in an untrusted p2p setting?
    • cloudhead 3y ago
      If you mean collision attacks, this shouldn't be a problem with Git, since it uses Hardened SHA-1. Eventually, when Git fully migrates to SHA-2, we will offer that option as well. > Is Hardened SHA-1 vulnerable? > No, SHA-1 hardened with counter-cryptanalysis (see ‘how do I detect the attack’) will detect cryptanalytic collision attacks. In that case it adjusts the SHA-1 computation to result in a safe hash. This means that it will compute the regular SHA-1 hash for files without a collision attack, but produce a special hash for files with a collision attack, where both files will have a different unpredictable hash. From https://shattered.io/ https://shattered.io/
      • ianopolous 3y ago
        So you use hardened sha1 in radicle? It would be great to see this in the docs.
        • cloudhead 3y ago
          Everything that is replicated on the network is stored as a Git object, using the libgit2[0] library. This library uses hardened SHA-1 internally, which is called sha1dc (for "detect collision"). Will add to the docs, good idea! [0]: https://github.com/libgit2/libgit2/blob/ac0f2245510f6c75db1b1e7af7ca01c15dec26bc/src/util/hash/sha1dc/sha1.c#L1745-L1756 https://github.com/libgit2/libgit2/blob/ac0f2245510f6c75db1b...
• Fice 3y ago
  > We need a way to embed project metadata into .git itself, so source code commits don't mess up with wikis and issues. Fossil (https://fossil-scm.org https://fossil-scm.org) embeds issues, wiki etc. into project repository.
  • IggleSniggle 3y ago
    Also Radicle, evidently
• zamalek 3y ago
  Classic git does not evade censorship, such as the extremely recent news concerning Nintendo. An idea like this has been rolling around in my head, and I'm overjoyed that someone has done the hard work.
  • grumbel 3y ago
    Git evades censorship just fine, since it is properly decentralized and doesn't care about where you got the repository from. Plain HTTP transport however does not and most Git repositories are referred to by HTTP URL. If you simply host Git on IPFS you have it properly decentralized without the limits of HTTP. IPNS (DNS of IPFS), which you need to point people to the latest version of your repository, however wasn't working all that reliably last time I tried.
    • pbronez 3y ago
      Yeah that’s been my experience with IPFS. Very cool idea, practically doesn’t work very well. Haven’t tried recently though, maybe it’s improved.
    • kevincox 3y ago
      But with Git you still need to locate an up-to-date source for the repo. If the author is signing commits or you know a desired commit ID then you can verify once you have found a source, but finding the source is the hard part. IIUC with Radicle you can just request the repository by signature and get the latest released version from the network without needing to track down a source yourself. A trusted publisher (probably the original author/maintainer) can continue to publish commits without a centralization point that can be shut down (like the recent Yuzu case).
      • chriswarbo 3y ago
        You're basically describing a name service: a way to associate a stable name (like "Yuzu" or "PGP:ABCDEFG..." or whatever) with a changing, mutable identitfier (like a Git commit ID, an immutable IPFS URL, a Bittorrent magnet link, etc.). The most obvious example is DNS, which is technically capable of this, but is mostly not set up in the ways we'd want. It's pretty centralised: so whilst anyone can host their own DNS servers, serving any data they like, it's unlikely the "main" DNS network will connect to it; and will consider you malicious if your data disagrees with the centralised records. Things like DNSLink can be useful for associating as DNS name with names in other systems, but that's still vulnerable to hijacking/poisoning without an out-of-band way to verify it. The GNU Name System seems better suited, since it can use public keys for stable names, which therefore can't be hijacked/poisoned. Associating these to pet names is also less centralised, feeling more like /etc/hosts than "the" DNS; with recursive resolving, so e.g. I can look up "Yuzu" based on what you think it is, etc. That seems to provide a nice balance between decentralised control, versus relying on side-channels to find public keys. I'm currently experimenting with this. There's also IPNS, but in my experience its lookups are incredibly slow and unreliable. It could get better, and I know various studies are being performed and experiments with different approaches and parameters are being tried, so I'm hopeful something will come of it. As far as I remember, the main reason Radicle diverged from these approaches (and IPFS/IPNS in particular) was to allow peers to negotiate delta transfers, like (non-dumb) Git HTTP servers do. That's more efficient than using something like IPFS/IPNS, where the root address keeps changing, and we need to fetch a load of the Merkle tree to find out which blocks we already have.
• clemiclemen 3y ago
  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 https://github.com/MichaelMure/git-bug
  • colinsane 3y ago
    do you know of any projects using [anything like] git-bug? i know i've encountered something like this once in a notable repo. thought it was graphics related, like mesa or something, but looks like they're using GitLab.
    • oooyay 3y ago
      Most CI runners use git notes which is similar to what git-bug uses iirc
  • kamikazechaser 3y ago
    A friend of mine wrote a similar tool. https://github.com/nolash/piknik https://github.com/nolash/piknik.