Record the ActivityPods-first directives, and what the reference reconnaissance established

2026-10-09 09:48:52 +02:00
parent df1db790ad
commit 184998a343
2 changed files with 172 additions and 0 deletions
@@ -0,0 +1,36 @@
+---
+type: brief
+summary: ActivityPods is the sole priority provider — everything that can goes through the Refine providers, a backend for actions on behalf of a user is to be added, the NextGraph+polyfill backend is suspended (temporary); reference material and open questions recorded 2026-10-09
+---
+
+# Brief (2026-10-09) — ActivityPods first, and a backend for on-behalf actions
+
+Directives recorded at the resumption of the hand-off (`.project/handoff/refine-provider-abstraction.md`), to anchor the ActivityPods integration workstream.
+
+## Directives
+
+1. **ActivityPods is the priority.** The Refine backend over NextGraph plus its polyfill is **suspended, temporarily** — it is not abandoned (the two-rights-models structure still targets both), but no work goes into it while ActivityPods is being wired.
+2. **Everything that can must go through `@activitypods/refine-providers`.** The Refine boundary rule from the hand-off applies: what Refine can express is a Refine resource; what it cannot (collection creation, WAC, groups, outbox posting) happens beside Refine, in the seam or in the new backend. Capability differences stay inside the provider layer, never in the app.
+3. **A backend must be added for actions "on behalf of a user".** Festipod needs server-side actions executed for the account of a user (the pattern used by the reference apps below). Its mechanism, packages and deployment shape are the first design question of this workstream.
+
+## Reference material (user-designated 2026-10-09)
+
+Reading these at this stage is adoption-time reading, explicitly directed — the standing constraint against reading provider sources at work time is unaffected (`@activitypods/refine-providers` remains specified by its pinned reconstruction, `activitypods-providers/contract_activitypods-providers.md`).
+
+- **Example apps** — `/home/sylvain/projects/reconnexion/welcometomyplace` and `/home/sylvain/projects/reconnexion/mutual-aid.app`: working integrations to mine for provider configuration, resources, and the on-behalf backend pattern.
+- **ActivityPods platform source** — `/home/sylvain/projects/activitypods/activitypods`; Semapps lives in a sibling folder.
+- **Shapes** — `/home/sylvain/projects/activitypods/shapes`: readily usable, and **evolvable by us** if Festipod's entities require it (that repo is ours to adapt).
+
+## Constraints already on record (see the 2026-10-03 brief and the reconstruction)
+
+- `fp:` must be registered at prefix.cc; shape trees must sit at public URLs, one per entity, no sharing cascade.
+- The Refine providers cover CRUD only; `custom` is not implemented — no escape hatch through Refine.
+- `getMany` silently drops failed fetches — it erases the "unreadable reference" state the model needs (a candidate contribution).
+- `acl:Append` third-party insert-without-remove behaviour is NOT VERIFIED; the structure does not depend on the answer.
+
+## Open questions
+
+- The on-behalf mechanism: how a Festipod backend authenticates and acts for a user (tokens? app actor? delegated outbox posting?) — to be mapped from the platform source and the example apps.
+- Which shapes from the shapes repo map to Festipod's entities (Event, MeetingPoint, Profile, Participation) as-is, and which need to be created or evolved.
+- The backend's deployment shape (service alongside the app? serverless? a platform app?).
+- Whether the four pointed-to provider contributions (from the hand-off) are still the right set once the backend exists — some may move from "contribution to the providers" to "our backend's job".