@eyedeekay
&eche|on
&kytv
&zzz
+R4SAS
+RN
+T3s|4
+acetone
+dr|z3d
+orignal
+polistern
+postman
+weko
+wodencafe
An0nm0n
Arch
FreefallHeavens
Gid
Hikari
Irc2PGuest2974
Irc2PGuest4253
Irc2PGuest51959
Irc2PGuest5219
Leopold
Minogami
Onn4l7h
Sleepy
Soni
Teeed
aargh1
admin
anon
apt0110
b3t4f4c3__
cheddah
eyedeekay_bnc
eyedeekay_bnc_
itsjustme
j6
limak
not_bob_afk
pihole2
poriori
profetikla
qend-irc2p_
rapidash
tbqdrn
theglitch
u5657
user100
w8rabbit
x74a6
yourtrueself
zer0bitz
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...
dr|z3d
:)
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