IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2022/08/26
@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+RN_
+T3s|4
+dr|z3d
+hk
+orignal
+postman
+wodencafe
Arch
DeltaOreo
FreeRider
FreefallHeavens
Irc2PGuest15271
Irc2PGuest28511
Irc2PGuest64530
Irc2PGuest77854
Nausicaa
Onn4l7h
Onn4|7h
Over
Sisyphus
Sleepy
Soni
T3s|4_
Teeed
aargh3
acetone_
anon4
b3t4f4c3
bak83
boonst
cancername
cumlord
dr4wd3
eyedeekay_bnc
hagen_
khb_
not_bob_afk
plap
poriori
profetikla
r3med1tz-
rapidash
shiver_1
solidx66
u5657
uop23ip
w8rabbit
weko_
x74a6
mesh it's too bad nickserv doesn't recognize the Destination->Username relationship
HaruCode why would it? it's _nick_serv
mesh HaruCode: Destination->nick is a pretty secure relationship. Instead of making people regain their nicks if they lose it, nickserv could do it for them
HaruCode the whole idea is givin the user independence from their parameters
mesh HaruCode: not really. the whole idea is giving people stable nicks
HaruCode also, ns is not i2p-only service
mesh yeah, that's the real point. I'm sure nickserv has no idea it's working on i2p
HaruCode stable nicks from wherever they login. don't even start it
mesh but it would be a neat feature if nickserv could recognize that the last destination of a nick is secure as long as the destination doesn't change
mesh though I'm curious why nicks get lost and people get renamed to ircguest or whatever
HaruCode noone will bother rewriting a third party program for you. I can give you a script which will automate the nick handling if you use hexchat
mesh really, nobody will rewrite nickserv. I'm shocked
HaruCode yes, especially for such... specific... request
HaruCode as for the nicks - it's because suddenly broken and inactive connection look the same until transport timeout, thus "ghosts" appear, which still hold the nick when you login again, so the irc server thinks it's busy and can't give it to you
HaruCode it's like being unable to tell a troll from a genuinely interested person for some time because of not having enough info
mesh it's more like reacting in bad faith to simple questions
mesh as for the issue with transport timeouts, thanks for that, didn't realize that was the actual issue
HaruCode it's like loaded questions are made to look simple, so it takes a few of them to find out which is which
mesh not really
mesh usually when somebody asks a question you can just answer it or ignore it
mesh it's really not a big deal either way
HaruCode very, very, really. and I'm glad my answers gave you new knowledge
robin If I ACCEPT an incomnig stream using SAM3, can I discover the address of the other end?
zzz yeah I think it's the first line unless quiet=true? but I shouldn't guess, let me look...
zzz If SILENT=false was passed, which is the default value, the SAM bridge sends the client a ASCII line containing the base64 public destination key of the requesting peer
zzz If SILENT=false was passed, which is the default value, the SAM bridge sends the client a ASCII line containing the base64 public destination key of the requesting peer
robin Ah, apparently the Python i2plib does not expose that information. I will have to do my own SAM message parsing then.
robin Or mayby fork i2plib. Right now the accept method just returns two streams
robin Oh, am I correct that this destination line is a separate line AFTER the STREAM STATUS RESULT=OK?
zzz that's my reading of the spec.
zzz stick around and talk to eyedeekay about it, he's our sam guy
zzz maybe look for a different lib
robin If I read the code right, i2plib processes the STREAM STATUS message and then gets out of the way. The destination address should then be the first thing that shows up on in the input stream. I will experiment. I would rather not have to replicate all the parsing that ip2lib does.
eyedeekay I think I missed the SAMv3 question in the scrollback, something to do with "SILENT=true"?
eyedeekay Found it on major
eyedeekay re: am I correct that this destination line is a separate line AFTER the STREAM STATUS RESULT=OK?
eyedeekay this is the case in the spec and in practice, I think you're right about the deficiency in i2plib
eyedeekay You should be able to get it by simply reading the next line that comes out the bridge
robin Over the returned StreamReader? Or the main SAM channel?
robin I will try both -
robin Sine i2plib knows whether it is SILENT or not, it could parse that address line for me
robin I use the source address for security checking with a replicated database I am trying to make