Need architectural validation

I am trying to create a rendezvous service and a client in go and libp2p. Using these brain-dead AI coding engines is worthless as you can ask five questions and get different and conflicting responses each time. Supremely frustrating.

What I need to do is the following:

  1. Create the rendezvous service.
    a) The rendezvous service will run on a public server that will have a known static IP address and port.
    b) Generate the host with a static peer ID.
    i) I have written a utility to generate a self-signed SSL certificate so that I can use the public key to create a peer ID.
    ii) This is necessary for all clients that wish to interact with the rendezvous service.
    iii) The peer ID needs to be static so that it can be used by all clients who will not know the rendezvous service’s ID when it first starts up.
    iv) Also, the clients will most likely be behind NAT devices so reaching out into the ether is not an option.
    c) Using the host that was created with the static IP address, port number, and peer ID, bootstrap a DHT to the host.
    d) Create a handler to register new clients (registration transaction).
    e) Create a handler to service queries by clients wishing to connect to other remote peers (find peer transactions).
    f) The rendezvous service will run forever.
  2. Create a peer client.
    a) Connect to the rendezvous service described above (registration transaction).
    b) Request the ID(s) of a remote peer(s) (find peer transaction).
    c) The client will need to establish a listener to receive incoming connection requests, chat messages, and file transfers.
    d) Connect one peer to the other peer(s) through a hole punch operation so that all of the peers are directly connected regardless of having a public or private (behind a NAT device) IP address.
    e) Give the peers the ability to send and receive chat messages.
    f) Give the peers the ability to send files.
    g) Give the peers the ability to send media files.
    h) When a client changes something in their public profile, give the peers the ability to update other peers who have subscribed to remote peer profile update transactions.
    i) The peer client will run forever.

First off, where am I all wet? Is this the correct approach? Is there any documentation that describes a typical rendezvous server/peer group topology? Is there any trick to load-balancing the rendezvous service as I am assuming I don’t want to have thousands of users all using one rendezvous server. I have looked at most of the examples but none that I have found use more than one computer to demonstrate connections. Doing all of this on one computer does not demonstrate anything remotely P2P so why are those the only examples?