RE: [EN/PT-BR] Horizon Forge: Updates and definition of version v1.0, plus the next focus.

Thanks for the question Angeluxx! I had already noted it down to review the security with the keychain login. Since you log in using the keychain extension, it's mandatory, but you can never be too careful, so I asked Claude Code to review the code and we implemented another layer of security:

Problem fixed:

The Keychain signature was being discarded — anyone could forge a session in sessionStorage and impersonate any player.

Implemented solution (4 files):

api/server.js:

POST /api/auth/verify — receives {username, memo, signature}, retrieves the public key from the account on the Hive blockchain, cryptographically verifies that the signature matches the memo using @hiveio/dhive, and issues an HMAC-SHA256 token valid for 24 hours. Middleware Socket.io (io.use) — validates the token in the handshake of each connection and populates socket.data.username. join_queue and rejoin_match — now use socket.data.username (defined by the middleware), completely ignoring the username sent by the client.

public/js/index.js:

After the Keychain signs, it POSTs to /api/auth/verify with {username, memo, signature: resp.result}. Only saves the session in sessionStorage if the server confirms — and includes the returned token. public/js/lobby.js:

Pass auth: { token: session.token } in the socket connection. Remove username from the join_queue payload (the server no longer accepts it).

public/js/battle.js:

Pass auth: { token: window._HF_SESSION?.token } in the PvP socket connection. Remove username from the rejoin_match payload.

What to add to the .env file:

XXXXXX=a_long_random_string_here

Without this, the server generates an ephemeral secret—it works, but tokens are invalidated upon restart. With AUTH_SECRET defined, sessions survive restarts.