But it’s not a matter of whether only the sender gets these latency values, the issue is that it incentivizes routing nodes to be as fast as possible to be picked up by senders and thus removes our ability to introduce random delays in the future, because the incentives will be against them.
It’s true that we haven’t implemented yet those privacy features (random delays / message padding), but we’ve made sure that nothing prevented us from adding them whenever we had time to work on them. Creating an incentive against them would be a big change that I’m afraid we wouldn’t be able to fix afterwards.
I believe you misunderstood my comment here. We are of course building software for routing nodes, but it doesn’t make sense to build features they only use for fun that don’t have a useful impact on the network. There are a lot of things that routing nodes think they want (most of the time the small ones that are mostly tinkering) that are either useless or harmful, and I don’t think we should provide them, even though some people are asking for it. They’re free to implement them anyway and document them in bLIPs, but I’m pretty sure they’ll realize it’s not worth the effort. But it’s a good thing that they can do it because it’s open-source software, and then they can prove me wrong!
I completely agree with that.