auth system? #83

New Issue

sneak · 2026-03-18T03:41:48+01:00

sneak commented

2026-03-18 03:41:48 +01:00

explain to me how auth works. i have a session. i have a client connected. how do i set a password so i can access it from another client?

clawbot was assigned by sneak

2026-03-18 03:41:56 +01:00

clawbot commented

2026-03-18 03:42:43 +01:00

How Auth Works

There are two paths:

1. Anonymous Session (no password, single-client)

POST /api/v1/session {"nick":"alice"}
→ {"id":1, "nick":"alice", "token":"a1b2c3..."}

You get a token. That token IS your identity. There's no password, no way to log in from another client. If you QUIT or the session expires, it's gone.

2. Registered Account (password, multi-client)

POST /api/v1/register {"nick":"alice", "password":"s3cret!!"}
→ {"id":1, "nick":"alice", "token":"a1b2c3..."}

This creates a session with a bcrypt-hashed password. Now you can log in from another device:

POST /api/v1/login {"nick":"alice", "password":"s3cret!!"}
→ {"id":1, "nick":"alice", "token":"d4e5f6..."}

Login adds a new client to the existing session — same nick, same channel memberships, but a separate message delivery queue and token. Both devices receive all messages independently.

The Gap: Anonymous → Registered

If you created a session via POST /api/v1/session (anonymous, no password), there is currently no way to set a password after the fact. You cannot convert an anonymous session into a registered one. You'd have to QUIT and re-create via /register.

There's also no "change password" endpoint.

Session Lifecycle Caveat

Both anonymous and registered sessions are deleted when all clients disconnect (QUIT or logout). Registration does NOT make a session survive all-client removal. If you register, log in from two devices, then QUIT from both — the session is destroyed and the nick is released. You'd need to re-register.

So to answer your question directly: If you already have an anonymous session and want multi-client access, you can't — there's no POST /api/v1/set-password or equivalent. You'd need to have used /register instead of /session when creating it.

Want me to create an issue for a "set password on existing session" endpoint? That would let anonymous sessions upgrade to registered ones.

## How Auth Works There are two paths: ### 1. Anonymous Session (no password, single-client) ``` POST /api/v1/session {"nick":"alice"} → {"id":1, "nick":"alice", "token":"a1b2c3..."} ``` You get a token. That token IS your identity. There's no password, no way to log in from another client. If you QUIT or the session expires, it's gone. ### 2. Registered Account (password, multi-client) ``` POST /api/v1/register {"nick":"alice", "password":"s3cret!!"} → {"id":1, "nick":"alice", "token":"a1b2c3..."} ``` This creates a session with a bcrypt-hashed password. Now you can log in from another device: ``` POST /api/v1/login {"nick":"alice", "password":"s3cret!!"} → {"id":1, "nick":"alice", "token":"d4e5f6..."} ``` Login adds a **new client** to the **existing session** — same nick, same channel memberships, but a separate message delivery queue and token. Both devices receive all messages independently. ### The Gap: Anonymous → Registered If you created a session via `POST /api/v1/session` (anonymous, no password), there is currently **no way to set a password after the fact**. You cannot convert an anonymous session into a registered one. You'd have to QUIT and re-create via `/register`. There's also no "change password" endpoint. ### Session Lifecycle Caveat Both anonymous and registered sessions are **deleted when all clients disconnect** (QUIT or logout). Registration does NOT make a session survive all-client removal. If you register, log in from two devices, then QUIT from both — the session is destroyed and the nick is released. You'd need to re-register. --- **So to answer your question directly:** If you already have an anonymous session and want multi-client access, you can't — there's no `POST /api/v1/set-password` or equivalent. You'd need to have used `/register` instead of `/session` when creating it. Want me to create an issue for a "set password on existing session" endpoint? That would let anonymous sessions upgrade to registered ones.

clawbot removed their assignment 2026-03-18 03:43:02 +01:00

sneak was assigned by clawbot

2026-03-18 03:43:02 +01:00

sneak commented

2026-03-18 04:06:07 +01:00

ok, remove the registration path. there is no registration, just the ability to set a session password from an existing session, so that additional clients can connect. yes, add the session password setting.

normally we would integrate it into the irc protocol somehow but in this case we want the result to set a cookie for the client so it should be its own route.

there is no need for a “token” - per-request auth should be with cookies. setting up a new client (which happens obviously when setting up a new session) should cookie that client.

ok, remove the registration path. there is no registration, just the ability to set a session password from an existing session, so that additional clients can connect. yes, add the session password setting. normally we would integrate it into the irc protocol somehow but in this case we want the result to set a cookie for the client so it should be its own route. there is no need for a “token” - per-request auth should be with cookies. setting up a new client (which happens obviously when setting up a new session) should cookie that client.

sneak removed their assignment 2026-03-18 04:06:16 +01:00

clawbot was assigned by sneak

2026-03-18 04:06:16 +01:00

sneak commented

2026-03-18 04:07:30 +01:00

actually that’s not right. the client will already have a cookie from session creation which creates the first client. the session reconnection password can indeed be set via irc command.