feat: spaces, folder import, boards and mail; rename to narl-workspace

The diary grows into a workspace: a flat list of dated entries becomes a
tree of spaces, and the app is renamed to match what it now is.

Spaces and nodes
  One recursive `nodes` table replaces `entries`: a space is a root node,
  and folders and documents nest under it without limit. Entries keep
  their ids through the migration, so share tokens, media links and the
  drafts in localStorage all still resolve.

Folder import
  A folder or a zip is uploaded as a document tree. Markdown becomes
  documents titled from their first heading, everything else becomes
  media, and relative links between the imported files are rewritten to
  the paths they landed at, so a set of cross-linked notes stays
  navigable after the upload.

Boards
  A kanban board per space, with the space as the board: lists, cards,
  due dates and an optional link to a document. `diary` has none.

Mail
  SMTP notifications through an outbox. A mail is enqueued under a key
  naming the occurrence it belongs to, so a restart cannot resend and a
  relay that refuses is retried with a widening backoff. Four kinds: the
  diary reminder, cards due and overdue, a weekly digest, and logins
  from a browser that has not been seen before or a burst of failures.
  All of it is dormant until WORKSPACE_SMTP_URL is set.

Rename
  Everything user-visible says workspace; everything that already exists
  outside this repo keeps its name, because renaming it would break a
  running deployment for tidiness alone: the database file, the docker
  volume, the session cookie, the Proton device, the keyring entry and
  the localStorage keys. Configuration reads WORKSPACE_* first and falls
  back to DIARY_*, so the deployed .env keeps working untouched.
This commit is contained in:
nvrl committed 2026-09-18 14:53:22 +02:00
1 parent 76f0887ac5
commit 49b2056215
50 files changed
+5487 -972

No files matched your search

