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/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