#dev (ilita) | Обсуждение разработки I2Pd | i2pd development discussion | http://i2pd.website/

thirtyseven hi, i can't stress enough how great settunneltype BOB option is and possibility it unlocks. thank you for implementing this. there is nothing more awesome i could imagine now than the remaining tunnel types getting added eventually. i regret that i didn't look at releases page much earlier. since my last message here i've been slowly trying to read and modify BOB.cpp and BOB.h in an attempt to add option to

thirtyseven connect to a specific default destination instead of reading it from user. finally i realised and confirmed that BOB does not have option to specify udp (or any other) tunnel type, as i saw the new release and how the settunneltype option was done, which is the real way this needs to be done in BOB.

thirtyseven gotta go try connect to udp server through socks next.

orignal заебал

orignal никто этим заниматься не будет

orignal BOB never had UDP

thirtyseven never had udp: yea, i was mistaking the option key=value command for config options and trying to set eg "option type=udpclient", which was dumb as fuck, and they are probably the i2cp options: tunnel length etc. but now the socks is socks and as socks5 i supposet it can work with udp traffic? or if not then fuuuck, guess imma have to reconsider the external forwarder shits

orignal updclient is i2pd tunnel

orignal not port of BOB protocol

thirtyseven and the socks that BOB can expose now is equal to the socks that can be exposed through tunnels.conf or it is limited to what BOB can do aka no udp for this socks?

orignal better to ask qend

orignal he has implemneted proxies for BOB

orignal ofc there is "socks' tunnel type in I2Ptunnels

orignal e.g. you can create sepaate in addition or instead standard socks proxy

orignal same for http rpoxy

thirtyseven hmm yea ok, so it seems it should have the same abilities, (maybe?) and i2p is capable of socks5 so i guess it could be expected of it to allow udp? ok thanks, imma ask quend and try myself too

orignal socks5?

thirtyseven well, at least on java i2p it says it supports socks5

orignal I'm going to implement just don't have time

orignal they only say this

orignal they never used and never tested

thirtyseven ah ok yea

orignal also SSU2 can work through socks5 proxy

orignal e.g. there is UDP socks code in i2pd

thirtyseven ah yes, i think when i was looking over the docs i saw this and though that this could mean socks5 can be used normally. still good

thirtyseven best of success with socks5 then at some point. guess all this isn't everything i thought, but still im imagining that BOB is an interesting candidate for opening local tunnels of other types too? like what you said once that you were proposing to be done with i2pcontrol. but java i2p didn't want to do it, (beacuse i2pcontrol gives control of router probably? idk)

orignal Java I2P doesn't support BOB anymore

thirtyseven yea i know

orignal we use it in reg.i2p

orignal for lookup command

orignal to check if an address is online

thirtyseven kinda like BOB, itsimple. and this settunneltype option gave me some hope that it could evolve into the thing that i was ranting about aka interface to open tunnels on local ports programatically. now we can open tunneltype socks, so it is something.

thirtyseven and httpproxy*

thirtyseven too

thirtyseven but yea if i understand correctly then the way all this shit works is, it's not like BOB could somehow message some part of router to create a tunnel, it would have to do it all from scratch within it's own scope or something like this? which would endup being more work than some form of samforwarder

thirtyseven (guessing blindly)

thirtyseven would use a forawarder already, if only there was some project in normal language that can just build offline with regular compilers. and forwarder has a disadvantage that you need a lingering process, and you need to keep track of it and manage it, this is why i was rather attempting to make BOB do what i wanted.

thirtyseven ok, guess i tried everything for now.

thirtyseven thx

thirtyseven comming back to what was talking about last time: also i don't know what would be more work to modify, SAM or BOB to allow for opening all standard tunnel types on local ports

thirtyseven SAM can forward server tunnels already after all

orignal SAM

thirtyseven yea. maybe i should at least take a look at SAM.cpp

orignal well i2pd supports SAM 3.1 only + datagrams

orignal 3.3 is not finished

thirtyseven guess would be addition to 3.1 then. but yea so far i wasn't even able to pass option value to Receive function in BOB.cpp

orignal if you need saomething for SAM datgrams I can add

thirtyseven thank you i'll keep that in mind. now i haven't gotten around to workign with FORWARD yet, (hope i can do it without problems), but iiuc sam FORWARD exposes server tunnel on local port. then what i really need is FORWARD but for clients both tcp and udp, with predetermined i2p address to connect every new socket to. as i was saying in the past: for configuring tunnels for client applications programatically.

thirtyseven eg quickly launch a tunnel, along with irc client that can use it.

orignal but it's there alreday

orignal line 1235 and below in SAM.cpp

orignal auto ep = session->UDPEndpoint;

thirtyseven and FORWARD of client tunnel to local port is supported? well if it is, then this is absolutely wonderful. but this seems to be totally undocumented, as it only mentions FORWARD for servers both tcp and udp but, not for clients

thirtyseven as documentation only mentions*

thirtyseven i mean, on irc2p they said that this is not a thing and makes no sense, unless they completely misunderstood my question?

orignal m_Owner.SendTo({ {(const uint8_t *)base64.c_str(), base64.size()}, {(const uint8_t *)&lf, 1}, {buf, len} }, *ep);

orignal so it's sends to ep specified in session create

orignal there is no difference between client and server for datagram

orignal only if you publsh LS or not

orignal if you receive a datagram from I2P you must have some rule what to do with it

thirtyseven so while creating my sam session, what command is used to specify local port to which i will be able to connect my client app? docs say only about: A)PORT= which is only valid for datagrams, and B)FROM/TO_PORT which are said to be only in SAM 3.2

