Board URLs: stable keys instead of database ids #197

New issue

Closed

opened 2026-09-18 17:12:51 +00:00 by Grandiras · 0 comments

Grandiras commented

2026-09-18 17:12:51 +00:00

Owner

Part of #190; not urgent, and cheaper the earlier it happens.

Boards are addressed by database id — /board/3. That is fine for one Postgres and does not survive the move to lexicons, where a record is named by whose repository it is in and a record key, and where ids handed out by one deployment's sequence mean nothing. It also lets anybody count the boards on a deployment from the address bar, which mattered less when an admin made all four of them.

Give Board a stable, non-sequential key (a TID is the native choice and sorts by creation time) and address boards by it. ShareLink is already the one place that writes a URL and the one place that reads one back, which is most of why this is small.
Migrating: every existing board gets a key in the migration; /board/{int} and the other id-carrying routes keep resolving and redirect to the keyed address, because those links are in chats and bookmarks and in ponente-last-page cookies. Both .ics endpoints take a board query (CalendarScope) that calendar apps have subscribed to — those must keep working unchanged, not redirect.
Columns, cards and comments will want the same eventually; boards are the only ones in URLs, so they are the only ones that need it now.

Worth noting while here, not fixing: positions are double midpoints (ColumnService, BoardService.MoveAsync), and the atproto data model has no floats. They will need to be fractional-index strings or integers before they can be records.

Part of #190; not urgent, and cheaper the earlier it happens. Boards are addressed by database id — `/board/3`. That is fine for one Postgres and does not survive the move to lexicons, where a record is named by whose repository it is in and a record key, and where ids handed out by one deployment's sequence mean nothing. It also lets anybody count the boards on a deployment from the address bar, which mattered less when an admin made all four of them. - Give `Board` a stable, non-sequential key (a TID is the native choice and sorts by creation time) and address boards by it. `ShareLink` is already the one place that writes a URL and the one place that reads one back, which is most of why this is small. - **Migrating:** every existing board gets a key in the migration; `/board/{int}` and the other id-carrying routes keep resolving and redirect to the keyed address, because those links are in chats and bookmarks and in `ponente-last-page` cookies. Both `.ics` endpoints take a `board` query (`CalendarScope`) that calendar apps have subscribed to — those must keep working unchanged, not redirect. - Columns, cards and comments will want the same eventually; boards are the only ones in URLs, so they are the only ones that need it now. Worth noting while here, not fixing: positions are `double` midpoints (`ColumnService`, `BoardService.MoveAsync`), and the atproto data model has no floats. They will need to be fractional-index strings or integers before they can be records.

Grandiras referenced this issue

2026-09-18 17:12:51 +00:00

Lexicons for boards, for when ATProto Spaces is stable #198

Grandiras referenced this issue

2026-09-18 17:13:03 +00:00

Member-owned boards and a home page: decisions and order of work #190

Grandiras referenced this issue from a commit

2026-09-22 19:42:22 +00:00

Address boards by a stable key instead of their database id

Grandiras referenced this issue from a pull request that will close it,

2026-09-22 19:42:36 +00:00

Address boards by a stable key instead of their database id #213