#ls2 (irc2p) | #ls2 I2P Protocol Development Discussion - Next Meeting Monday, October 9th 6:30 UTC

zzz we just spent a year working on taking a few bytes out of SSU here and there to make SSU2. But in streaming, datagrams, etc. 300 bytes doesn't matter?

orignal also I don't compress streaming

orignal few bytes in every packet is one thing

orignal 200 bytes in SYN only is another thing

orignal and

zzz we took about 900 bytes out of the SSU 1 handshake

orignal you save 200 bytes in SYN but it still goes though 1K tunnel message

zzz true

orignal that's why I'm skeptical there

orignal ofc I can compress just a SYN packet

orignal not a problem

zzz we always compress the SYN, even if the gzip option is off

orignal I don't for now but I can change

zzz so, tell us more about your b33 idea. how would it work, how would it be compatible or what protocols would have to change?

orignal we always use b33 as detination's address

zzz so we change every layer of every protocol?

orignal why?

orignal how we do it for encrypted LS?

zzz I'm asking.

orignal not really just lookup with flag

orignal that 32 bytes means not ident hash for signing key

orignal see, in my code I use full address rarely

orignal my point is since it works for encrypted leasets why it can't be expanded to non-encrypted leasesets?

zzz I don't understand at all. You can try to explain it more, or write it up and send me a patch for the proposal

zzz what's the "expansion" algorithm?

orignal for example

zzz and what protocols use "new b33" vs. what use old system?

orignal I have a B33 adrress

orignal and I can build full address assuming that crypto and padding are all zeros

orignal for a destination we actually need signing key and signature type

orignal simply speaking we don't need crypto keys and cetificate for dest

zzz so what protocols change to use "b33"

zzz and what protcols stay the same?

orignal streaming for example

orignal ofc it needs to be discussed more

zzz so streaming v2 uses b33 instead of full dest in the SYN?

orignal what I want to do just get rid of crypto key in dest's identity

orignal yes

orignal 35 bytes

zzz So that saves 352 bytes.

orignal b33 just replaces identity

zzz But you said 'who cares' about saving 320 bytes

orignal no it's not about saving

orignal current identity format is also not simple

orignal like you have to parse certifcate

orignal find signature type than find offset of signature key, etc.

orignal also for my favorite topic p2p connections

zzz sure, but unless you change EVERY protocol AND stop supporting the old format, you still need that code

orignal you receive an inncoming conenction and have to deal with long peer address

orignal it might be some magic number identify new format

zzz how do you know if a dest supports streaming v2?

orignal because it publishes b33

orignal veru easy

zzz but it would still have to support v1 also?

orignal orc

orignal ofc

orignal you peer can be with old identity

zzz so there's two leasesets, one for the old dest and one for the new dest?

orignal maybe

orignal but it the same problem that we had with new signature types

orignal some dests didn't support new types at all

orignal same for LS2

orignal notthing new

zzz sure, but the problem is I listed 20 different protocols in the proposal that know about destinations

zzz either all have to support a "v2" or there needs to be some layer where the conversion happens

orignal that's what we need to think

orignal hence I would start with routers

orignal because RI always has version

zzz see, the padding proposal gets us 90% of the savings with 1% of the effort

orignal 32 crypto 32 signature and maybe 2 bytes for flags

zzz and maybe only good for a couple years before we add PQ crypto types

eyedeekay I'm back, sorry got double-booked

eyedeekay Potentially dumb question for orignal: is the idea that this is a "migration" sort of thing where once everybody's on the new style the old style gets dropped?

orignal then let's do it alreast for routers

orignal eyedeekay that's what we had for new signature types and for LS2

orignal say flibusta.i2p didn't understand EdDSA for a long time

orignal I had to chase them to upgrade

eyedeekay Just wanted to make sure that there wasn't something I was taking for granted in the scrollback

orignal zzz so let's start with router

orignal no proeblem for me to implement

zzz like we spend two years 2023-2024 making this change, then in 2025 we start supporting sntrup761 and router identities are huge again

orignal then let's not do it

orignal just gzip compression

zzz I want to understand your proposal and discuss it further

zzz but we need it written down so we can really figure out how it would work

zzz I listed 19 protocols that might be affected. Identify which ones would change and how the transition would happen

zzz and what the benefits would be

zzz I agree this is a good time to think about it

orignal and I will change compression for SYN

orignal because it usually comes with LeaseSet

zzz yeah also HTTP headers are pretty compressible

zzz I think I always compress the SYN, SYN ACK, and CLOSE

zzz but I can check if you want

orignal I meant 1K problem

orignal it make sense because they come together with LS

zzz yeah

orignal let's start doing it then

zzz also, if you're fetching a bunch of images, you may get multiple SYNs or fragments in a single tunnel message\

orignal yes, maybe

zzz sure, just guessing

zzz ok, I want to keep discussing our options in the coming weeks. Not planning on making any changes for this release

zzz anything else on 1) ?

orignal no

zzz eyedeekay, you have anything for the agenda?

orignal when the release btw?

eyedeekay Nothing to add today

zzz late november

orignal how is you go router going along?

zzz next week will be #ls2 meeting 200, bring your party hats

orignal )))

eyedeekay Not much movement this week

eyedeekay I've been in Easy-Install and Browser-Related things

orignal also I start thinking about SSU2 through socks proxy

zzz I don't think we started counting until #ls2, we didn't count the #ntcp2 meetings

zzz oh, I'll give a very quick status

orignal also you might see SSU2 with ygg addresses soon

zzz on ssu2

orignal sure

zzz obscuratus found a problem with the way we were handling termination acks

orignal what's that?

zzz because we weren't handling them at all, it fell back to ssu 1 processing, and then we started blocking ports

zzz fixed today

orignal good

orignal I see another issue with SSU2

zzz whats that?

orignal lack of routers supporting it again

orignal Charlie ofter fails as "already connected"

orignal when I have few hundreds SSU2 links

orignal simply speaking we need throusands in the network

orignal that's why I'm asking about release

orignal I have changed transport selection logic recently

zzz wow, you're doing "hundreds", thats great

orignal not NTCP2 vs. SSU2 is chhosen randomly

orignal around 250-300 links

zzz cool

orignal as I said because 1/2 proebabilty now

orignal SSU2 ( 202

orignal SSU2v6 ( 65

orignal what I see now on one of my routers

zzz our 2% enable for this release worked really really well. We've fixed so many little things, just from having a lot of testers

zzz we'll have to remember it for whatever we have to test next :)

orignal that's why I have this probem with Charlie now

zzz yup

zzz anything else for the meeting?

orignal we simply need more

orignal no

zzz ok, party next week, invite your friends