#ls2 (irc2p) | #ls2 proposal review channel

eyedeekay I finally got back to work on go-i2p last Friday, continuing work on the Noise transport, worked on it for most of Friday and most of SundayI can now make a socket, instantiate a noise transport using the socket, and begin to use it to manage "incoming" and "outgoing" handshakes.They don't complete yet, still working on that, but it's more like debugging now and less figuring out how to actually do it, I more or les

eyedeekay o nowI'm dealing with drawbacks of what I've done here already, I think noiseSocket is intended at times as example of a way to use flynn/noise which is not exactly like I would do it or how a P2P application needs to do itSome of the functions are very long and hard to break down, and they use a different Noise flavor than NTCP2 by default, so I'm breaking things down into steps until I have exactly one step of a N

eyedeekay ne functionWhich should finally give me what I've been hoping for all along, an interface where I can modify steps(i.e. add padding, eventually turn it into NTCP2) by instantiating it with different versions of an interface-defined function, so I get to think about reusability nowI'm going to attempt to ask a question I don't quite know how to ask yet, and maybe won't know the answer until I try it out for myself...

eyedeekay tructures can be "nested" if they implement the common interface(`net.Conn`, `net.PacketConn`), and use the common interface to store the information about the socket in their implmentation, and only use the functions of the common interface(This is true)1. That I can instantiate this Noise-framework Transport struct with functions to modify the process in a granular enough way that turning it into NTCP2 is a matter

eyedeekay functions and plugging them in to an instance of the struct(Sort of like what you would do with inheritance)(which I think is true)2. that I can instantiate it with both a `net.Conn(TCP Socket interface)` and a `net.PacketConn(UDP Socket interface)` because I only use the common features of those 2 interfaces, (Which isn't true yet but I'm thinking about how to do it)Does that potential definition of a moddable Nois

eyedeekay brary mean that I can approach SSU2 mostly in terms of connection management and peer testing, because the crypto would be similar enough to NTCP2 that I could re-use the custom functions?I'll find out the hard way eventually the first time I have to do it with SSU2, but it would be exciting to have come up with a design that has accelerating returns in such a way.

eyedeekay Oops linebreaks

eyedeekay I will try again

eyedeekay I finally got back to work on go-i2p last Friday, continuing work on the Noise transport, worked on it for most of Friday and most of Sunday

eyedeekay I can now make a socket, instantiate a noise transport using the socket, and begin to use it to manage "incoming" and "outgoing" handshakes.

eyedeekay They don't complete yet, still working on that, but it's more like debugging now and less figuring out how to actually do it, I more or less know where the pieces go now

eyedeekay I'm dealing with drawbacks of what I've done here already, I think noiseSocket is intended at times as example of a way to use flynn/noise which is not exactly like I would do it or how a P2P application needs to do it

eyedeekay Some of the functions are very long and hard to break down, and they use a different Noise flavor than NTCP2 by default, so I'm breaking things down into steps until I have exactly one step of a Noise handshake, exactly one function

eyedeekay Which should finally give me what I've been hoping for all along, an interface where I can modify steps(i.e. add padding, eventually turn it into NTCP2) by instantiating it with different versions of an interface-defined function, so I get to think about reusability now

eyedeekay I'm going to attempt to ask a question I don't quite know how to ask yet, and maybe won't know the answer until I try it out for myself...

eyedeekay Supposing:

eyedeekay 0. Go network structures can be "nested" if they implement the common interface(`net.Conn`, `net.PacketConn`), and use the common interface to store the information about the socket in their implmentation, and only use the functions of the common interface(This is true)

eyedeekay 1. That I can instantiate this Noise-framework Transport struct with functions to modify the process in a granular enough way that turning it into NTCP2 is a matter of writing a few custom functions and plugging them in to an instance of the struct(Sort of like what you would do with inheritance)(which I think is true)

eyedeekay 2. that I can instantiate it with both a `net.Conn(TCP Socket interface)` and a `net.PacketConn(UDP Socket interface)` because I only use the common features of those 2 interfaces, (Which isn't true yet but I'm thinking about how to do it)

eyedeekay Does that potential definition of a moddable Noise-over-many-transports library mean that I can approach SSU2 mostly in terms of connection management and peer testing, because the crypto would be similar enough to NTCP2 that I could re-use the custom functions?

eyedeekay I'll find out the hard way eventually the first time I have to do it with SSU2, but it would be exciting to have come up with a design that has accelerating returns in such a way.

