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