Team-targeted tasks: subscribe and filter by team tag #1

New issue

Open

opened 2026-05-13 09:51:55 +00:00 by padreug · 0 comments

padreug commented

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

Owner

Context

The webapp tasks module today targets tasks at individuals via NIP-52 p tags. Real chore lists cluster by audience — "animal-chores", "farmers", "kitchen" — and we want a way to publish a task to a team without enumerating every member's pubkey.

See umbrella issue aiolabs/webapp#55 for the cross-module design discussion (tasks, libra, events, forum all want the same primitive).

Concrete tasks-side scope

Assuming we land on avenue A (tag convention) or B (NIP-51 lists) from the umbrella:

Backend (this repo)

team (or teams, plural) field on CreateTask / Task — a list of team identifiers.
Publisher emits one ["t", "<team>"] per team (already supported by the categories field — may just need a UX rename or a dedicated field to keep "user-facing hashtags" distinct from "team scoping").
Sync filter: optionally subscribe only to {kinds: [31922], "#t": ["<my-teams>"]} to reduce noise, given that relay-side #t filtering does work (unlike our custom event-type tag).
If we go avenue B, add resolution of NIP-51 team-list addresses and an a-tag on the task pointing at the team.

Webapp surface

"Post to team" picker in the create-task dialog (multi-select).
Subscribed-teams preference on the user profile (stored as a NIP-51 kind 30000 follow set per umbrella issue).
Feed filter: show tasks where any of the task's team tags ∈ user's subscribed teams.

Non-goals (for this issue)

Roster admin / enrollment UX — that's a webapp-side concern; track in the umbrella.
Cross-module reuse (libra, events) — separate issues per repo.
NIP-29 relay-enforced membership — only if A/B prove inadequate.

Open questions

Reuse categories or add a dedicated teams field? The semantics overlap but conceptually "team" is "who this is for" and "category" is "what kind of work" — useful to keep them separate for filtering UX.
Do team tags follow a naming convention (kebab-case, namespaced like aio:animal-chores) so they don't collide with arbitrary hashtags from other Nostr clients?
How does the LNbits admin page behave when filtering — show only tasks for teams the admin is on, or always show all?

## Context The webapp tasks module today targets tasks at individuals via NIP-52 `p` tags. Real chore lists cluster by audience — "animal-chores", "farmers", "kitchen" — and we want a way to publish a task to a team without enumerating every member's pubkey. See umbrella issue [aiolabs/webapp#55](https://git.atitlan.io/aiolabs/webapp/issues/55) for the cross-module design discussion (tasks, libra, events, forum all want the same primitive). ## Concrete tasks-side scope Assuming we land on avenue A (tag convention) or B (NIP-51 lists) from the umbrella: ### Backend (this repo) - `team` (or `teams`, plural) field on `CreateTask` / `Task` — a list of team identifiers. - Publisher emits one `["t", "<team>"]` per team (already supported by the `categories` field — may just need a UX rename or a dedicated field to keep "user-facing hashtags" distinct from "team scoping"). - Sync filter: optionally subscribe only to `{kinds: [31922], "#t": ["<my-teams>"]}` to reduce noise, given that relay-side `#t` filtering does work (unlike our custom `event-type` tag). - If we go avenue B, add resolution of NIP-51 team-list addresses and an `a`-tag on the task pointing at the team. ### Webapp surface - "Post to team" picker in the create-task dialog (multi-select). - Subscribed-teams preference on the user profile (stored as a NIP-51 kind 30000 follow set per umbrella issue). - Feed filter: show tasks where any of the task's team tags ∈ user's subscribed teams. ## Non-goals (for this issue) - Roster admin / enrollment UX — that's a webapp-side concern; track in the umbrella. - Cross-module reuse (libra, events) — separate issues per repo. - NIP-29 relay-enforced membership — only if A/B prove inadequate. ## Open questions 1. Reuse `categories` or add a dedicated `teams` field? The semantics overlap but conceptually "team" is "who this is for" and "category" is "what kind of work" — useful to keep them separate for filtering UX. 2. Do team tags follow a naming convention (kebab-case, namespaced like `aio:animal-chores`) so they don't collide with arbitrary hashtags from other Nostr clients? 3. How does the LNbits admin page behave when filtering — show only tasks for teams the admin is on, or always show all?

padreug referenced this issue from aiolabs/libra

2026-05-13 10:00:24 +00:00

Add team budget system with spending limits #10

padreug referenced this issue from aiolabs/webapp

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

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