Disambiguate task vs activity NIP-52 calendar events on shared relays #25

New issue

Open

opened 2026-04-26 22:13:16 +00:00 by padreug · 0 comments

padreug commented

2026-04-26 22:13:16 +00:00

Owner

Problem

The tasks module and activities module both use NIP-52 calendar event kinds (31922/31923) on the same Nostr relay. This causes task events ("Put out the recycling", "Put the chickens to bed") to appear in the activities feed as community events.

Currently we filter by checking for event-type: task tag or a status tag on kind 31922 events (NIP-52 only defines status on RSVP kind 31925, not on calendar events). This works as a stopgap but is fragile — manually created events may not have these tags, and future modules could introduce other non-activity calendar events.

The core challenge

NIP-52 calendar events are a general-purpose format. There's no built-in mechanism to distinguish "this is a community activity" from "this is a household task" from "this is a meeting." Both are valid kind 31922 events per spec.

Possible solutions

1. Custom `event-type` tag convention

Tasks publish with ['event-type', 'task'], activities with ['event-type', 'activity']
Activities feed filters in only event-type: activity (whitelist, not blacklist)
Pros: Simple, explicit
Cons: Non-standard tag, other Nostr clients won't know about it

2. Use `t` (hashtag) tags as categories

Tasks publish with ['t', 'task'] or ['t', 'chore']
Activities publish with ['t', 'event'] or domain-specific tags like ['t', 'concert']
Activities feed subscribes with #t filter excluding task-related hashtags
Pros: NIP-12 compliant, relay-level filtering possible
Cons: Fragile if tags aren't consistent, can't filter at relay level with negation

3. Separate relay channels

Tasks publish to a different relay or different relay namespace
Activities only subscribe to the "community" relay
Pros: Clean separation, no filtering needed
Cons: Requires relay infrastructure decisions, harder to manage

4. Use different Nostr kinds for tasks

Tasks could use a dedicated kind (e.g., from the application-specific range 30000-39999)
NIP-52 kinds reserved for true calendar events only
Pros: Clean protocol-level separation, relay filtering works natively
Cons: Breaks NIP-52 compatibility for tasks, need to define/document the new kind

5. Author-based filtering

Activities feed only shows events from known community/organizer pubkeys
Tasks are personal (user's own pubkey) and naturally excluded
Pros: Works without any tag conventions
Cons: Breaks open discovery — new organizers wouldn't appear until added

Current workaround

ActivitiesNostrService.parseNostrEventToActivity() filters out events with event-type: task tag or a status tag on kind 31922 (since NIP-52 doesn't define status on calendar events, only on RSVPs).

References

NIP-52 spec: https://github.com/nostr-protocol/nips/blob/master/52.md
Tasks module: src/modules/tasks/services/TaskService.ts
Activities filter: src/modules/activities/services/ActivitiesNostrService.ts:137-143

## Problem The tasks module and activities module both use NIP-52 calendar event kinds (31922/31923) on the same Nostr relay. This causes task events ("Put out the recycling", "Put the chickens to bed") to appear in the activities feed as community events. Currently we filter by checking for `event-type: task` tag or a `status` tag on kind 31922 events (NIP-52 only defines `status` on RSVP kind 31925, not on calendar events). This works as a stopgap but is fragile — manually created events may not have these tags, and future modules could introduce other non-activity calendar events. ## The core challenge NIP-52 calendar events are a general-purpose format. There's no built-in mechanism to distinguish "this is a community activity" from "this is a household task" from "this is a meeting." Both are valid kind 31922 events per spec. ## Possible solutions ### 1. Custom `event-type` tag convention - Tasks publish with `['event-type', 'task']`, activities with `['event-type', 'activity']` - Activities feed filters *in* only `event-type: activity` (whitelist, not blacklist) - Pros: Simple, explicit - Cons: Non-standard tag, other Nostr clients won't know about it ### 2. Use `t` (hashtag) tags as categories - Tasks publish with `['t', 'task']` or `['t', 'chore']` - Activities publish with `['t', 'event']` or domain-specific tags like `['t', 'concert']` - Activities feed subscribes with `#t` filter excluding task-related hashtags - Pros: NIP-12 compliant, relay-level filtering possible - Cons: Fragile if tags aren't consistent, can't filter at relay level with negation ### 3. Separate relay channels - Tasks publish to a different relay or different relay namespace - Activities only subscribe to the "community" relay - Pros: Clean separation, no filtering needed - Cons: Requires relay infrastructure decisions, harder to manage ### 4. Use different Nostr kinds for tasks - Tasks could use a dedicated kind (e.g., from the application-specific range 30000-39999) - NIP-52 kinds reserved for true calendar events only - Pros: Clean protocol-level separation, relay filtering works natively - Cons: Breaks NIP-52 compatibility for tasks, need to define/document the new kind ### 5. Author-based filtering - Activities feed only shows events from known community/organizer pubkeys - Tasks are personal (user's own pubkey) and naturally excluded - Pros: Works without any tag conventions - Cons: Breaks open discovery — new organizers wouldn't appear until added ## Current workaround `ActivitiesNostrService.parseNostrEventToActivity()` filters out events with `event-type: task` tag or a `status` tag on kind 31922 (since NIP-52 doesn't define status on calendar events, only on RSVPs). ## References - NIP-52 spec: https://github.com/nostr-protocol/nips/blob/master/52.md - Tasks module: `src/modules/tasks/services/TaskService.ts` - Activities filter: `src/modules/activities/services/ActivitiesNostrService.ts:137-143`

padreug referenced this issue

2026-04-27 16:13:25 +00:00

Consider keeping CreateActivityDialog for unticketed/unapproved community events #29

padreug referenced this issue from a commit

2026-05-13 09:50:35 +00:00

add Nostr publishing and bidirectional sync

padreug referenced this issue

2026-05-13 09:51:09 +00:00

Cross-cutting "teams" concept: targeted tasks, scoped budgets, and shared rosters #55

padreug referenced this issue

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

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