4 ms·

Yeah I think RFC format would be more ideal?

loup-vaillant 6y ago
It doesn't really matter. What does is the process: how their protocol came into being. If they just did what was most convenient to implement in Python, that can easily have a huge negative impact: a good protocol has to take into account all the complexity, not just the ease of picking up whatever is on Python's very comprehensive standard library. For instance, would you serialise your messages in JSON? It sure is convenient. Works with many languages. You can send out text streams, or even binary streams if you encode them in base64. Though it takes some space, so you might want to compress the whole thing before you send it. Possibly over an HTTP tunnel, there are lots of HTTP client & server implementations out there. And all of a sudden you are depending on JSON, gzip, and some http stack. Which is crazy. If you start from the wire format, and make sure it is as simple as possible, you will get simplicity for most implementations, without dragging it huge dependencies just because it was convenient, you will get performance because you're not wasting your time juggling between formats and compression and whatnot, and you will get security because your stack just got much smaller. What I fear about IpV8 is that it appears to be Python only. Which is a strong clue that this protocol wasn't designed, but grown on top of what Python provides. At the very least, we need a C implementation with no third party dependency to measure the true complexity of the protocol, and maybe simplify whatever needs to be simplified. I know, C is a underpowered, unsafe language. That's kind of the point: if the C implementation itself is simple, then we know this protocol can be implemented in anything.
- sumtechguy 6y ago
  Very good points. I suggested the RFC because it usually forces you to think about those very things. What is the protocol? What do you need to make it work? How do you setup a call? How do you tear one down? What bits are in the payloads? Which side has which responsibility? What happens when there is an error? What sort of errors should I expect as a client/server? What if the other side is a different endianness? Starting in python is not a bad one to do. I think it is a great prototype language. Your suggestion of going to something simpler like C is not a bad idea. It would shake out those dependencies they did not know they had. Python is sneaky about that, as it has some very nice tools just to manage its own data (looking at you dictionaries). But those same tools do not exist in C without some external lib or extra code.
  - loup-vaillant 6y ago
    Hmm, the RFC process seems to cover more than my suggestion to do C. I'll revise my position slightly, and agree that we need to do something like an RFC at some point. I also agree with starting with a prototype in whatever high level language you have. Python is a good prototype language. However, I see that the first commit is 20 years old? They should have outgrown Python by now.
    - sumtechguy 6y ago
      Yeah, they probably should abstract and write it down at this point. 20 years is a long prototype :). Moving to C is not a bad idea at all. It would shake out those issues. The RFC bit is more to get it so you can rip it apart and do the thing in any language. I have done a few of these sorts of things over the years. It is very easy to tie yourself to a particular language library without realizing it. Sometimes just writing down what bits go back and forth and responsibility helps shake out those oddities. If I were doing it I would probably start with a port with something like C just so I could understand what is really needed and what is cruft. Then doc it into the RFC format as I went along.
      - synctext 6y ago
        Hopefully you still see this late reaction by IPv8/Tribler team. There is now Kotlin code, Android Trustchain app and expired IETF draft. On top of the pretentiously named IPv8 overlay, we now have tamper-proof accounting and trust function operational. Took a mere 20 years of my life:-) [1] https://github.com/Tribler/kotlin-ipv8/ https://github.com/Tribler/kotlin-ipv8/ [2] https://github.com/Tribler/trustchain-superapp https://github.com/Tribler/trustchain-superapp [3] https://tools.ietf.org/id/draft-pouwelse-trustchain-01.html https://tools.ietf.org/id/draft-pouwelse-trustchain-01.html [4] https://dicg2020.github.io/papers/devos.pdf https://dicg2020.github.io/papers/devos.pdf

It doesn't really matter. What does is the process: how their protocol came into being. If they just did what was most convenient to implement in Python, that can easily have a huge negative impact: a good protocol has to take into account all the complexity, not just the ease of picking up whatever is on Python's very comprehensive standard library. For instance, would you serialise your messages in JSON? It sure is convenient. Works with many languages. You can send out text streams, or even binary streams if you encode them in base64. Though it takes some space, so you might want to compress the whole thing before you send it. Possibly over an HTTP tunnel, there are lots of HTTP client & server implementations out there. And all of a sudden you are depending on JSON, gzip, and some http stack. Which is crazy. If you start from the wire format, and make sure it is as simple as possible, you will get simplicity for most implementations, without dragging it huge dependencies just because it was convenient, you will get performance because you're not wasting your time juggling between formats and compression and whatnot, and you will get security because your stack just got much smaller. What I fear about IpV8 is that it appears to be Python only. Which is a strong clue that this protocol wasn't designed, but grown on top of what Python provides. At the very least, we need a C implementation with no third party dependency to measure the true complexity of the protocol, and maybe simplify whatever needs to be simplified. I know, C is a underpowered, unsafe language. That's kind of the point: if the C implementation itself is simple, then we know this protocol can be implemented in anything.

sumtechguy 6y ago
Very good points. I suggested the RFC because it usually forces you to think about those very things. What is the protocol? What do you need to make it work? How do you setup a call? How do you tear one down? What bits are in the payloads? Which side has which responsibility? What happens when there is an error? What sort of errors should I expect as a client/server? What if the other side is a different endianness? Starting in python is not a bad one to do. I think it is a great prototype language. Your suggestion of going to something simpler like C is not a bad idea. It would shake out those dependencies they did not know they had. Python is sneaky about that, as it has some very nice tools just to manage its own data (looking at you dictionaries). But those same tools do not exist in C without some external lib or extra code.
- loup-vaillant 6y ago
  Hmm, the RFC process seems to cover more than my suggestion to do C. I'll revise my position slightly, and agree that we need to do something like an RFC at some point. I also agree with starting with a prototype in whatever high level language you have. Python is a good prototype language. However, I see that the first commit is 20 years old? They should have outgrown Python by now.
  - sumtechguy 6y ago
    Yeah, they probably should abstract and write it down at this point. 20 years is a long prototype :). Moving to C is not a bad idea at all. It would shake out those issues. The RFC bit is more to get it so you can rip it apart and do the thing in any language. I have done a few of these sorts of things over the years. It is very easy to tie yourself to a particular language library without realizing it. Sometimes just writing down what bits go back and forth and responsibility helps shake out those oddities. If I were doing it I would probably start with a port with something like C just so I could understand what is really needed and what is cruft. Then doc it into the RFC format as I went along.
    - synctext 6y ago
      Hopefully you still see this late reaction by IPv8/Tribler team. There is now Kotlin code, Android Trustchain app and expired IETF draft. On top of the pretentiously named IPv8 overlay, we now have tamper-proof accounting and trust function operational. Took a mere 20 years of my life:-) [1] https://github.com/Tribler/kotlin-ipv8/ https://github.com/Tribler/kotlin-ipv8/ [2] https://github.com/Tribler/trustchain-superapp https://github.com/Tribler/trustchain-superapp [3] https://tools.ietf.org/id/draft-pouwelse-trustchain-01.html https://tools.ietf.org/id/draft-pouwelse-trustchain-01.html [4] https://dicg2020.github.io/papers/devos.pdf https://dicg2020.github.io/papers/devos.pdf