IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2023/08/23
@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+RN_
+dr|z3d
+hk
+orignal
+postman
+wodencafe
Arch
DeltaOreo
FreeRider
FreefallHeavens
Irc2PGuest19353
Irc2PGuest22478
Irc2PGuest48042
Irc2PGuest64530
Irc2PGuest77854
Nausicaa
Onn4l7h
Onn4|7h
Over1
Sisyphus
Sleepy
Soni
T3s|4_
Teeed
aargh3
acetone_
anon4
b3t4f4c3
bak83_
boonst
cumlord
dr4wd3
eyedeekay_bnc
hagen_
khb
not_bob_afk
plap
poriori
profetikla
r3med1tz
rapidash
shiver_1
solidx66
tr
u5657
uop23ip
w8rabbit
weko_
x74a6
dr|z3d sounds ominous. cats and dogs? *laughs*
dr|z3d do not want canine poop in my router. :)
obscuratus And chewing on all the wires...
obscuratus Hhhhmmm, this could be a problem in the segmented netDb as currently implemented.
obscuratus Let's say you fire up a router, and become a floodfill.
obscuratus Then you start up I2PSnark.
obscuratus The I2PSnark client will ask the router for suggested FF to flood the LS.
obscuratus But the router will always exclude itself, even if it is close enough to warrent storing that LS.
obscuratus We'll have to think that one through. It's easy enough to not add ourselves to the list of peers to ignore. With segmented netDb, it might be safe to allow ourselves to be included in the list of routers to flood to.
dr|z3d If we're using segmented dbs, then using ourselves as a floodfill (or not) shouldn't cause an issue, should it?
dr|z3d The worst that could happen is we flood another ff with our dest and then query other ffs to get it.
dr|z3d Or..?
dr|z3d Forget the second part, we don't need to query ffs for a dest we own.
obscuratus We'll no longer know that we own it, I think.
obscuratus I've already had to re-code around the obstacle that the segmented netDb would get refused when it tried to look up another client who was local.
obscuratus For example, shared clients wasn't allowed to look up the LS for the hidden service web page.
obscuratus Basically, to fix that, I had to ask for the LS in a way where the router wouldn't scan the local clients.
dr|z3d So we don't have a segmented db for our own local dests?
dr|z3d Color me slightly confused.
RN I think not collecting our dests into one is the point of segmenting, no?
RN s/our/_OUR_/
obscuratus Of course we'll have segmented db for our local destinations/clients. But I've found I have to block the router from knowing things about it's clients sometimes,
obscuratus The router will have a core "floodfill" segmented netDb. And all the clients will have their own netDb. I've been finding I have to constrain the router to the information in it's own floodfill netDb. It shouldn't be poking around in what's in the client netDb.
obscuratus And, let me be clear, that's basically the desing anyways. Each db only knows about itself.
dr|z3d No, I don't think so. The point of segmented dests is to not reveal to other routers that we own specific dests if we're queried as a ff.
dr|z3d (responding to RN)
obscuratus But it's kind-of interesting. The client netDb's never store RI. They don't need it, just LS.
obscuratus And, if you run with FF disabled, the "floodfill" netDb will never end up storing LS.
obscuratus At least that's the way it'
dr|z3d If you're not a ff, the local ff db presumably doesn't exist.
obscuratus At least that's the way it's working on my well behaved testing network.
obscuratus dr|z3d: No, we call it "floodfill", but it's basically the core router netDb.
obscuratus Although, in a future iteration, we may divorce the two, and have a true "floodfill-only" netDb.
obscuratus As-is though, it should be fine. That's the way I2PD does it, AFAICT.
obscuratus If a client does receive RI, it'll just store it in it's netDb. But the clients don't really do anything with it.
obscuratus So far, in testing, I've never seen a client store RI.
obscuratus If they did, I'm probably guessing that's someone testing for an exploit. But with segmented netDbs, it's no problem.
dr|z3d Looking forward to testing it all out, obscuratus
eyedeekay Sorry I had no service yesterday, will follow up tonight