Rooms implementation does not seem to work #140

New Issue

2026-10-27T09:35:15+01:00

adam commented

2026-10-27 09:35:15 +01:00

After creating a room, it seems like the key to reference the room does not work.

The send advert button works, but the messages view throws an error that the room does not exist, sending a message via the webui yields the same error:

Example: /api/room_post_message

{"room_name":"BBS","message":"test","author_pubkey":"server"}

Gives the response

{
    "success": false,
    "error": "Invalid author_pubkey: Room 'BBS' not found"
}

After creating a room, it seems like the key to reference the room does not work. The send advert button works, but the messages view throws an error that the room does not exist, sending a message via the webui yields the same error: Example: `/api/room_post_message` ``` {"room_name":"BBS","message":"test","author_pubkey":"server"} ``` Gives the response ``` { "success": false, "error": "Invalid author_pubkey: Room 'BBS' not found" } ```

adam commented

2026-10-27 09:35:16 +01:00

Hit the same thing on our deployment (dev @ c7157d2, two rooms in production) and can offer a diagnosis:

The runtime registers and looks up rooms by the identity name (room_servers[].name), not by settings.node_name. If your identity is called e.g. RoomServer and the node_name is BBS, then room_name=BBS returns "room does not exist" even though the room runs fine. Observed on /api/room_messages, /api/room_clients, /api/room_post_message, and /api/room_stats (stats also reports room_name as the identity name, which is how we spotted it).

Workarounds that work today:

query by room_hash=0xNN instead of room_name (first byte of the room identity pubkey, unambiguous), or
keep name and settings.node_name identical in the config.

Two adjacent gotchas we hit while debugging this, in case they help:

/api/room_post_message requires author_pubkey to be a full 64-hex pubkey — a placeholder like "server" is rejected. Posting with a real pubkey (we used the room's own) works and the message is queued for distribution.
The advert path reads settings.room_name while the scheduler and HTTP endpoints read settings.node_name — when the two differ, a single advert renames the room on the mesh to the identity-name fallback. We keep both keys identical as a workaround; happy to send a small PR unifying this.

Hit the same thing on our deployment (dev @ c7157d2, two rooms in production) and can offer a diagnosis: **The runtime registers and looks up rooms by the *identity* `name` (`room_servers[].name`), not by `settings.node_name`.** If your identity is called e.g. `RoomServer` and the node_name is `BBS`, then `room_name=BBS` returns "room does not exist" even though the room runs fine. Observed on `/api/room_messages`, `/api/room_clients`, `/api/room_post_message`, and `/api/room_stats` (stats also *reports* `room_name` as the identity name, which is how we spotted it). Workarounds that work today: - query by `room_hash=0xNN` instead of `room_name` (first byte of the room identity pubkey, unambiguous), or - keep `name` and `settings.node_name` identical in the config. Two adjacent gotchas we hit while debugging this, in case they help: - `/api/room_post_message` requires `author_pubkey` to be a full 64-hex pubkey — a placeholder like `"server"` is rejected. Posting with a real pubkey (we used the room's own) works and the message is queued for distribution. - The advert path reads `settings.room_name` while the scheduler and HTTP endpoints read `settings.node_name` — when the two differ, a single advert renames the room on the mesh to the identity-name fallback. We keep both keys identical as a workaround; happy to send a small PR unifying this.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/pyMC_Repeater#140