Hello, I’m Valmond creator of the Tenfingers sharing protocol & implementation.

To make it more motivating for people to try it out, what should I share to showcase its abilities? It can be rougly anything up to say a gigabyte.

I’m thinking about music, video, parts of wikipedia, …

Legal of course.

Any ideas greatly appreciated.

Cheers & thanks!

  • lime!
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    14 days ago

    if I’m reading this right, it’s a bit like ipfs+dht. is this a content-addressable system?

    anyway, you should probably have demos of

    • large files (like a Linux disk image), to demonstrate consistency in transfer.
    • Video stream, to demonstrate performance and low latency.
    • multiple files shared with many peers at once, to demonstrate scalability
    • sharing with low bandwidth and high latency, to demonstrate possible mobile use cases.

    thoughts:

    • the logo is very close to wireguard’s.
    • if the data is stored on peers, that means there must always be people with free storage online for it to work? how much storage is needed? is that data in plaintext? could a bad actor push illegal content to peers without them knowing?

    also, please convert the whitepaper to a format that is actually readable. rtf? really?

    • Valmond@lemmy.worldOP
      link
      fedilink
      arrow-up
      2
      ·
      14 days ago

      Thanks, good ideas and recommendations!

      The data is overshared, so several nodes store your data (as you store theirs. The storage requirements are roughly your data size times the number of over shares. The number of overshares is confugurable on a per data basis), this makes the availability high.

      The data is encrypted with AES 256 (CTR) so nodes do not know what they are storing.

      It’s hard to invent new logos I guess, at least mine is blue and laying on the side…

      It might feel like IPFS but the underlying tech is completely different, so it’s not a DHT but uses dynamic links, which means that you can update your shared data without the need to re distribute the link file.

      Ha ha point taken, I’ll convert it to a better format.

      • lime!
        link
        fedilink
        English
        arrow-up
        2
        ·
        14 days ago

        i’m interested in the dynamic linking, what mechanism is used to stop situations like left-pad or the pypi incident where a file is removed replaced with a malicious alternative?

        • Valmond@lemmy.worldOP
          link
          fedilink
          arrow-up
          3
          ·
          14 days ago

          The idea is that nodes are trust-less, they do not know anything about the data.

          An owner is authentified over an RSA handshake, so if the owner is not compromised, your request for updating a data will be rejected.

          A malicous node though, must be both lucky (asked to share the data, so it can try to serve the malicious data) but also must have access to the link file so he can use the AES key to encrypt the bad data. This could happen if a malicious peron gets the hand on the link file, which sort of defeats the whole idea in the first place but it’s an attack vector for sure.

          So back to the drawing board again.

          The public RSA key of the owner is already in the link file, I think I can use it to authenticate the data (say the original user uses his private RSA to sign a hash of the data and adds it to the payload).

          Very good feedback, I thought I had it all covered. It seems like I can make a secure fix but I’ll think a bit more about it first of course.

          • lime!
            link
            fedilink
            English
            arrow-up
            2
            ·
            14 days ago

            your reaction makes me more confident that this may turn into something interesting :)

            i take it then that files must have some ownership information associated with them, to distinguish the author from a relay node? or is that just a private key.

            • Valmond@lemmy.worldOP
              link
              fedilink
              arrow-up
              1
              ·
              13 days ago

              Thanks!

              The file does have an ownership information (the public RSA key of the owner), it’s just that a malicious node doesn’t show any proof of ownership of the data it’s sending (which causes the problem). I think I have a straight forward solution but I’ll ponder it a bit more before digging in :-) I’d like to have the possibility to download from several nodes at once which makes things a bit more interesting.

              Would you mind if I copy paste this conversation over to tenfingers@lemmy.mindoki.com ? I guess here it will disappear in the abyss…

              Cheers

              Valmond

              • lime!
                link
                fedilink
                English
                arrow-up
                2
                ·
                13 days ago

                sure, do that. and good luck with this, i did something similar for a project once and as usual its those last 5% that are going to cost you 90% of the time.

                • Valmond@lemmy.worldOP
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  11 days ago

                  Thank you!

                  Ya, there was a saying in video game dev circles, when you have finished 90% of a game, that’s good, because now you only have the other 90% to do…

                  What was that project, if you’d like to share?

                  • lime!
                    link
                    fedilink
                    English
                    arrow-up
                    2
                    ·
                    11 days ago

                    it was nothing official, just a toy file sharing thing using the chord dht algorithm. it consisted of a single binary that you fed with a directory and the IP of an extant member, and it would sync everything on the network into that directory.

                    no edge cases handled, so the 90% remained.