feat: Update ROADMAP with personal data handling and user moderation features

- Added goals for defining personal data categories and retention obligations.
- Included exit criteria for user-level moderation, personal collections, and self-service data export.
- Expanded Phase 2 goals to include remote actor moderation and shareable block lists.

chore: Update flake.nix to specify main program

- Set the main program for the project in the flake configuration.

feat: Add issue templates for bug reports, feature requests, and questions

- Created structured templates to streamline issue reporting and feature suggestions.

docs: Add pull request template for consistent contributions

- Introduced a PR template to guide contributors on providing necessary information.

docs: Establish a Code of Conduct for community behavior

- Implemented a Code of Conduct to promote a respectful and inclusive environment.

docs: Create Diversity, Equity, and Inclusion (DEI) statement

- Outlined commitment to diversity and inclusion within the FeDIY community.

docs: Define Code Review Guidelines for constructive feedback

- Established guidelines to ensure respectful and effective code reviews.

docs: Implement Security Policy for vulnerability reporting

- Created a security policy detailing how to report vulnerabilities and our commitment to addressing them.

docs/ARCHITECTURE.md

@@ -65,6 +65,8 @@ Bundled web UI:
 - Communicates only through the public API.
 - Treated as the reference client for API usability validation.
 - Should degrade gracefully where JavaScript is unavailable where practical.
+- Must support per-user display preferences: font choice (including dyslexia-friendly fonts), size, line spacing, and contrast settings persisted to the user's account.
+- Must not hardcode fonts or layout in ways that prevent user override.
 
 ## Logical Components
 
@@ -92,18 +94,180 @@ Bundled web UI:
 
 ## Moderation and Safety Strategy
 
+### Instance and Moderator-Level Controls
+
 - Local policy is authoritative for what is visible on this instance.
 - Policy controls exist at three levels: object, actor, and instance.
 - Moderation actions produce auditable events.
 - Appeals and reversal policy should be documented before broad federation rollout.
 
+### User-Level Personal Moderation
+
+Users have unilateral, moderator-independent tools to protect themselves from bad actors. These do not require moderator approval and take effect immediately for the acting user:
+
+- **Block users**: block specific local or remote accounts. A blocked account cannot interact with the user's content and the user does not see the blocked account's content.
+- **Block instances**: block an entire remote instance. The user sees no content from that instance and cannot be interacted with by its users.
+- **Mute users**: suppress a user's content from the user's feed without full blocking.
+- **Keyword and wildcard filtering**: filter content containing specific words, phrases, or wildcard patterns from the user's feed and notifications. Filters operate client-side or server-side at the user's preference.
+- **No moderator gate**: user-level blocks, mutes, and filters are the user's own data. Instance moderators cannot prevent a user from protecting themselves.
+
+### Shareable Social Moderation
+
+Users may choose to share their personal moderation and curation data with others:
+
+- **Exportable/importable block lists**: users can export their block list as a portable format (JSON-LD or similar) and share it. Others can import it in whole or selectively.
+- **Subscribable block lists**: a user may publish a block list as a live resource. Subscribers can opt in to apply it automatically or review updates manually.
+- **Recommendation lists**: users can publish curated lists of projects, accounts, or tags they recommend. Lists are first-class objects with their own AP identity.
+- **Personal collections and bookmarks**: users can organize saved projects into named collections and optionally make those collections public or shareable.
+- **Community-defined lists**: groups of users (communities, instances) can collaboratively maintain shared lists for moderation or discovery purposes.
+- **Attribution and transparency**: shared lists carry attribution to the list maintainer. Subscribers know whose judgment they are trusting.
+
+## Localization and Internationalization Strategy
+
+FeDIY is designed to be usable across languages and locales from the beginning:
+
+- **Locale-aware API**: all user-facing strings are externalized and never hardcoded in the API layer. The API surfaces language/locale metadata about content (project language, author locale) to allow clients to filter, translate, or display appropriately.
+- **Content language tagging**: projects carry a declared language tag (BCP 47). Instances may restrict accepted content languages or accept all. Federated objects include language metadata.
+- **UI string externalization**: all bundled UI strings are stored in locale files (e.g., JSON or gettext PO format) from the start. The architecture does not permit hardcoded display strings.
+- **RTL layout support**: layout must support right-to-left scripts (Arabic, Hebrew, Persian, etc.) from the first UI design pass. CSS logical properties are preferred over physical ones.
+- **Locale-sensitive formatting**: dates, times, numbers, and units use locale-aware formatting rather than hardcoded conventions.
+- **Community translation**: translation files are exposed in the repository so that the community can contribute translations without touching application code.
+- **Locale as a user preference**: authenticated users can set their preferred locale, stored in their account. Unauthenticated users can set locale via browser `Accept-Language` or an explicit UI control.
+- **Search and indexing**: full-text search configurations are locale-aware where the persistence layer supports it (e.g., PostgreSQL language dictionaries).
+
 ## Non-Functional Requirements
 
