And again, NIP-42 requires domain name validation. So #bostr could not use NIP-42 for public usage. 

 I am rather questioning the privacy at multiplextr than in #bostr as it tell to coracle that the event was sent from "that" relays, and then coracle sign the AUTH for "that" relays also. 

 Yes, multiplextr absolutely has the privacy problem you're describing. The advantage it has is it allows clients to implement routing. 

 In config.js, You put your public key in `authorized_keys` array. After restart, bostr will only allow users in `authorized_keys` to use the bouncer.

However, You need to ensure that NIP-42 is supported in your client. Otherwise the bouncer will not doing anything for you during authentication.

Additionally, You could enable internal NIP-42 for NIP-42 relays for your own use by inserting public & private key in `private_keys`. 

 It works when left authorized -keys empty, but Every time I added key to authorized_keys, seems it doesn’t work.🤔️ 

 Did your client supports NIP-42? I've tested this funcion in #Amethyst client. 

 Ok,thanks. It work in snort web client. Seems most clients donot support nip-42. 

 By the way, about the bounce, can it bounce to local host, like ws://127.0.0.1:port  

 It could bounce to wherever you want to. 

 I think so, but failed🤔️ 

 How so?

If you want to debug, You could enable `log_about_relays` in config.js to see whenever the bouncer connects to your relay or no. 

 Sorry, saw the configuration in the file. Can whitelist

// For personal usage. Leaving this empty allows everyone to use this bostr instance.
  // NOTE: Requires NIP-42 on client.
  authorized_keys: [
    // "pubkey-in-hex",
    // "npub ....",
    // ....
  ],