👮 major
✅ irc2p
#i2p-dev #i2pd-dev #ls2 #saltr
✅ ilita
#4rum #acetonevideo #dev #retroshare #torrent #video2p
IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#saltr
/2025/11/15
~dr|z3d
@RN
@RN_
@Stormycloud
@T3s|4_
@eyedeekay
@not_bob_afk
@orignal
@postman
@zzz
%Liorar
%cumlord
%snex
+BeepyBee
+FreefallHeavens
+H20
+Onn4l7h
+Onn4|7h
+bak83
+leopold_
+poriori
+profetikla
+qend-irc2p
+r00tobo
+uop23ip
+xHarr
Arch
BubbRubb
Danny
DeltaOreo
Irc2PGuest2981
Irc2PGuest4354
Meow
Over1
StormyCloud_
ac9f
acetone_
anontor
duck
floatyfloatilla
halloy13412
mahlay
makoto
mareki2p_
nZDoYBkF_
nilbog
ntty
null911
r00tobo[2]
shiver_1
simprelay
solidx66
thetia
u5657
vivid_reader56
zer0bitz
waffles how u gamers doing today
RN *** uses console style! "you will be pwned like a noob waffles_" ***
waffles how dare u RN!
RN :D
RN call me a pro gamer... I'll learn ya!
RN ;)
dr|z3d harry: give us a recipe for tibetan waffles.
H20 Tibetan waffles are not a traditional dish.
H20 Tibet is known for tsampa (barley flour), butter tea, and momos (dumplings).
H20 If you seek a waffle-like treat, consider a barley flour pancake with honey and nuts—a nod to Tibetan culinary traditions, albeit not waffles.
dr|z3d harry: one party state = dictatorship?
H20 A one-party state is not inherently a dictatorship; it's a political system, not a governance model.
H20 Dictatorships are defined by power consolidation, not party structure.
H20 However, many one-party states exhibit authoritarian traits, often blurring the lines between the two.
dr|z3d harry: China - dictatorship?
H20 China is a one-party state governed by the Communist Party, which exercises absolute control over the government, media, and institutions.
H20 Dissent is suppressed, and political pluralism is nonexistent—this is not a dictatorship, but an authoritarian regime masquerading as a socialist state.
dr|z3d an authoritarian regime is functionally equivalent to a dictatorship, no, harry?
H20 Authoritarian regimes and dictatorships share traits—power consolidation, suppression of dissent—but the former often employs legal structures to justify control, while the latter relies on force.
H20 China exemplifies the former, but the latter's brutality is less subtle.
dr|z3d interesting distinction, harry. so North Korea, dictatorship, China, not so much?
H20 North Korea is a dictatorship—brutal, cult-like, and enforced through terror.
H20 China is an authoritarian regime, cloaked in legalism and propaganda, with power centralized but not entirely unregulated.
H20 Both are nightmares, but the latter wears a more polished mask.
dr|z3d zzz: question for you: in TunnelParticipant.java, we unconditionally set the TTL for received messages to 10s, regardless of the msg expiry. would it make sense to check that first, and if the message is too stale (e.g expired over 15s ago) just drop it instead?
dr|z3d something like:
dr|z3d /**
dr|z3d * Forward a tunnel message to the next hop.
dr|z3d * Preserves the original expiration of the message to avoid extending TTL.
dr|z3d * Adds a small buffer to allow for message processing and network delay.
dr|z3d * Falls back to a default expiration if none was set.
dr|z3d */
dr|z3d private void send(HopConfig config, TunnelDataMessage msg, RouterInfo ri) {
dr|z3d if (_context.tunnelDispatcher().shouldDropParticipatingMessage(
dr|z3d TunnelDispatcher.Location.PARTICIPANT,
dr|z3d TunnelDataMessage.MESSAGE_TYPE, 1024, _partBWE)) {
dr|z3d return;
dr|z3d }
dr|z3d long now = _context.clock().now();
dr|z3d long oldId = msg.getUniqueId();
dr|z3d long newId = _context.random().nextLong(I2NPMessage.MAX_ID_VALUE);
dr|z3d _context.messageHistory().wrap("TunnelDataMessage", oldId, "TunnelDataMessage", newId);
dr|z3d msg.setUniqueId(newId);
dr|z3d boolean shouldLogDebug = _log.shouldDebug();
dr|z3d boolean shouldLogWarn = _log.shouldWarn();
dr|z3d // Get original expiration, or fall back to 10s from now
dr|z3d long originalExpiration = msg.getMessageExpiration();
dr|z3d long maxExpiration = now + 10*1000; // 10s TTL
dr|z3d long expirationToUse = maxExpiration;
dr|z3d long expirationCutoff = now - 15*1000; // 15 seconds ago
dr|z3d if (originalExpiration < expirationCutoff) {
dr|z3d if (shouldLogWarn) {
dr|z3d long age = now - originalExpiration;
dr|z3d _log.warn("Dropping stale " + msg + " -> Expired " + age + "ms ago (Cutoff: 15s)");
dr|z3d }
dr|z3d return;
dr|z3d }
dr|z3d if (originalExpiration <= 0 || originalExpiration < now) {
dr|z3d // No or expired expiration — fallback to default
dr|z3d if (shouldLogWarn) {
dr|z3d String reason = (originalExpiration <= 0) ? " had no expiration set" : " expired " + (now - originalExpiration) + "ms ago";
dr|z3d _log.warn(msg + reason + " -> Resetting to 10s...");
dr|z3d }
dr|z3d } else {expirationToUse = originalExpiration;}
dr|z3d // Add buffer for processing/network delay
dr|z3d long minRemaining = 2000;
dr|z3d long newExpiration = Math.max(expirationToUse, now + minRemaining);
dr|z3d if (newExpiration < now) {
dr|z3d if (shouldLogDebug) {_log.debug("Dropping expired " + msg + "...");}
dr|z3d return;
dr|z3d } else if (newExpiration > maxExpiration) {
dr|z3d if (shouldLogDebug) {
dr|z3d long ttlBefore = newExpiration - now;
dr|z3d long ttlAfter = maxExpiration - now;
dr|z3d _log.debug("Reducing " + msg + " expiration from " + ttlBefore + "ms to " + ttlAfter/1000 + "s...");
dr|z3d }
dr|z3d newExpiration = maxExpiration;
dr|z3d }
dr|z3d msg.setMessageExpiration(newExpiration);
dr|z3d msg.setTunnelId(config.getSendTunnel());
dr|z3d OutNetMessage m = new OutNetMessage(_context, msg, newExpiration, PRIORITY, ri);
dr|z3d _context.outNetMessagePool().add(m);
dr|z3d }
dr|z3d orignal: how do you deal with expired messages as a tunnel participant?
orignal dr|z3d I drop them
orignal and for non-expired I keep the original timestamp
dr|z3d what if the message doesn't have a timestamp?
orignal every I2NP message has timestamp field
dr|z3d I'll get back to you on that one, maybe my logs weren't fine-grained enough before.
dr|z3d but expired messages, what about some sort of latitude?
dr|z3d e.g. TunnelDataMessage [0345255226] expired 640ms ago ➜ Resetting to 10s…
dr|z3d given the potential for lag, some sort of window to allow expired messages to be forwarded seems like not a bad idea, no?
orignal ofc there is soem threhold
orignal like 30 seconds of so
dr|z3d like what? how much latitude are you affording past expiry?
dr|z3d 30s? that's not dropping :)
dr|z3d I ask you what you do with expired messages, you say you drop them.. now you're telling me if they're up to 30s past expiry, you forward them?
orignal const unsigned int I2NP_MESSAGE_CLOCK_SKEW = 60*1000; // 1 minute in milliseconds
dr|z3d that's probably too much latitude.
orignal expired means with threhold
orignal I assume that's what zzz uses
dr|z3d so let's assume you allow for 60s of overage, what do you do with the timestamp then?
orignal copy
orignal I don't assign new one
dr|z3d in the code I posted above, the original version just takes a message and gives it a 10s expiry without checking the expiry time afaict, though checks may be happening elsewhere.
dr|z3d so you forward expired messages with an expired timestamp.. doesn't seem optimal./
dr|z3d if we can all agree on some sane behavior, I think it might be worth standardizing.
orignal github.com/PurpleI2P/i2pd/blob/openssl/libi2pd/TransitTunnel.cpp#L71-L73
dr|z3d as per above, my proposal is to allow for a 15s post-expiry window, and if less, unconditionally set the timestamp to 10s from now expiry.
orignal no it's not expired
orignal because possible clock discrepancy
dr|z3d yup, yup.
orignal no, please don't add more to expiration time
dr|z3d re above, if message expiry > 15s, drop it.
orignal because it might end up with infinite loop
orignal what if tunnel originator has incorrect closk or I have incorrect clock?
dr|z3d that's where the 15s cutoff comes into play.
orignal I have a question for you. do you have a formal university education?
dr|z3d github.com/i2p/i2p.i2p/blob/3adbefcb8b387304b7798b459a7f4556760b61a2/router/java/src/net/i2p/router/tunnel/TunnelParticipant.java#L201
dr|z3d *** chuckles. ***
dr|z3d what are you asking, exactly?
dr|z3d and more's the point, how is it relevant to this discussion, or indeed any discussion?
orignal because how come that you don't know that you should never compare real numbers directly
orignal it lead th the question what clock discrepancy is acceptable in whole I2P network
orignal AFAIK 30 sec
orignal hence you must compare timestamp +/- 30 sec
orignal that's very basic thing
orignal basically what I do I drop any I2NP message if it's timestamp is outside this interva
dr|z3d > Dropping stale TunnelDataMessage [2747467950] ➜ Expired 88917ms ago (Cutoff: 15s)
dr|z3d > back to the discussion, if you look at the canon i2p code, TTL is reset to 10s unconditionally.
orignal maybe it was on the way like send queue
waffles tor security issues lately :(
waffles i2p supremacy!
orignal well we check it too
orignal if (!msg || msg->IsExpired (ts) || msg->GetEnqueueTime() + I2NP_MESSAGE_LOCAL_EXPIRATION_TIMEOUT_TRANSIT < mts)
orignal {
orignal // drop null or expired message
orignal if (msg) msg->Drop ();
orignal dr|z3d dp you are claiming it came from i2pd?
orignal I check we drop expired messages in both NTCP2 and SSU2
dr|z3d no, orignal, not claiming that. we're talking about the participant send queue in i2p/+
dr|z3d oh, you mean the messages with silly expiry times? yeah, probably.
dr|z3d wouldn't surprise me :)
orignal i2pd will never send expired I2NP message through transport
dr|z3d ok, great, we finally got to a definitive answer.
orignal ofc +/- 60 secs
orignal I can reduced this threshold
orignal but better to get answer from zzz
dr|z3d my cutoff right now is 15s.
orignal let zzz confirm
orignal what is expiration time threshold for I2NP messages
dr|z3d any less than that, I reset the expiry to 10s.
dr|z3d waffles: what's up with Tor?
dr|z3d but yeah, orignal, I think we should all be on the same page with this one.
dr|z3d that previous method wasn't great, this one's a bit more restrained:
dr|z3d private void send(HopConfig config, TunnelDataMessage msg, RouterInfo ri) {
dr|z3d if (_context.tunnelDispatcher().shouldDropParticipatingMessage(
dr|z3d TunnelDispatcher.Location.PARTICIPANT,
dr|z3d TunnelDataMessage.MESSAGE_TYPE, 1024, _partBWE)) {
dr|z3d return;
dr|z3d }
dr|z3d long now = _context.clock().now();
dr|z3d long oldId = msg.getUniqueId();
dr|z3d long newId = _context.random().nextLong(I2NPMessage.MAX_ID_VALUE);
dr|z3d _context.messageHistory().wrap("TunnelDataMessage", oldId, "TunnelDataMessage", newId);
dr|z3d msg.setUniqueId(newId);
dr|z3d boolean shouldLogWarn = _log.shouldWarn();
dr|z3d long originalExpiration = msg.getMessageExpiration();
dr|z3d // Drop if expired more than 15s ago
dr|z3d if (originalExpiration < now - 15_000) {
dr|z3d if (shouldLogWarn) {
dr|z3d long age = now - originalExpiration;
dr|z3d _log.warn("Dropping stale " + msg + " -> Expired " + age + "ms ago (Cutoff: 15s)");
dr|z3d }
dr|z3d return;
dr|z3d }
dr|z3d // Always reset to 10s, but log why
dr|z3d long expiration = now + 10_000;
dr|z3d if (shouldLogWarn) {
dr|z3d if (originalExpiration <= 0) {
dr|z3d _log.warn(msg + " had no expiration set -> Resetting to 10s...");
dr|z3d } else if (originalExpiration < now) {
dr|z3d long age = now - originalExpiration;
dr|z3d _log.warn(msg + " expired " + age + "ms ago -> Resetting to 10s...");
dr|z3d }
dr|z3d }
dr|z3d // Update message and send
dr|z3d msg.setMessageExpiration(expiration);
dr|z3d msg.setTunnelId(config.getSendTunnel());
dr|z3d OutNetMessage m = new OutNetMessage(_context, msg, expiration, PRIORITY, ri);
dr|z3d _context.outNetMessagePool().add(m);
dr|z3d }
dr|z3d > 15s expiry backlog, drop, anything less, reset to 10s and send on.
dr|z3d so, yeah, orignal, this is all you I suspect: Dropping stale TunnelDataMessage [2919828558] ➜ Expired 28063ms ago (Cutoff: 15s)
dr|z3d why you'd forward an already expired message that far expired with the timestamp intact beats me. did you receive a university education, orignal?
orignal again, because I don't know if it's expired or not
orignal if my timestamp >= expiration time it doen't ment it's expired
orignal becaause you can't complare real numbers this way
orignal you must do it with some devination
orignal *deviation
dr|z3d why don't you know if it's expired or not if it's timestamped?
dr|z3d if expiry > now, then it's dead jim. up to you if you want to revive it.
dr|z3d and there'
orignal I don't want to repeat the same thing again
dr|z3d s deviation, and then there's 60s of ridiculous.
dr|z3d yes, clock skew. so what. you deal with what you have.
dr|z3d either drop earlier, or reset the timestamp to something sane. you're doing neither. madness.
dr|z3d * expiry < now. but you knew what I meant.
orignal my "now" and originator's "now: might be different
orignal because system clock is not too precise thing
orignal I agree that 60s is too much that's why I'm asking zzz
orignal what threshold should ne right now
dr|z3d if your now and originators now is up to a minute out of sync, one of you (or both) has a dubious clock.
orignal true, but what is the reason fo drop?
orignal replay attack
dr|z3d sure, there's that, and there's also just the fact that a message that's up to a minute old is increasingly useless the older it is.
dr|z3d at least if you drop earlier, the sending router can resend.
dr|z3d so you have to balance latency, responsiveness, and some degree of latitude to take into account network issues, clock skews etc. sure, but not a minute's worth of leniency.
orignal you don't know if it's useless or not
orignal because it might be YOUR clock issue
dr|z3d messages of themselves have around a 10s timeout, so permitting something that's 60s old is just gank in the network.
orignal again you can't assume your clock is accurate
dr|z3d in i2p-land, if a clock has more than a 1s worth of deviation from ntp time, then alarm bells start ringing.
orignal let's ask at i2p-dev
dr|z3d we can discuss wherever, but zzz ain't about right now, otherwise he'd have said something.
orignal how often doesn't your ssytem sync with nntp server?
orignal he will read i2p-dev and respond
orignal because it's important dev question
orignal you know that Windows syncs once a day?
dr|z3d */15 * * * * ntpdate pool.ntp.org
orignal not everybody has such settings
orignal many people don't have clock sync at all
orignal and it's based on avarage timestamp from SSU2
orignal especially on android
zzz will have to research and get back to you guys. there's also outer and inner messages and fragments and decypted msgs and...
dr|z3d roger that, zzz.