+103
View File
@@ -0,0 +1,103 @@
-- The diary grows sub-structures. A flat list of dated entries becomes a tree:
-- top-level spaces (diary, work, uni, ...), folders inside them to any depth,
-- and documents as the leaves. One recursive table holds all three, so a space
-- is simply a node without a parent and nesting costs nothing extra.
--
-- Ids are carried over unchanged. Share tokens already handed out, the
-- entry/media links and the `diary:draft:<id>` keys browsers hold in
-- localStorage all key on the entry id, and none of them can be rewritten from
-- here. The `diary` space therefore takes an id above every existing entry.
CREATE TABLE nodes (
id INTEGER PRIMARY KEY AUTOINCREMENT,
parent_id INTEGER REFERENCES nodes (id) ON DELETE CASCADE,
kind TEXT NOT NULL CHECK (kind IN ('space', 'folder', 'document')),
-- A document's title, a folder's or space's name.
name TEXT NOT NULL DEFAULT '',
-- URL-safe, unique among siblings: the path segment in /n/<space>/<slug>.
slug TEXT NOT NULL,
-- Documents only; folders and spaces keep it empty.
body TEXT NOT NULL DEFAULT '',
position INTEGER NOT NULL DEFAULT 0,
-- Spaces only. The diary is a journal, not a project, so it has no board.
has_board INTEGER NOT NULL DEFAULT 0,
created_at INTEGER NOT NULL,
updated_at INTEGER NOT NULL,
share_token TEXT UNIQUE,
share_key_hash TEXT
);
CREATE UNIQUE INDEX idx_nodes_parent_slug ON nodes (parent_id, slug);
CREATE INDEX idx_nodes_parent ON nodes (parent_id, position, created_at DESC);
CREATE INDEX idx_nodes_share_token ON nodes (share_token);
-- Same shape and same reasoning as entry_media in 0002: a file may be embedded
-- by more than one document, and deleting one of them must not take the file
-- away from the others.
CREATE TABLE node_media (
node_id INTEGER NOT NULL REFERENCES nodes (id) ON DELETE CASCADE,
media_id TEXT NOT NULL REFERENCES media (id) ON DELETE CASCADE,
PRIMARY KEY (node_id, media_id)
) WITHOUT ROWID;
CREATE INDEX idx_node_media_media_id ON node_media (media_id);
-- The three spaces to start from. Their ids sit above every entry id so the
-- documents below can keep theirs.
INSERT INTO nodes (id, parent_id, kind, name, slug, position, has_board, created_at, updated_at)
VALUES
((SELECT COALESCE(MAX(id), 0) FROM entries) + 1, NULL, 'space', 'diary', 'diary', 0, 0,
strftime('%s', 'now'), strftime('%s', 'now')),
((SELECT COALESCE(MAX(id), 0) FROM entries) + 2, NULL, 'space', 'work', 'work', 1, 1,
strftime('%s', 'now'), strftime('%s', 'now')),
((SELECT COALESCE(MAX(id), 0) FROM entries) + 3, NULL, 'space', 'uni', 'uni', 2, 1,
strftime('%s', 'now'), strftime('%s', 'now'));
-- Every entry becomes a document in the diary space, id intact. The slug
-- carries the day the entry is about and its id, which reads well in a URL and
-- cannot collide with a second entry written on the same day.
INSERT INTO nodes (id, parent_id, kind, name, slug, body, position,
created_at, updated_at, share_token, share_key_hash)
SELECT e.id,
(SELECT id FROM nodes WHERE parent_id IS NULL AND slug = 'diary'),
'document',
e.title,
date(e.created_at, 'unixepoch') || '-' || e.id,
e.body,
0,
e.created_at,
e.updated_at,
e.share_token,
e.share_key_hash
FROM entries e;
INSERT INTO node_media (node_id, media_id)
SELECT entry_id, media_id FROM entry_media;
-- Search follows. Folder and space names are indexed alongside document bodies,
-- because "where did I put that folder" is the same question as "where did I
-- write that sentence".
CREATE VIRTUAL TABLE nodes_fts USING fts5 (
name, body, content = 'nodes', content_rowid = 'id', tokenize = 'unicode61'
);
CREATE TRIGGER nodes_ai AFTER INSERT ON nodes BEGIN
INSERT INTO nodes_fts (rowid, name, body) VALUES (new.id, new.name, new.body);
END;
CREATE TRIGGER nodes_ad AFTER DELETE ON nodes BEGIN
INSERT INTO nodes_fts (nodes_fts, rowid, name, body) VALUES ('delete', old.id, old.name, old.body);
END;
CREATE TRIGGER nodes_au AFTER UPDATE ON nodes BEGIN
INSERT INTO nodes_fts (nodes_fts, rowid, name, body) VALUES ('delete', old.id, old.name, old.body);
INSERT INTO nodes_fts (rowid, name, body) VALUES (new.id, new.name, new.body);
END;
-- The rows above were inserted before the triggers existed.
INSERT INTO nodes_fts (nodes_fts) VALUES ('rebuild');
DROP TRIGGER entries_ai;
DROP TRIGGER entries_ad;
DROP TRIGGER entries_au;
DROP TABLE entries_fts;
DROP TABLE entry_media;
DROP TABLE entries;
+45
View File
@@ -0,0 +1,45 @@
-- A board per space, so "what am I working on" can be asked per space instead
-- of across everything at once. There is no board table: a space *is* its
-- board, and `nodes.has_board` decides whether the view exists. The diary is a
-- journal rather than a project and keeps that flag off.
CREATE TABLE board_lists (
id INTEGER PRIMARY KEY AUTOINCREMENT,
-- A space. Dropping the space drops its board with it.
space_id INTEGER NOT NULL REFERENCES nodes (id) ON DELETE CASCADE,
name TEXT NOT NULL,
position INTEGER NOT NULL,
created_at INTEGER NOT NULL
);
CREATE INDEX idx_board_lists_space ON board_lists (space_id, position);
CREATE TABLE cards (
id INTEGER PRIMARY KEY AUTOINCREMENT,
list_id INTEGER NOT NULL REFERENCES board_lists (id) ON DELETE CASCADE,
-- The document this card is about, if any. Deleting that document must not
-- delete the card: the work is still open, only its notes are gone.
node_id INTEGER REFERENCES nodes (id) ON DELETE SET NULL,
title TEXT NOT NULL,
body TEXT NOT NULL DEFAULT '',
due_at INTEGER,
done_at INTEGER,
position INTEGER NOT NULL,
created_at INTEGER NOT NULL,
updated_at INTEGER NOT NULL
);
CREATE INDEX idx_cards_list ON cards (list_id, position);
CREATE INDEX idx_cards_node ON cards (node_id);
-- The reminder mails in the next phase ask "what is due", which is a question
-- about every board at once.
CREATE INDEX idx_cards_due ON cards (due_at) WHERE due_at IS NOT NULL AND done_at IS NULL;
-- The three columns every board starts with, for the spaces that already exist.
INSERT INTO board_lists (space_id, name, position, created_at)
SELECT n.id, l.name, l.position, strftime('%s', 'now')
FROM nodes n
CROSS JOIN (SELECT 'backlog' AS name, 0 AS position
UNION ALL SELECT 'doing', 1
UNION ALL SELECT 'done', 2) l
WHERE n.parent_id IS NULL AND n.kind = 'space' AND n.has_board <> 0;
+37
View File
@@ -0,0 +1,37 @@
-- Mail is sent through an outbox rather than straight from the code that
-- decides a mail is due. Two reasons, both of which have bitten every reminder
-- that skips this step: a restart must not send yesterday's reminder again, and
-- a relay that is down for an hour must not lose the mail it refused.
--
-- `dedupe_key` carries the whole idea. It spells out *which* occurrence this is
-- ("reminder:2026-09-18", "card_due:41:2026-09-20:overdue"), so deciding
-- whether a mail was already sent is an insert that either takes or does not.
CREATE TABLE notifications (
id INTEGER PRIMARY KEY AUTOINCREMENT,
kind TEXT NOT NULL,
dedupe_key TEXT NOT NULL UNIQUE,
subject TEXT NOT NULL,
body TEXT NOT NULL,
created_at INTEGER NOT NULL,
sent_at INTEGER,
attempts INTEGER NOT NULL DEFAULT 0,
-- When the last attempt was made, which is what the backoff is measured
-- from; a count alone cannot say whether it is time to try again.
last_attempt_at INTEGER,
last_error TEXT
);
-- The sweep asks one question every minute: what is still unsent?
CREATE INDEX idx_notifications_pending ON notifications (created_at) WHERE sent_at IS NULL;
-- Which browsers have logged in. The hash is over the User-Agent, so this can
-- honestly say "a browser you have not used before", not "someone else" — and
-- it needs no proxy header to be trusted for it.
CREATE TABLE login_events (
id INTEGER PRIMARY KEY AUTOINCREMENT,
device_hash TEXT NOT NULL UNIQUE,
user_agent TEXT NOT NULL,
first_seen_at INTEGER NOT NULL,
last_seen_at INTEGER NOT NULL
);