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

orignal good point about hole punch

orignal I ignore it in SSU2 and handle it in SSU1

orignal so, unsolocited retry but can we?

zzz I think it should basically be the same as retry, but a new message type 11

zzz because I need to handle it differently

orignal and Charlie's intro key for encryption?

zzz alice's I think. same as peer test

zzz we should always use the target's intro key if we have it

orignal yes, Alice is also fine

zzz ok

orignal since we pass her router ident

zzz right

orignal and not only IP adress

orignal my concern is we prefer Bob's intro key

orignal e.g. Alice tries to connect to Charlie that will become Bob after introduction

zzz yeah but the hole punch is really separate from the handshake

zzz different connection ids too

orignal yes, it's fine

zzz let me add it to the spec and then you can review it

orignal yes please

eyedeekay I'm about to have a cluster headache, it's probably going to start in the middle of the meeting

eyedeekay Following up on some stuff in case I'm not able to answer during the meeting

eyedeekay go-i2p I'm **finally** checking in the initial refactor that I've been working on for the better part of a half a year

eyedeekay It took 3 attempts but it it's finally happening, so the main branch is waking up *today*

eyedeekay Still not usable as a router but as a library, it's beginning to work

eyedeekay I have a working interactive SAM AUTH promt for our Android package, testing it with BRB to get an idea of how applications should handle denials

eyedeekay One of my Matrix people suggested that that we do sanity checks on cryptographic signatures before we actually use them, in order to be proactive about things like the Psychic Signatures vulnerability

eyedeekay I see where he's coming from but I think there are enormous workability problems at the very least, I'm pretty sure it's not the right way but there were enough "Pro's" that it seemed worth bringing up

eyedeekay I think that's everything of significance I have to report on

eyedeekay I'll still try to attend the meeting, just not sure how good I'll be, wanted to get this out before it takes me down

zzz 0) Hi

zzz hi

eyedeekay hi

zzz thanks for the updates eyedeekay but you should go take it easy

orignal hi

zzz what's on the agenda for today?

zzz how about 1) SSU2 status

orignal yes

zzz anything else for the list?

orignal and SSU2 relays

orignal nothing

zzz ok, 2) is relays

zzz 1) SSU2 status

zzz I'll let you go first orignal

orignal So, I publish SSU2 addreses with "C" caps now

orignal should be able to connect to other SSU2 routers through instroducers

orignal recognize ih* params

zzz great, have you tested it?

orignal not yet

orignal still don't publish introducers

zzz ok

zzz any other status?

orignal implemented the way we discussed last week

orignal as I said before saw SSU2 session for more than 12 hours

orignal with a lot of data

zzz super

zzz my status:

orignal will start implemnting peer test sson

zzz haven't said it, but every time we talk about something and agree, or almost-agree, I update the spec

orignal ))

zzz last week I said I'd have relay code in 1-2 weeks.

zzz that's not even close

orignal I know

zzz I think it's going to be about 4 more weeks

orignal relays are complicated

zzz I'm working on it every day

orignal but simplier than in SSU1

zzz but trying to modify the state machine will take some time

zzz the messages themselves are easy; it's the state machine that's hard

zzz so I'll probably code up the messages soon

orignal I don't use a state machine I use different approach

zzz "state machine" makes it sounds better than it really is :(

zzz it's all code from 2005

orignal I think so

zzz I think that's all of my status

zzz have to spend more time getting ready for release, which is probably May 23rd

zzz we'll make a final decision on the release date tomorrow

orignal same here

orignal found few bugs

zzz 23rd ok with you?

zzz ping

orignal yes

orignal fine

zzz ok, let's plan on that

zzz anything else on 1) ?

orignal no

zzz 2) SSU2 relays

zzz I updated the spec for a hole punch message

orignal good

orignal I will check and implement

zzz I need to add more text about it, that you don't need to wait for the Relay Response if you get the hole punch first

zzz that's the way we do it in SSU 1 but I'm not sure if it's documented in the SSU 1 specs

orignal how come?

orignal I need to verify Charlie's signature

zzz hmm

orignal to make sure it's that IP

zzz we could put the Replay Response block in the Hole punch message too

orignal maybe

orignal that's good idea

zzz your concern is that Bob "fakes" a hole punch to Alice?

orignal maybe

zzz ok, let's put the same Relay Response block in the Hole Punch message. Can't hurt

orignal yes

zzz I'll update the spec

zzz you said you were using RI blocks, not I2NP messages, to send the RIs, right?

orignal yes

zzz if they fit?

orignal if it fits

orignal if not then I2NP

zzz ok. I updated my code last week for peer test to handle that

zzz are you putting them in the same message as the relay block if they fit?

zzz or two separate messages

zzz ping.....

orignal sec

orignal yes same message

orignal sometimes all your messages come at the same time

zzz yeah, lag

zzz ok, same message if possible. got it

zzz will make sure I can handle that

zzz any other discussion on relay?

orignal no

zzz it's good we're both thinking about it at the same time, easy to make decisions that way

zzz anything else for the meeting?

orignal not from me

zzz ok, thanks everybody

orignal zzz, doesn't Bob need to send full relay response back to Alice or just status since Alice will receive it from Charlie?

zzz alice may be firewalled, if so she won't get the hole punch, so the full relay response needs to be sent by Bob also