Add userData to dht.announce()

Proposal

I suggest adding userData field to peer encoding.

{
      publicKey: c.fixed32.decode(state),
      relayAddresses: ipv4Array.decode(state),
      userData: c.buffer.decode(state),
}

Reasoning

My understanding is that upon making dht.lookup request, applications can expect up to 400 random peers.

With no further information, apps are left with the only option of connecting to all these peers before making any judgment on whether they are honest, authorized, or spam, or which peers are most likely to have what they need.

Each of these connections requires the DHT to facilitate the hole-punching, if the client isn't already connected or blocked these peers.

Adding userData would allow applications to make this app-specific judgment, helping them minimize their load on the DHT.

Use cases

Some use cases from the top of my head:

Spam protection, as clients prioritize servers with proper attestations from the source author, either direct or delegated.
Announcing alternative transports servers may support. That is helpful for:
- Allow skipping hole-punching for servers with publicly accessible addresses.
- Browsers can use DHT relays only for lookup, then connect through advertised HTTP/Websocket servers.
L2 overlay networks, that use the DHT for what it is good for, but then offer more features like persistent records, and experiment with defensive measures to fight abuse, including computation cost, or fees etc. where the userData relays all the required proofs. All without needing any involvement from the DHT.

Why not mutablePut

For all the reasons why we need swarm.join in the first place: capabilities vs ACL. This proposal would enable async capabilities for applications that can afford static proofs, as opposed to requiring a handshake.

Also, mutablePut can only accept Ed25519 signatures, while in userData you can attach attestations signed according to any scheme the application layer supports.

examples

Seeders of Hypercores, pointing to alternative supported transports + showing a delegation proof from the author of the core, in this example the core is using secp256k1 instead of ed25519 in the auth function, which is not possible with something like https://github.com/holepunchto/hyperswarm-seeders:

{
"alternative_endpoints": {
  "WebSocket": ["wss://foo.example.com", "wss://example.org:8080"],
  "WebTransport": ["https://example.com:4999/wt"],
  "QUIC": ["https://example.com:5000"],
},
"author_attestation": {
  "attestation": {
      "seeder": <key>,
      "ttl": <timestamp>,
      "priority": 1,
   },
  "keyType": "secp256k1",
  "signature": <signature>,
},
}

Risk

~I assume the only risk here is the same as in mutablePut, namely spam. Demanding a max size for userData should help here, but it this proposal doesn't assume how should the DHT fight the abuse of both. Only that it doesn't introduce a new attack vector that doesn't already exist with mutablePut.~ Apparently there is an implicit max size anyways, so doesn't seem anymore abusable than mutablePut https://gist.github.com/Nazeh/ce4475b1a7c668db064beb326f915eed

~I don't think this would be a breaking change either.~ Trying to keep m.peer somewhat backward compatible is proving to be too complicated, this will probably need to be a major version.

holepunchto / hyperdht