use a random string as peer-name in mDNS

[marten-seemann]

We don't use the <peer-name> for anything, we only should make sure that there's no collision in the network (I think). This was part of the initial design requirements: https://github.com/libp2p/libp2p/issues/28 (Proposal section).

Instead of figuring out how to best encode a peer ID such that it fits into 63 characters, a problem we've struggled with for a very long time, we can just admit that we're only filling this field because the RFC requires us to do so, and use random garbage.

[dvc94ch]

The problem is a different one. Why are peer ids allowed to be longer than 63 characters. Also the name can be segmented using the DNS segmentation algorithm if I recall. rust-libp2p does this.

[aschmahmann]

Why are peer ids allowed to be longer than 63 characters

AFAIK this is only possible if someone decides to encode peerIDs as CIDs using a base smaller than 36. Perhaps there's a reasonable argument for decoupling here in the event that at some point it became necessary to switch the hash function used for keys to be something longer than sha2-256 that won't fit into a lowercase encoding.

Also the name can be segmented using the DNS segmentation algorithm if I recall

What do you mean? Is there an example or a spec I can look at?

[dvc94ch]

something longer than sha2-256 that won't fit into a lowercase encoding

so you mean a 512 bit hash for pq security?

What do you mean? Is there an example or a spec I can look at?

so according to the spec a label is 63 characters [0]. rust-libp2p [1] works around it by splitting a peer_id longer than 63 characters into multiple labels and joining them as subdomains with a ..

• [0] https://datatracker.ietf.org/doc/html/rfc1035
• [1] https://github.com/libp2p/rust-libp2p/blob/5ef430b8d8d390c904440043f6a8d8bb83b68507/protocols/mdns/src/dns.rs#L265

[aschmahmann]

so you mean a 512 bit hash for pq security?

There are a variety of reasons I could imagine someone proposing a change in the hash function, but yes e.g. someone wanting a 512 bit one.

rust-libp2p [1] works around it by splitting a peer_id longer than 63 characters into multiple labels and joining them as subdomains with a .

Ah, ya. I'm not sure what the tradeoffs are here. It might just work in the mDNS case, but I'm not sure what types of things the tooling around mDNS expects. We have a similar problem in go-ipfs (https://github.com/ipfs/go-ipfs/issues/7318) where the . splitting isn't a great solution basically because no one will grant *.*.mydomain certificates even though it seems like the kind of thing that's reasonable and not a spec problem.

[dvc94ch]

In any case that seems like an ipfs problem. Not sure why getting TLS certificates from some CA for . split peer IDs has anything to do with libp2p.

[aschmahmann]

Yes. My point was just that there is already evidence that DNS tooling exists that won't be happy with arbitrary . splits. It might not be a big deal in most mDNS contexts, but wanted to flag that it's not quite as simple as "works on my machine".

[dvc94ch]

My suggestion would be to leave it as is and design your own protocol once you have the bandwidth. The libp2p-mdns seems shoe horned onto an mdns spec. You can probably build something much simpler for discovering peers and their addresses in local networks using multicast, at least in terms of the packet format.

[dvc94ch]

It might not be a big deal in most mDNS contexts, but wanted to flag that it's not quite as simple as "works on my machine".

Actyx has deployed the rust-libp2p mdns on Android/windows/Linux in the mission critical context of factories. I think it's pretty clear that it works on more than just my machine

[aschmahmann]

Is Actyx using the . delimited names? I'd think all their names would fit in the 63 character limit.

[dvc94ch]

Is Actyx using the . delimited names? I'd think all their names would fit in the 63 character limit.

Probably. But we also don't care about mdns compatibility. We only care about discovering other local rust-libp2p nodes, and I presume that's the sentiment of many rust-libp2p users.

[marten-seemann]

I was trying to avoid having to solve the problem of how to map peer IDs to subdomains. We've had this discussion for a long time, with no clear solution so far. I suggest we don't try to solve this problem here, because for mDNS, we don't need to solve it.

All we need for mDNS is a unique identifier shorter than 64 characters, and this PR suggests the (probably) easiest solution to achieve this property.

[dvc94ch]

I guess it's backwards compatible with existing implementations as long as they use peer ids shorter than 64 characters

[mxinden]

Could you bump the spec version @marten-seemann?

Friendly ping :)