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 clawbot2026-03-18 03:43:02 +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 sneak2026-03-18 04:06:16 +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.
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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?
How Auth Works
There are two paths:
1. Anonymous Session (no password, single-client)
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)
This creates a session with a bcrypt-hashed password. Now you can log in from another device:
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-passwordor equivalent. You'd need to have used/registerinstead of/sessionwhen 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.
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.
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.
and of course login (which creates a new client) sets a cookie.