WebSockets rewrite

[scripting]

There have been problems over time with the WebSocket functionality in WordLand and wpIdentity. But I think I've gotten it stabilized, and since @scotthansonde was involved in this, a long time ago, I thought I should close the loop.

1. I rewrote wsConnectUserToServer in api2.js to wait 10 seconds between retries after a failed connection, and to only try 100 times, and after that it gives up. You can reload the page to get another set of tries. Previously it waited 1 second and retried indefinitely.
2. I switched the websockets package wpIdentity was using from nodejs-websocket to ws. This was based on advice I got from ChatGPT and Claude.ai, saying that nodejs-websocket was not being maintained, and the gold standard for everyone was ws.
3. I changed the Caddy config file on the server, per the advice of ChatGPT, to make sure that failed WS connections didn't fall back to HTTP connections, which is what I was seeing in the logfile, along with the steady stream of errors in the user's JS console (this came up the other day in a bug report on the wordlandSupport repo issues list.

The result? It's much calmer in the server log. This is kind of mysterious, I didn't expect it to settle down so quickly because there must have been some old clients out there reconnecting every second?

The new Caddy file

{
  on_demand_tls {
    ask http://localhost:1339/isdomainvalid
  }
}

https:// {
  tls {
    on_demand
  }

  @websocketsWordlandSocial {
    host wordland.social
    header Connection *Upgrade*
    header Upgrade    websocket
  }

  @httpWordlandSocial {
    host wordland.social
  }

  reverse_proxy @websocketsWordlandSocial localhost:1502
  reverse_proxy @httpWordlandSocial localhost:1339

  # Optional: fallback for other domains
  reverse_proxy localhost:1339
} 

Screen shot of server log with a client trying to connect every second

[scripting]

Update -- the method described above didn't work. Spent most of a day trying options to get Caddy to redirect websocket requests, without luck. So I took another approach that doesn't involve using Caddy, I added code to my server, PagePark, that ignores WebSocket messages that are being sent to the HTTP server. It doesn't pass them on to the HTTP request handler, doesn't log them, and returns a 400 error to the caller.

The need to do all this was because an earlier version of api2.js never stopped trying to establish a connection. Big mistake. Now it times out after 100 attempts, and it spaces the attempts out by 10 seconds instead of what it was previously, 1.