•  infeeeee   ( @infeeeee@lemm.ee ) 
    link
    fedilink
    29
    edit-2
    4 months ago

    The most important questions about any p2p service:

    • why would anyone store my data?
    • why would I store someone else’s data?
    • how can i be sure that someone else’s data is not CSAM: i found the answer you can select what repos to sync

    It seems to me it’s IPFS again, but now for git repos. And it has the same problems as IPFS

    •  shrugal   ( @shrugal@lemm.ee ) 
      link
      fedilink
      18
      edit-2
      4 months ago

      I believe the thinking should be the other way around.

      No one wants to store your code, and you shouldn’t store anybody’s code either. But suppose you have a group of people who want to collaborate on (or just mirror) a codebase, so they already decided to store it on their machines. This project gives them a decentralized tool to coordinate their efforts, and their code/issues/patches will be stored and accessible as long as they are interested in it.

      Like, the tool doesn’t give you a reason to use it, but if you have a reason then here is a tool to help you.

    •  Clot   ( @clot27@lemm.ee ) 
      link
      fedilink
      6
      edit-2
      4 months ago

      Same question. P2p was initially used to pirate stuff e.g. movies which isn’t a private property and streaming that through p2p made a lot of sense. But for codes I don’t know if its appropriate or not…

      • There were other similar initiatives where everything is encrypted, so you cannot be sure what others store on your node. For torrent you can select what torrent you download and share.

        I was thinking about Storj, where you get “money” for hosting other people’s content in a similar p2p fashion. For Storj the answer to the first 2 questions are money, but you can’t answer the third, because encryption. (“Money” is not real money but some strange crypto, but that’s not important now.)

        CSAM is just the worst possible example, it’s forbidden in most countries of the world, and no sane people should be ok storing it. The main thing is, if you host other people’s content, can you know what is the content, do you have some word if you want to host it or not.

          • DHT returns an ip based on a hash, what do you mean.

            If you solely rely on DHT for searching for new things to download, than yes, that’s a good way to get unwanted material on your hard disk, I don’t recommend to do that to anybody at the curtent state of the technology. Don’t mix up things deliberately, usually people don’t do that, they get a torrent file or magnet link from a trusted source, than DHT can’t mess it up.

    •  Clot   ( @clot27@lemm.ee ) 
      link
      fedilink
      1
      edit-2
      4 months ago

      Here’s another response I got from someone from radicle regarding this.

      That’s a great Q.

      Radicle can support a federated model, where known major seeds are connected with multiple smaller clusters. >Radicle supports also completely self-sustaining and disconnected clusters of nodes networked between themselves >within that cluster. And of course any other network topography in between.

      There’s a promising active proposal to establish a dedicated new Radworks Organization tasked with solving the >incentivization and reward problem for seeds. https://community.radworks.org/t/discussion-rgp-22-start-the

      Additionally, similar to how one can “star” a repo on GitHub, one can “seed” a repo on Radicle. “Starring” a repo is >often a toast of support, akin to an emoji reaction, with little more effect other than that, but in Radicle “seeding” a >project, goes beyond incrementing a vanity metric: it actively supports propagating that project across the Radicle >network. The count of seedings per repo can also be used as a differentiator between original and “copy-cat” ones.

    • More importantly, why would you want to host code on a few likely-totally-unreliable computers, when you can host on a few servers which are bulletproof with redundancy?

      Github has a SLA of 99.9% uptime reliability lol