Participation privacy (decision_2026-10-29_participation-privacy-mechanism):
a sign-up is a private Join naming the meeting point, addressed to nobody,
handled by the backend on emission. Attendee lists hold member URNs hashed
from (WebID, event, a secret kept in the participant's profile), so counts
stay public and only contacts recognise anyone; the creator has no read
right and is notified anonymously. Each person's participations collection,
created by the backend at the first sign-up, is readable by their /contacts
WAC group only, never world-readable. The member URN is sticky per
(meeting point, participant) and every collection write is verified by
reading back, so a refused write leaves the act unrecorded and retryable.
The EventRef mechanism and its browser-side provisioning are gone.
The backend now runs with WebACL on, as the reference apps do, on its own
secure datasets festipod / settings-festipod instead of the pod provider's
settings dataset; pod-notifications needs it. The compose header and the
deployment leaf say how to reset a stack whose datasets predate this.
The rights matrix covers the new mechanism live (148 hard lines), including
a forged contact Accept between throwaway accounts: the stranger enters the
contacts list (platform defect, reported upstream) but is refused the profile
and the participations. Tests may attack as long as they never break the dev
environment (rule_tests-never-break-the-dev-environment).
Also lands the coherence-pass work that was still uncommitted: contacts as
the Pod's social graph and invite links, image upload to the Pod, the
meeting-point form, profile completion gate, and the doctrine for them.
Superseded briefs and decisions are deleted rather than annotated.
Back to the sibling apps' pattern: an overridable MAIN_DATASET /
SETTINGS_DATASET, explicit on the main stack (festipod-test /
settings-festipod-test), computed from DATASET_PREFIX and the service name when
left empty (previews). One convention across the apps is simpler for the
developers who move between them than a local variant.
Reverts the previous commit's compose change; the deployment leaf keeps one
line on why Coolify shows those two variables holding expression text.
The sibling apps wrap their dataset names in an overridable
`${MAIN_DATASET:-${DATASET_PREFIX:-…}-${SERVICE_NAME_BACKEND}}` because they keep
historical datasets. Coolify stores such a default, itself an expression, as the
created variable's value, so the new app showed MAIN_DATASET and
SETTINGS_DATASET holding what reads as unresolved text. It does resolve at
deploy time (docker compose interpolates `.env` values), so this was confusing
rather than broken — but Festipod has no historical datasets to keep, so the
names are now computed directly: festipod-backend / settings-festipod-backend,
`…-backend-pr-<n>` in a preview, the same names as before.
The comment and the deployment leaf say what was observed and what was traced,
and that a second stack on the same Fuseki needs its own DATASET_PREFIX in both
its normal and preview scopes.
The stack Coolify builds from the repository, on the test server only for
now, modelled on the sibling ActivityPods apps: the app (root Dockerfile), the
backend (backend/Dockerfile) and a per-stack Redis; Fuseki is the shared one,
reached over the external coolify network, with a pair of datasets per stack.
One base URL per environment: the app at https://festipod.dev.reconnexion.coop,
the backend's Domains https://<host>/api,https://<host>/.well-known, with
Coolify's Strip Prefixes OFF. The Pod provider offered in one click defaults
to https://mypod.store, as for the sibling dev apps.
The deployment leaf no longer claims that nothing is deployed with this shape
and that no Coolify config exists; it records the stack, the base-path layout,
both images' build traps and the first-boot ones (set the domains before the
first deployment; restart the backend once so /app carries the access-need
group).
Sylvain Duchesne