4 ms·

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?

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

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