orignal PORT=1234 and HOST=127.0.0.1

orignal again i2pd's SAM is not 3.1 it has some more stuff adopted from 3.2 and 3.3

orignal if you want both datagram and streams on the same dests you need subsession that's in 3.3 and not fully implemented

orignal why? because grandpa screwed it up completely

thirtyseven so this from SAM docs: "[PORT=$port] # Required for DATAGRAM* RAW, invalid for STREAM" -this does not apply to i2pd, and i can just specify PORT= with with STYLE=STREAM and it will expose it on specified port?

orignal no only for datagram

orignal for stream you use FORWARD

thirtyseven ok and then FORWARD works for client tunnel too? not only server?

orignal as I said multiple tunnels per dest is 3.3

orignal for UDP yes

orignal for stream no

orignal client is when you initiate a session not other side

thirtyseven yes client is an outgoing connection. ok, so with SAM i can do UDP on local port, and i can do TCP on local port, but only for server, not for initiating connections. ok, so can't use sam as programmatical replacement for tunnels.conf. that's a shame

thirtyseven i'd need to do forwarding with external program. like gosamforwarder or i2ptunnel.jar

thirtyseven fuck had some hope there again. i need: programmatical alternative to tunnels.conf, and the way i saw it SAM would almost be doing it, IF it could expose client tunnel to local port, but it can't.

orignal futhermore it requires STREAM CONNECT

AreEnn some day 37 will have his new and improved wheel

orignal ))))

thirtyseven AreEnn, i want a wheel but what im getting is a fucking triangle

thirtyseven A nigger (like me if you will), cannot and should not be expected to fucking add shit to tunnels.conf or fuck around with webui all the time. it's not realistic. Im a special little nigger that can do it for myself fine. But even I don't want to have to go comment and uncomment tunnel configs to disable them when im not using them.

thirtyseven why keep this shit open, to what purpose. if i am not keeping my irc open. i can have billion trillion different games and apps i might want to use and now i need to comment them in and out. instead i could just request tunnels once, and start irc by single script, i'd understand not wanting doing this, because idk universe somehow makes it extremely hard. but i am baffled this can be seen as reinventing

thirtyseven the wheel/unnecesary.

thirtyseven and external forwarder is a dogshit solution, because you need additional process and you need to manage it, and it's a space for failure and unreliability, if it dies for any reason then you loose connection, and you need to restart the entire program to regain it.

thirtyseven and the argument about this is bad becuse it is unspecific and insecure is so unfathomably retarded, the security of user's software is his own responsibility, i2p passes data in and out. i2p is not only means of anonymisation, it is also means of direct secure connectivity that does not exist without it.

thirtyseven not for everyone

thirtyseven im a nigger alright. i don't know HOW. but i know what niggers do, and what niggers need. and want it or not, world is made of niggers

thirtyseven fuck it, wanted to delete the last one but hit enter instead

thirtyseven whatev it's true in the end

thirtyseven A repetitive action that takes time and effort and fault points, has no right to not be automated. Time is wasted with every single having to learn to and adding configs in tunnels.conf or through webui.

thirtyseven not automating this, is design for obscurity.

thirtyseven some day 37 will have his new and improved wheel -Gonna be a good day.

thirtyseven fuck, obviously you hate niggers so i only made a case against myself by taking that angle jesus christ. the real point is, it is why disregard the matter of cooperation with existing software like this, why disregard i2p's role in empowering real hardware self hosting of all kinds of things, no more fucking nigger cloud bullshit, i2p could send it down the drain if it only made it easy to reliably request

thirtyseven tunnels for i2p unaware applications.

jrnd__ thirtyseven: why sick noise. go ahead and implement programmatical tunnels in your fork(s) and/or pull requests to i2pd and or i2pjava. sync those PRs with teams or fork, that's a lot of room

jrnd__ thirtyseven: everyone can blame, but implementing requires hard labour.

jrnd__ thirtyseven: write i2p proposal(s) if you need to extend i2p specs

thirtyseven im trying, wish me luck but you might not live to see it lol. im not even talking about demanding it, i simply can't understand why would so many people say like "this is dumb, no reason to do this" or just act like they don't understand it at all, and not see this as obvious advantage.

jrnd__ thirtyseven: you could even write fork(s) or impls that compete and struggle with everyone

jrnd__ thirtyseven: people are complex and there are various ways to defend your own ways

jrnd__ thirtyseven: as Ian Anderson sang, "roll your own little sparrow on the schoolyard wall"

thirtyseven yea this is very interesting. to me it seems like i just have to be trolled and fucked around with at least to some extent. while the real deal is, that native solution like SAM gives power and control over SAM apps to i2p itself and what im talking about here gives none of that.

jrnd__ why you need to be a victim of troll crowds. you need not.

jrnd__ just think and implement.

thirtyseven not victimising myself, simply running out of options

jrnd__ thirtyseven: our viewpoints with orignal often mismatch, and he always proposes to do a fork, and it's completely OK.

jrnd__ thirtyseven: do your own i2p

jrnd__ thirtyseven: and existing i2p's network is open

jrnd__ thirtyseven: that's infinities of options in fact.

jrnd__ orignal: крч ещё один нытик, и видимо извилины в череп сильно упираются, опций не видит никаких

jrnd__ чет со связью

jrnd__ orignal: крч ещё один нытик, и видимо извилины в череп сильно упираются, опций не видит никаких

jrnd__ крч ещё один нытик, и видимо извилины в череп сильно упираются, опций не видит никаких

jrnd__ чет меня шатает часто

jrnd__ пинг прошел, ок.