Replies: 4 comments 7 replies
-
No. Reducing dependencies would mean re-implementing well-regarded, broadly used and tested software such as libsodium. While that would reduce the number of lines of code, it would NOT make things more secure. In other words, this:
is false. At best it is a weak correlation, but if you are applying it as a hard and fast rule to assess software quality or security then you should not be assessing software quality or security. |
Beta Was this translation helpful? Give feedback.
-
|
additionally by making these a dependency we are reducing the lines of code WE are babysitting, which objectively reduces complexity on OUR end. the notion that reimplementing or vendoring a dependency makes things less complicated or "more secure" is truly asinine. |
Beta Was this translation helpful? Give feedback.
-
|
now include the kernel and userland to you loc count. keep in mind, compared to something like tor browser it is piss in the wind. |
Beta Was this translation helpful? Give feedback.
-
|
realistically, the core of lokinet itself is not THAT bad. still bigger than i want it to be. ~/git/lokinet $ cloc llarp/
428 text files.
428 unique files.
3 files ignored.
github.com/AlDanial/cloc v 1.86 T=0.23 s (1836.4 files/s, 298971.3 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
C++ 167 4343 1702 35297
C/C++ Header 250 4831 2689 18376
C 3 105 57 801
Objective C 2 78 33 455
CMake 2 49 9 331
XML 1 1 5 31
-------------------------------------------------------------------------------
SUM: 425 9407 4495 55291
-------------------------------------------------------------------------------there is a lot more gutting of redundant code that can be done than people think. additionally separating each part of the core into its own strictly isolated library would definitely inform boundaries between components and clearly define their relations. right now it is a bit kitchen sinky in a few parts. |
Beta Was this translation helpful? Give feedback.
-
|
sorry guys, this was a dumb question in the first place. A (hopefully) less dumb question: are there any particular parts of the codebase you would like to refactor or rewrite? Obviously not talking about basic cryptography parts, more about the interfaces. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, there are quite a bit of the internals left from early lokinet development that are overdue for some serious refactoring. To take a tiny example, Lokinet has various custom implementations of bencoding serialization/deserialization that would be much better replaced and simplified with our oxen-encoding library (which lokinet already uses). This isn't a deficiency, though: lokinet was the first thing to use bencoding, but as other code used it (oxen-mq, oxen-storage-server, oxen-core) we built a more general purpose interface in https://github.com/oxen-io/oxen-encoding. Lokinet uses that already in some places, but there are still older parts of the code that haven't been retrofitted. As to larger refactors, @majestrate has been talking about getting a major internals refactor underway for a long time; some of the internals (particularly around internal handling of "endpoints") is... complicated, to put it charitably. |
Beta Was this translation helpful? Give feedback.
-
that mess was a result of 4 incomplete refactors tripping over each other to solve the same problem. it failed spectacularly each time i tried to as some feature we needed made it harder to fix 😩 |
Beta Was this translation helpful? Give feedback.
-
|
i do not think it is a dumb question and i think this is a legitimate concern with software at all levels of operation. i myself am unsure of what constitutes a proportional response to address the issues of excess complexity. over all, it seems to be a long term pondering in software. a note on the core ethos of the code: lokinet started as SARP (simple anon routing protocol) but i realized that it wouldn't be easy to keep it simple so i changed "simple" to "low latency" as that is much more concise depiction of the long term goals. |
Beta Was this translation helpful? Give feedback.
-
|
Looking back, the question was not necessarily dumb, but rather poorly phrased. I like how Bjorn Stahl (aka Letoram aka crasygload etc.) summarizes software simplicity in "12 principles for a Diverging Desktop Future". I interpret his words like this: the software should be able to do what the user expects it to do, which means a balance between 'so barebones it's practically useless' and 'actually, it can read your mail too!'. |
Beta Was this translation helpful? Give feedback.
-
|
i agree with this philosophy. lokinet is a unicast ip packet onion router and this it all it ever really does. the biggest issue in it is that every os has their quarks when it comes to networking. this explodes fast. most of the bs code in lokinet arent those parts, it's some cruft idiocy from an era i am glad is gone. see #2013 for the whole enchilada. |
Beta Was this translation helpful? Give feedback.
-
TL;DR:
Plus you also depend on even more stuff.
We all know that more code = more bugs. More bugs = more security issues. I don't trust Tor, I am sure that a lot of nodes spy on their users. Lokinet seems much more trustworthy, but why does it require so much unsafe code? I am afraid of giving my Internet privacy to this amount of loc. Are there any plans to reduce build & runtime requirements?
Beta Was this translation helpful? Give feedback.
All reactions