@eyedeekay
&eche|on
&zzz
+RN
+acetone
+dr|z3d
+hottuna
+orignal
+postman
+weko
An0nm0n
Arch
FreefallHeavens
Gid
Hidenet
Irc2PGuest16050
Irc2PGuest19856
Irc2PGuest2827392
Irc2PGuest65220
Irc2PGuest79172
Irc2PGuest83718
Minogami
Onn4l7h
Onn4|7h
Palimpsest
ProRu
Sleepy
SoniEx2
T3s|4
T3s|4_
Teeed
aargh4
admin
anon4
b3t4f4c3__
cheddah
eyedeekay_bnc
itsjustme
j6
limak
not_bob_afk
profetikla
qend-irc2p
rapidash
tbqdrn
theglitch
w8rabbit
x74a6
zer0bitz
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