-- Reliability: resilient delivery and retry strategy for federated traffic.
-- Security: signature verification, key management, least-privilege defaults, and safe CORS policy.
-- Performance: predictable latency for local reads and bounded queues for remote events.
-- Operability: metrics, logs, and runbooks for incident response.
-- API stability: public API changes follow a deprecation policy; breaking changes require a version increment.
+- **Accessibility**: designed from the start to be inclusive for people with sensory and motor differences. Includes WCAG 2.1 AA minimum, text-to-speech hooks, alt text for all visual content, captions for audio, keyboard navigation, and support for assistive technologies.
+- **Localization**: all UI strings externalized and locale-ready from day one; RTL layout support; content language tagging; community-translatable.
+- **Reading comfort**: users can override fonts (including dyslexia-friendly typefaces), size, line spacing, and contrast. No system-level or application-level font lock-in.
+- **Reliability**: resilient delivery and retry strategy for federated traffic.
+- **Security**: signature verification, key management, least-privilege defaults, and safe CORS policy.
+- **Performance**: predictable latency for local reads and bounded queues for remote events.
+- **Operability**: metrics, logs, and runbooks for incident response.
+- **API stability**: public API changes follow a deprecation policy; breaking changes require a version increment.
+
+## Privacy and Legal Compliance Strategy
+
+FeDIY is designed with privacy as a first-class concern. The architecture must satisfy GDPR (and equivalent data-protection regulations) by design, not by retrofit.
+
+### Data Minimisation and Purpose Limitation
+
+- Collect only the personal data required for the platform to function.
+- Every personal data field must have a documented purpose. Fields without a clear purpose are not collected.
+- Access to personal data is scoped to the minimum needed for each system component.
+
+### Lawful Basis for Processing
+
+- Account data is processed on the basis of contract (the user's agreement to the terms of service).
+- Where consent is required (e.g. non-essential cookies, marketing communications), it is obtained explicitly, recorded, and revocable.
+- Processing logs record the lawful basis used for each data category.
+
+### Right to Access (Article 15)
+
+- Users can request a full export of all personal data held about them via a self-service API endpoint.
+- The export is machine-readable (JSON), human-readable, and covers: account data, published and draft content, interactions (follows, likes, bookmarks), moderation history affecting the user, and session/audit records.
+- Federated data about the user held by remote instances is outside the local instance's control; exports note this explicitly.
+
+### Right to Erasure / Right to be Forgotten — Technical Design
+
+GDPR Article 17 (and equivalent laws in other jurisdictions) defines erasure at two levels. FeDIY must handle both:
+
+**Level 1 — Local erasure (the account deletion step):**
+
+- Users initiate deletion via a self-service workflow with no moderator or admin involvement required.
+- Local erasure covers: account credentials, profile fields, email address, private/draft content, session tokens, IP logs beyond the retention window, interactions data (follows, likes, bookmarks, block lists) that is not itself public.
+- Draft projects (never published) are deleted immediately.
+- Deleted account data is fully purged within a defined maximum window (e.g. 30 days), not merely soft-deleted. The purge window is disclosed in the privacy notice.
+- A deletion-in-progress state is visible to the user while processing completes.
+
+**Level 2 — Propagation to third-party controllers (GDPR Art. 17(2)):**
+
+- GDPR Article 17(2) requires that where a controller has made personal data public, it must take *reasonable steps* to inform other controllers processing that data of the erasure request. For FeDIY, this means federated instances.
+- FeDIY fulfils this via ActivityPub `Delete` activities sent to all known federation peers that have received activities from this actor.
+- `Delete` is sent for: the actor object itself, all known published objects (projects, activities).
+- Delivery is best-effort with retry. FeDIY cannot *compel* remote instances to comply — this is a known limitation of the federated model, and the privacy notice must state it clearly.
+- A log of which peers received the `Delete` activity (and delivery status) is retained for the operator's accountability records. This log is separate from the user's personal data and may be kept for legal compliance.
+
+**Tombstoning vs. full erasure of public content:**
+
+- Publicly published content that is referenced by other objects (e.g. a project that has been boosted or commented on by other users) may be replaced by an ActivityPub `Tombstone` rather than silently deleted. The `Tombstone` preserves object identity without reproducing the content or the author's personal data.
+- The privacy notice and the deletion UI must clearly explain: (a) the distinction between draft/private data (deleted) and published content (tombstoned), and (b) the federation propagation limitation.
+- A user who wants all traces removed must be told honestly what FeDIY can and cannot control.
+
+**Permitted retentions (GDPR Art. 17(3) exceptions):**
+
+- Moderation and safety records may be retained in anonymised form where necessary for legal compliance (e.g. CSAM reporting obligations, abuse records). These are anonymised at deletion time: the personal identifiers are removed but the safety record is kept.
+- Legal hold: if an account is under active investigation or legal proceedings, deletion may be suspended for the duration. The user must be informed of the hold.
+- Financial transaction records (where applicable) must comply with applicable tax and accounting retention laws, which may be longer than the general data window.
+
+**RTBF for individual content items (not full account deletion):**
+
+- A user may request deletion of specific published content (a project, a comment) without deleting their entire account.
+- The same tombstone/propagation logic applies per object.
+- This supports the GDPR right to withdraw consent for a specific published item without requiring full account closure.
+
+### Multi-Jurisdiction Compliance Matrix
+
+FeDIY is an open, self-hostable, federated platform. Instance operators may be subject to different legal regimes depending on where they operate and where their users are located. The architecture must support compliance across the primary regulatory regimes; instance operators are responsible for customising behaviour to their jurisdiction.
+
+| Jurisdiction | Law | Erasure/RTBF right | Deletion SLA | Notes |
+|---|---|---|---|---|
+| EU / EEA | GDPR Art. 17 | Yes — right to erasure + propagation | Without undue delay; typically ≤30 days | Includes Art. 17(2) propagation obligation |
+| UK | UK GDPR (post-Brexit) | Yes — equivalent to EU GDPR | Same as EU GDPR | Applies to UK users/controllers |
+| California, US | CCPA/CPRA | Yes — right to delete | 45 days (extendable to 90) | Opt-out of sale/sharing; right to correct |
+| Virginia, US | VCDPA | Yes — right to delete | 45 days | Opt-out of targeted advertising |
+| Colorado, US | CPA | Yes | 45 days | Global Privacy Control must be honored |
+| Connecticut, US | CTDPA | Yes | 45 days | |
+| Texas, US | TDPSA | Yes | 45 days | Applies broadly to controllers |
+| Other US states | Various (and growing) | Varies | Typically 45–90 days | Architecture must be jurisdiction-agnostic |
+| Brazil | LGPD Art. 18 | Yes — right to deletion | Reasonable time | Applies to data of Brazilian residents |
+| Canada | PIPEDA / C-27 | Limited currently; C-27 will add explicit right | Bill C-27 pending | Design for upcoming CPPA |
+| UK / Australia | Privacy Act 1988 (AU) | Limited; reform ongoing | Varies | Design to accommodate |
+
+**Architectural implications:**
+
+- **Jurisdiction-agnostic deletion workflow**: the erasure workflow is the same regardless of the user's jurisdiction; the operator configures any jurisdiction-specific behaviour (SLA, exceptions, notices) via instance settings.
+- **Configurable SLA timers**: instance operators can set the deletion SLA window (e.g. 30 days for GDPR, 45 days for CCPA) via configuration. The default should satisfy the strictest common requirement.
+- **Opt-out signals**: the architecture must support Global Privacy Control (GPC) header signals, which California (and others) require businesses to honor. The API and UI must process GPC as an opt-out of data sale/sharing.
+- **No data sale**: FeDIY does not sell user data; this simplifies compliance but opt-out infrastructure may still be needed for operators who use analytics or advertising services.
+- **Right to correct**: both GDPR (Art. 16) and CCPA/CPRA provide this right. Self-service profile and content editing satisfies it.
+- **Response time tracking**: the system must be capable of recording when a deletion request was received, what was deleted, and when the purge completed, to support operator accountability obligations under multiple laws.
+
+### Right to Rectification (Article 16)
+
+- Users can correct or update their account profile data at any time without requiring moderator involvement.
+- Updates to personal data propagate to federated instances via ActivityPub `Update` activities.
+
+### Right to Data Portability (Article 20)
+
+- The data export (see Right to Access) is in a portable, interoperable format.
+- Where possible, exported project data can be imported into another FeDIY instance or compatible platform.
+
+### Data Retention Limits
+
+- A configurable retention policy governs how long the following categories are kept:
+  - Authentication logs and failed login records: short retention (e.g. 30–90 days) unless a security incident requires longer.
+  - Session tokens: purged on logout and on expiry.
+  - IP address logs: not stored beyond what is operationally required; never logged against content in a way that persists indefinitely.
+  - Deleted account data: fully purged within a defined window after the deletion request is processed (e.g. 30 days), except for legally required anonymised moderation records.
+- Instance operators must be able to configure retention windows to meet their local legal obligations.
+
+### Federated Data and Third-Party Instances
+
+- When a user deletes their account, a best-effort `Delete` activity is sent to known federated peers. FeDIY cannot compel remote instances to comply.
+- The privacy notice must clearly explain that content shared via federation may persist on remote instances beyond FeDIY's control.
+- FeDIY does not store personal data about remote users beyond what is strictly required to process incoming activities.
+
+### Children's Privacy
+
+- FeDIY does not knowingly collect personal data from children under the age of 13 (or the applicable age in the user's jurisdiction).
+- Age verification approach (self-declaration, parental consent, or age-gate) must be defined before Phase 1 launch.
+
+### Privacy Notice
+
+- A machine-readable and human-readable privacy notice must be published at a well-known URL before any public instance accepts registrations.
+- The notice describes: what data is collected, why, how long it is retained, how to exercise rights, and contact information for the data controller.
+- Instance operators are data controllers for their own instances. FeDIY provides a template notice but operators are responsible for customising it to their jurisdiction.
 
 ## Architecture Decision Practice
 

docs/OPEN_QUESTIONS.md

@@ -155,10 +155,40 @@ The goal is to remove ambiguity before implementation while keeping scope realis
 - Read-only browsing (project pages, search results) without JS is desirable.
 - Authoring without JS is probably out of scope — is that an explicit decision?
 
-**Q16 [P1]** What is the accessibility baseline?
+**Q16 [P1]** What is the accessibility baseline and implementation strategy?
 
-- WCAG 2.1 AA as a minimum?
-- Are there specific craft-community accessibility concerns (screen reader support for step-by-step instructions, colour contrast for pattern images)?
+- WCAG 2.1 AA is the minimum standard. How do we validate compliance and maintain it over time?
+- What alt text strategy is required for all media (project images, step-by-step photos, diagrams, charts)? Do we enforce it at upload time or provide tools for post-hoc addition?
+- What captions and transcripts strategy for audio/video content? Who is responsible for creation?
+- What text-to-speech capabilities should be built into the API and UI? Should the API provide structured step data (title, description, images) in a format suitable for TTS clients?
+- How do we support blind and low-vision users in the bundled UI? Screen reader testing and semantic HTML are baseline; what else?
+- How do we support Deaf and hard-of-hearing users? Captions for instructional videos, visual indicators for audio cues, readable transcripts.
+- How do we support users with motor differences? Full keyboard navigation, no time-dependent interactions, adjustable interface sizes/spacing.
+- What color contrast requirements apply to project images and diagrams submitted by users? Can we provide tools or guidance to improve accessibility?
+- Are there craft-community-specific accessibility concerns (e.g., tactile or kinesthetic learning for certain crafts, accessible alternatives for physical demonstrations)?
+- What is the accessibility review process for features and content? How are accessibility issues prioritized?
+
+**Q16a [P1]** What reading-comfort customization options does the bundled UI provide?
+
+- What font choices are offered? At minimum, the UI should offer a dyslexia-friendly typeface (e.g., OpenDyslexic, Atkinson Hyperlegible) alongside a standard option.
+- Should the full base font be user-overridable (including via browser/OS settings and user stylesheets)? The bundled UI must not block this.
+- What line-height, letter-spacing, word-spacing, and paragraph-width adjustments are available? (Wide spacing and shorter line length aid many readers.)
+- Are text size controls per-user and persistent (stored in account preferences), or session-only?
+- Should there be a low-visual-stress color theme (off-white/cream backgrounds, reduced contrast)? Some users with dyslexia or visual stress find high-contrast black-on-white harder to read.
+- How do user-defined display preferences interact with instance theming? User preferences must take precedence.
+- Are reading-comfort settings exposed via API so third-party clients can retrieve and honor them?
+
+**Q16b [P1]** What is the localization (i18n/l10n) strategy?
+
+- What locale data format is used for UI strings? (gettext PO, JSON, TOML, ICU MessageFormat?)
+- What is the language tagging convention for user-generated content? BCP 47 language tags are assumed — is this confirmed?
+- Does the platform support RTL scripts (Arabic, Hebrew, Persian, etc.) from the first UI pass? CSS logical properties are required if so.
+- What locale-sensitive formatting is required at MVP? (dates, times, numbers, units of measure)
+- How are translations contributed by the community? Are translation files in the main repo or a separate project?
+- What is the fallback behavior when a user's preferred locale is not available for a piece of content?
+- Does the search index need locale-specific text analysis (stemming, tokenization) configured per language?
+- Does the ActivityPub object for a project carry `@language` or equivalent metadata to signal content language to federated instances?
+- Is machine translation (MT) in scope? If so, is it instance-opt-in, per-user opt-in, or always-on?
 
 ---
 
@@ -244,10 +274,32 @@ The goal is to remove ambiguity before implementation while keeping scope realis
 - Instance admin assigns moderators manually; no self-service promotion.
 - Are there multiple moderation tiers (e.g. content moderator vs instance admin)?
 
+**Q29a [P1]** What user-level personal moderation tools are provided, and how are they represented in the data model?
+
+- A user must be able to block specific local and remote accounts without any moderator involvement. What is the API shape for a user-level block?
+- A user must be able to block an entire remote instance. Does this map to an ActivityPub `Block` activity, a local filter record, or both?
+- Are user-level mutes (suppress content without blocking) distinct from blocks in the data model?
+- What keyword and wildcard filter capabilities are supported? Are filters applied server-side (content never delivered to client) or client-side (UI suppresses matching content)? Both options should be supportable.
+- When a user blocks another, is the blocked party notified? (Convention in AP-based platforms is not to notify.)
+- Do user-level blocks prevent the blocked party from seeing the user's public content, or only prevent interaction?
+- How are user-level moderation actions represented in the user's own data export (GDPR portability)?
+
+**Q29b [P1/P2]** What is the data model and AP representation for shareable block and recommendation lists?
+
+- Shareable block lists: what format is used for export and import? JSON-LD? A well-known community format (e.g., Oliphant CSV, FediBlock)?
+- Can a block list be published as a live federated resource that subscribers can follow and receive updates from?
+- Recommendation lists: are these a first-class AP object type (e.g., `OrderedCollection` of `Project` objects), or a local-only feature?
+- Personal collections/bookmarks: are these private by default with an explicit publish action, or public by default?
+- What privacy model applies to list subscriptions? Can a user see who has subscribed to their block list?
+- How does subscribing to another user's block list interact with the subscriber's own moderation decisions? (Additive by default; subscriber retains override.)
+- Are community-maintained lists (collaboratively edited by a group) in scope, and if so, what is the authorship/edit governance model?
+- Can lists be versioned or snapshotted so a subscriber can audit what changed between updates?
+
 **Q30 [P3]** Do we participate in shared blocklists (e.g. FIRES, Oliphant tiers)?
 
 - Subscribe to external block lists automatically, or manual import only?
 - Is this a phase 3 concern or deferred entirely?
+- Does the user-level list subscription mechanism (Q29b) subsume this, or is it a separate instance-level concern?
 
 **Q31 [P3]** What is the user-facing report and appeals workflow?
 
@@ -293,3 +345,89 @@ The goal is to remove ambiguity before implementation while keeping scope realis
 
 - Can multiple accounts be listed as co-authors of a project?
 - Is there a contribution workflow (pull-request style) or trust-based co-author invite?
+
+---
+
+## Privacy and Legal Compliance
+
+**Q38 [P0/P1]** What personal data does FeDIY collect and what is the lawful basis for each category?
+
+- Account registration data (email, display name, password hash): processed under contract. What is the minimum required set?
+- IP address and access logs: is there a documented retention window and purge policy before Phase 1 launches?
+- Content data (projects, drafts, media): processed under contract. Drafts are private; what is the data model distinction between draft and published that ensures privacy?
+- Session and authentication tokens: what is the TTL and purge-on-logout policy?
+- Does the platform ever use personal data for purposes beyond what is needed to operate the service (e.g. analytics, recommendations)? If so, is consent obtained?
+
+**Q39 [P1]** What does the right-to-access (GDPR Article 15) export look like?
+
+- What data categories are included in a user's full export: account profile, published projects, draft projects, interactions (follows, likes, bookmarks, block lists), moderation history affecting the user, session and audit records?
+- What format is the export? JSON is required; is a human-readable HTML or PDF summary also provided?
+- Is the export self-service (user-initiated via UI and API) or does it require admin action?
+- What is the SLA for delivering an export? GDPR requires response within one month.
+- How are exports of federated data handled — i.e. data about the user that exists on remote instances? The export must explain this limitation.
+
+**Q40 [P1]** What does account deletion (GDPR Article 17 — right to erasure / right to be forgotten) entail?
+
+- What is the deletion workflow? Must be self-service, not admin-gated.
+- What data is fully erased: credentials, profile fields, private drafts, session tokens, email address, IP logs?
+- What is tombstoned rather than erased: publicly published content that is referenced by others? The privacy notice must explain the tombstone policy.
+- What moderation records are retained in anonymised form for legal/safety obligations, and for how long?
+- How long after a deletion request is the data fully purged? A maximum window (e.g. 30 days) must be defined and disclosed.
+- How is deletion propagated to federated instances (GDPR Art. 17(2))? An ActivityPub `Delete` activity is sent to known peers; remote compliance cannot be guaranteed. The privacy notice must say this.
+- Is there a delivery-receipt log for `Delete` activities sent to federated peers, retained for operator accountability (separate from user personal data)?
+- Is there a deletion-in-progress state visible to the user while federation propagation is completing?
+- Does the architecture support deletion of individual published items (a single project, a comment) without requiring full account closure?
+- Is legal hold (suspension of deletion during active investigation or legal proceedings) required? If so, how is the user notified?
+- For financial/transaction records, what is the operator-configurable retention window to satisfy accounting law?
+
+**Q40a [P1]** How does the platform support compliance with US state privacy laws alongside GDPR?
+
+- CCPA/CPRA (California): deletion SLA is 45 days (extendable to 90). Does the system support configurable SLA windows per instance?
+- CCPA/CPRA: right to opt-out of sale/sharing of personal data. FeDIY does not sell data, but does the architecture support the Global Privacy Control (GPC) signal as an opt-out mechanism?
+- CCPA/CPRA: right to correct inaccurate personal information. Is this satisfied by standard profile editing?
+- CCPA/CPRA: right to know (categories of data collected, sources, purposes, third parties). Is this satisfied by the privacy notice and data export?
+- Virginia VCDPA, Colorado CPA, Connecticut CTDPA, Texas TDPSA and others: broadly equivalent deletion and portability rights with 45-day SLAs. Does the jurisdiction-agnostic deletion workflow satisfy all of these?
+- Colorado CPA specifically: Global Privacy Control signals must be honored. Is GPC processing in scope for Phase 1?
+- Brazil LGPD Article 18: right to deletion of unnecessary or unlawfully processed data, equivalent in scope to GDPR Art. 17. Is the architecture jurisdiction-agnostic enough to satisfy this without custom logic?
+- Canada PIPEDA (and forthcoming CPPA / Bill C-27): limited right to deletion currently; architecture should anticipate the stronger rights in Bill C-27 when enacted. What future-proofing is needed?
+- UK GDPR: equivalent to EU GDPR; same architecture satisfies it, but does the template privacy notice need UK-specific customisation (ICO contact details, UK law references)?
+
+**Q40b [P1]** What is the operator guidance for jurisdiction-specific compliance customisation?
+
+- Which compliance settings are configurable per-instance (SLA window, data categories, GPC handling, legal hold policy)?
+- Does FeDIY provide a compliance checklist for operators launching a public instance?
+- Does the template privacy notice include jurisdiction-specific variants (EU, UK, California, Brazil) or a single configurable template?
+- How does FeDIY communicate clearly that the instance operator is the data controller and bears primary legal responsibility?
+
+**Q41 [P1]** What are the data retention periods for each category?
+
+- Authentication and failed-login logs: short retention (30–90 days suggested); is this configurable by instance operators?
+- IP address logs: are these stored at all beyond ephemeral request processing? If so, what is the maximum retention window?
+- Deleted account data: what is the maximum time between deletion request and full purge of identifiable data?
+- Moderation records: anonymised retention for legal purposes — what anonymisation process is applied and for how long are they kept?
+- Inactive account data: is there a policy for purging accounts that have never been activated or have been dormant for an extended period?
+
+**Q42 [P1]** What is the data portability (Article 20) export format, and can it be imported?
+
+- Is the export format capable of round-tripping into another FeDIY instance (i.e. migrate your account and projects to a different instance)?
+- Does the export include ActivityPub actor identity in a way that helps federated peers update their records after a migration?
+- Is account migration (move actor from instance A to instance B, with follower redirect) in scope? If so, which phase?
+
+**Q43 [P0/P1]** What is the privacy notice strategy for instance operators?
+
+- FeDIY provides a template privacy notice that operators must customise. What is the minimum required content?
+- Is the privacy notice served at a well-known URL (`/privacy`) before the instance accepts registrations?
+- How does the platform ensure that operators have published a privacy notice? (e.g. configuration check at startup, NodeInfo metadata)
+- Who is the data controller for a self-hosted instance? The instance operator. Is this clearly communicated in the code and documentation?
+
+**Q44 [P1]** What is the children's privacy policy?
+
+- What minimum age is required to register? (GDPR requires parental consent for under-16 in most EU member states; COPPA requires age 13 in the US.)
+- Is age verification self-declaration only, or is a stronger mechanism required?
+- What happens if a minor's account is reported? Is there a defined response process?
+
+**Q45 [P2]** How are federated data subjects' rights handled?
+
+- If a user on a remote instance requests erasure of data held locally (e.g. cached profile, received activities), what is the process?
+- Does receiving a `Delete` activity for a remote actor trigger a purge of all locally cached data about that actor?
+- Are there GDPR obligations that apply to data received via federation from instances in different jurisdictions?

docs/ROADMAP.md

@@ -14,6 +14,7 @@ Goals:
 - Define domain language and baseline architecture docs.
 - Establish quality process (TDD/BDD + GitHub Flow).
 - Clarify the core-plus-extension project contract before implementation.
+- Define personal data categories, retention windows, and erasure obligations before any user data model is implemented.
 
 Exit criteria:
 
@@ -23,6 +24,8 @@ Exit criteria:
 - ADR for project revision lifecycle (draft/publish/supersede).
 - ADR for composable extension mechanism (shape, namespacing, discovery).
 - Initial repository layout includes dedicated locations for API contracts and extension schemas.
+- Documented answer to Q38: personal data categories and lawful basis for each (prerequisite for any user data model work).
+- Draft privacy notice template and operator guidance (prerequisite for any public-facing instance).
 
 ## Phase 1: Single-Node MVP (No Federation Yet)
 
@@ -33,6 +36,9 @@ Goals:
 - Basic publishing lifecycle (draft, published, updated).
 - Search and browse within one instance.
 - Support extension payloads in project data model without requiring domain-specific first-party implementations.
+- User-level personal moderation: block and mute individual accounts; keyword and wildcard content filters. No moderator approval required.
+- Personal collections and bookmarks (private by default).
+- Self-service data export (right to access) and account deletion (right to erasure) with defined retention and purge windows.
 
 Exit criteria:
 
@@ -40,6 +46,11 @@ Exit criteria:
 - Project pages are discoverable and readable on one node.
 - Test coverage exists for core behavior paths.
 - At least one extension payload can be stored, validated, and rendered as non-breaking optional data.
+- A user can block another user and have that block take effect immediately without moderator involvement.
+- A user can bookmark and organize projects into personal collections.
+- A user can export all their personal data without admin involvement.
+- A user can delete their account without admin involvement; defined data purge window is enforced.
+- Data retention windows for authentication logs, session tokens, and IP records are implemented and documented.
 
 ## Phase 2: ActivityPub Foundation
 
@@ -62,12 +73,17 @@ Goals:
 - Federation-aware project discovery and attribution.
 - Local moderation controls for remote content and actors.
 - Abuse-report and review workflow for moderators.
+- User-level block and mute extended to remote actors and instances (no moderator gate).
+- Shareable and subscribable block lists and recommendation lists as federated first-class objects.
+- Public personal collections with AP identities.
 
 Exit criteria:
 
 - Moderators can block/mute remote actors and instances.
 - Remote project visibility follows local moderation policy.
 - Audit trail exists for moderation decisions.
+- A user can block a remote actor or entire instance without moderator involvement.
+- A user can publish a block list or recommendation list and another user on any instance can subscribe to it.
 
 ## Phase 4: Community Scaling
 
@@ -85,9 +101,10 @@ Exit criteria:
 
 ## Moderation Model Milestones
 
-- Milestone A: Local content moderation for local users.
-- Milestone B: Remote actor and instance policy enforcement.
-- Milestone C: Transparent moderation history and appeals guidance.
+- Milestone A: Local content moderation for local users, plus user-level blocks/mutes/keyword filters (no moderator gate).
+- Milestone B: Remote actor and instance policy enforcement; user-level blocks extended to remote actors and instances.
+- Milestone C: Shareable and subscribable block lists and recommendation lists as federated objects.
+- Milestone D: Transparent moderation history and appeals guidance; community-maintained shared lists.
 
 ## Federation Strategy Milestones