tasks: when task-create lands in the webapp, emit ["event-type", "task"] on kind 31922 #56

New issue

Open

opened 2026-05-17 17:46:06 +00:00 by padreug · 0 comments

padreug commented

2026-05-17 17:46:06 +00:00

Owner

Context

The webapp tasks module today is read-only — it subscribes to kind 31922 calendar events and kind 31925 RSVPs, publishes its own 31925 completions and kind 5 deletions, but has no publishing path for kind 31922 itself. Tasks shown in the UI come from external publishers (in our setup, the LNbits tasks extension at git.atitlan.io/aiolabs/tasks).

When the webapp grows a "Create Task" flow (i.e. publishes its own 31922), it MUST emit ["event-type", "task"] in the tag list. The lnbits tasks extension already requires this tag on every inbound 31922 to disambiguate tasks from activities on shared relays — without it, lnbits silently drops the event from its local cache (a webapp-authored task would appear in webapp-land but not federate back to the lnbits-extension-backed view).

What needs to happen

When webapp introduces 31922 publishing for tasks (likely in src/modules/tasks/services/TaskService.ts or a new CreateTaskDialog):

Add ["event-type", "task"] to the tag list, alongside d, title, start, etc.
Symmetrically, when activities publishes 31923 (or 31922 if that ever changes), tag it ["event-type", "activity"] so the convention is two-sided rather than tasks-only — otherwise the activities filter at ActivitiesNostrService.ts:141-143 (which strips event-type: task) remains the only enforcement and we drift back into the #25 problem.

Why now

Filing this as a heads-up rather than a bug because:

The bug doesn't exist yet — the webapp has no 31922 publish path to fix.
It's easy to forget when the create-task flow eventually lands, and the failure mode is silent (events appear in the webapp but not lnbits, with no error anywhere).

Lnbits ext side reference

Publisher: tasks/nostr_publisher.py#build_task_event — emits ["event-type", "task"].
Filter: tasks/nostr_sync.py#_is_task_event — whitelist on the same tag.

#25 disambiguate task vs activity NIP-52 events on shared relays — same root cause.
#55 cross-cutting teams concept — same family of "we need consistent tag conventions across modules."
aiolabs/tasks#1 — concrete tasks-side team scope.

## Context The webapp tasks module today is read-only — it subscribes to kind 31922 calendar events and kind 31925 RSVPs, publishes its own 31925 completions and kind 5 deletions, but has **no publishing path for kind 31922 itself**. Tasks shown in the UI come from external publishers (in our setup, the LNbits `tasks` extension at `git.atitlan.io/aiolabs/tasks`). When the webapp grows a "Create Task" flow (i.e. publishes its own 31922), it MUST emit `["event-type", "task"]` in the tag list. The lnbits tasks extension already requires this tag on every inbound 31922 to disambiguate tasks from activities on shared relays — without it, lnbits silently drops the event from its local cache (a webapp-authored task would appear in webapp-land but not federate back to the lnbits-extension-backed view). ## What needs to happen When `webapp` introduces 31922 publishing for tasks (likely in `src/modules/tasks/services/TaskService.ts` or a new `CreateTaskDialog`): - Add `["event-type", "task"]` to the tag list, alongside `d`, `title`, `start`, etc. - Symmetrically, when **activities** publishes 31923 (or 31922 if that ever changes), tag it `["event-type", "activity"]` so the convention is two-sided rather than tasks-only — otherwise the activities filter at `ActivitiesNostrService.ts:141-143` (which strips `event-type: task`) remains the only enforcement and we drift back into the #25 problem. ## Why now Filing this as a heads-up rather than a bug because: - The bug doesn't exist yet — the webapp has no 31922 publish path to fix. - It's easy to forget when the create-task flow eventually lands, and the failure mode is silent (events appear in the webapp but not lnbits, with no error anywhere). ## Lnbits ext side reference - Publisher: [tasks/nostr_publisher.py#build_task_event](https://git.atitlan.io/aiolabs/tasks/src/branch/main/nostr_publisher.py) — emits `["event-type", "task"]`. - Filter: [tasks/nostr_sync.py#_is_task_event](https://git.atitlan.io/aiolabs/tasks/src/branch/main/nostr_sync.py) — whitelist on the same tag. ## Related - #25 disambiguate task vs activity NIP-52 events on shared relays — same root cause. - #55 cross-cutting teams concept — same family of "we need consistent tag conventions across modules." - aiolabs/tasks#1 — concrete tasks-side team scope.

padreug referenced this issue

2026-05-17 19:44:18 +00:00

tasks: support custom recurrence intervals (every N days/weeks, monthly) #57

padreug referenced this issue from aiolabs/tasks

2026-05-17 19:44:45 +00:00

support custom recurrence intervals (every N days/weeks, monthly) #2

padreug added the

app:tasks

enhancement

labels

2026-05-17 21:23:30 +00:00