Onion Message Rate Limiting: Should implementations coordinate to avoid fingerprinting?

[Abdulkbk]

While testing onion message interoperability across implementations, I noticed that each implementation handles the "MAY rate-limit messages" guidance in BOLT04 quite differently. I'm curious whether this divergence is intentional or if there's value in coordinating behavior.

From BOLT04, the reader:

MAY rate-limit messages by dropping them.

This gives implementations freedom, but I wonder if that freedom creates unintended consequences. For example, what I observed forwarding onion messages from LND -> CLN, I received a warning:

Received Warning(chan_id=0000000000000000000000000000000000000000000000000000000000000000, err=Ratelimited onion_message: exceeded one per 250msec) from 024bfcddde03d74d0e9126701a42da9f944eed94c20a9b9cc0680b0be0d71b01bf@172.18.0.2:9735

This reveals the peer's implementation, and since onion messages are intended to enhance privacy, I wonder whether this is a concern.

[TheBlueMatt]

Peers are already highly fingerprint-able via feature bits. The cases where we care about fingerprint-resistance are primarily just nodes in blinded paths, which this doens't impact.