@Xeha
@orignal
Arch
BubbRubb
C341
Danny
FreeB
Irc2PGuest4952
Irc2PGuest51104
Irc2PGuest54175
Irc2PGuest61213
Meow
Over
R4SAS
RN
RN_
acetone_
ardu
awooga-915
b3t4f4c3___
duanin2
eyedeekay
hagen_
halloy13412
hk
mareki2p
poriori_
qend-irc2p
r00tobo
r00tobo[2]
rapidash
semantica
shiver_
thetia
u5657
wew
woodwose
x74a6
aisle
Was there any particular reasoning behind latency-aware tunnel selection falling back to standard tunnel selection when a tunnel within range fails to build? I'm still looking into optimizing I2P deployments of applications and services, and I'm wondering if there's a less obvious reason as to why this was chosen over stricter adherence to the latency configuration: github.com/PurpleI2P/i2pd/commit/e740d5f
aisle
282f302459b