orignal maybe you can implemnent using TCP socekts only?

zzz what do you need to answer the questions? a more-knowledgable Go developer?

orignal rather than Noise

eyedeekay Not sure, mostly posing as a hypothetical question, like I said I'll find out the hard way when I try to do it one way or the other

eyedeekay orignal the idea would be to use the most primitive version of the thing, just the abstract functions covered by the interface, in order to allow for this nesting property

zzz I suggest doing it the easiest way first, then plan for refactor time before you add a SSU2 transport. I don't think you have enough vision of what's coming with a 2nd transport to make it perfect the first time

orignal if I was you I would wtite it in "C-style"

orignal without ingterfaces, etc.

zzz yeah, simpler the better, agreed

eyedeekay So not even a TCP socket, really, just the framework for one

eyedeekay bring-your-own-implementation

eyedeekay Fair enough, just something I was thinking about

zzz if you were working side by side with some Go Greybeard you could maybe be more structured

zzz but you have a thousand miles to go, don't get hung up on the first 100 feet, just start walking

eyedeekay Well Go's sort of all-about-interfaces, the normal way to design functions that take and emit objects is to accept interfaces and emit implementations. I'll hold off on trying anything fancy or hypothetical on the existing interface though

zzz we can put out another call for help but don't hold breath

zzz sure, do an interface if that's the go style. just don't try to make it perfect with knowledge of what you need for ssu2

eyedeekay OK that's how I'll approach it

orignal but do you have something that works now?

zzz the java Transport interface has 42 revs in 20 years

eyedeekay orignal I have something that will compile and break at a point I understand

orignal like one funny guy wanted to use i2pd's api but didn't know C++ enough

orignal like lambdas and binds

zzz anything else on 2) ?

eyedeekay Nothing else from me, unless there are more questions

zzz I have a quick 3)

zzz 3) torsocks over socks tunnel

zzz I'm playing with mods to our socks tunnel so torsocks will work with it

zzz first to i2p hosts, then maybe via outproxy

zzz via socks-to-CONNECT conversion

zzz almost have i2p working

zzz might be useful, might not

zzz just FYI

zzz EOT

eyedeekay I can think of a use for it

orignal does it work with i2v6?

dr|z3d chould be useful routing over an outproxy as a wrapper.

orignal *ipv6

dr|z3d *could

zzz torsocks does not support ipv6

orignal while tor proxy does

dr|z3d no support for UDP either.

orignal e.g. you can't connect to remote ipv6

orignal *you can

zzz actually, the tor socks proxy docs say ipv6 doesn't work

orignal I know because I'm using it

zzz maybe that's old

orignal yes it's old

orignal they have added it couple years ago

Xeha tor socks with ipv6 works

zzz cool, that's good to know

Xeha its now enabled by default

orignal I know because tried recently

zzz ok, I have more work to do

Xeha your old version might support it too, you have to add a parameter: SocksPort 9050 IPv6Traffic

zzz so probably torsocks supports ipv6 too

zzz will test at some point

eyedeekay Android has a thing where it will "proxify" an app but you need a VPNService to do it, which we could make on top of a SOCKS proxy.

eyedeekay Result would be that we could have a GUI which automatically configures any/all apps to use I2P on Android with such a thing

eyedeekay Sort of like Orbot

orignal what's a problem to implement socjs connections natively?

eyedeekay Like in the apps themselves?

zzz torsocks does a lot of work to grab the sockets

orignal like in i2pd

zzz huh?

orignal you can specify ntcp2.proxy=socks://127.0.0.1:9050

zzz no this is on the client side

orignal and it will create NTCP2 sessions

zzz sending application traffic through a i2p socks tunnel

orignal then I have missed your point

orignal oh I see

orignal you want torify clearnet traffic

orignal but through i2p rather than tor

zzz yeah basically torify

zzz which is a wrapper around torsocks

zzz so, just playing around, will report back if I ever get it working

zzz anything else on 3) ?

Xeha if you configure torsocks to connect to i2p socks client proxy, torify works over i2p

orignal no

zzz it doesn't work for java socks tunnel because of tor socks extensions, that's what I'm working on

eyedeekay You have to disable something to do with tor's isolation flags don't you? can't remember but if it's an issue I can figure it out

zzz haven't gotten that far

zzz anything else for the meeting?

eyedeekay Nothing from em

eyedeekay me

zzz ok then... everybody please spend this week testing and fixing bugs!

zzz thanks everybody