#ls2 (irc2p) | #ls2 proposal review channel

eyedeekay What I would like to do is add the ability for SAM to instruct a client to `WAIT` on another response, and that between the WAIT and the session establishment being completed, solicit feedback from the user

zzz just for reference for the others, you're referring to the discussion at the bottom of zzz.i2p/topics/2988

eyedeekay i.e. An application want to make a SAM connection, tell it to WAIT, and in the case of android, use a Toast to present a message to the user "An application is trying to make a SAM connection $nickname" Allow/Deny

eyedeekay For desktop, the channel would be the new Notifications in the taskbar IMO

orignal you don't need to change protocol for it

zzz that's a very interesting idea

orignal look

orignal when user tries to create a new session

zzz orignal is right, no protocol change needed, IF the client side doesn't time out waiting for response

eyedeekay I also thought, in the same vein, that SAM could also have the ability to use a client certificate to authenticate the clients themselves, which the client could pass to SAM by a similar process

orignal he also have to wait until we build new tunnels

orignal so no difference for androind

orignal it waits until user press Yes or No

zzz right, we wait 5 minutes for LS anyway

orignal do we really need cert rather than just password?

eyedeekay No I don't think so, at least for local

eyedeekay It was just a thought about something that might be useful

zzz agreed, I don't see how a cert is any better than a password

eyedeekay Looks like the timeout for Java is a full minute, that seems like plenty

zzz at which phase?

eyedeekay HELLO if I'm reading correctly, I just hastily grepped for it

eyedeekay github.com/i2p/i2p.i2p/blob/12c4f43109461e860e773402856413fa2f7a8ff9/apps/sam/java/src/net/i2p/sam/SAMHandlerFactory.java#L30

eyedeekay private static final int HELLO_TIMEOUT = 60*1000;

zzz yeah you probably want to go farther than that before asking the user, but that's just an implementation detail

zzz one problem with the toast is you don't have any verifiable identification of the client

zzz you don't know who is asking

eyedeekay Yeah that is an issue

eyedeekay But IMO the default response we should recommend for the user is that if you don't know why the app is requesting a connection, say no

eyedeekay So lying about what your app is for only works if you trick the user first

zzz one way to do it is on the client side, create a random username/pw, and display it to the user on first connection

zzz then the toast on the router side says, new user/pw, accept?

eyedeekay Yeah and also that discourages password re-use

zzz or really just display the username on both sides. pw stays secret

zzz with that, you only have to go through the dance once

eyedeekay Good idea

zzz and the username could be e.g. 'appname - randomchars'

eyedeekay That's what I would do

zzz I'm glad we're coming a little closer together here, we started pretty far apart

zzz anything else on 2) ?

eyedeekay We just had to find a way to reconcile our goals

eyedeekay If we think this is a good idea I'm going to get to work on it in a branch

zzz concept ack :)

eyedeekay Thanks, nothing else on 2 for me

zzz anything else for the meeting?

orignal no

zzz one hour flat, thanks everybody

zlatinb hey take a look github.com/citizenlab/test-lists/blob/master/lists/global.csv

zlatinb both geti2p.net and muwire.com are on it, nice