Matsubaa
941a9da928
- 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.
119 lines
5.3 KiB
Markdown
119 lines
5.3 KiB
Markdown
# FeDIY Roadmap
|
|
|
|
This roadmap prioritizes a usable core product first, then federation depth and community scaling.
|
|
|
|
## Product Intention
|
|
|
|
Build a federated DIY project-hosting platform in Rust, inspired by the utility of Ravelry and Instructables, but interoperable through ActivityPub.
|
|
|
|
## Phase 0: Foundations
|
|
|
|
Goals:
|
|
|
|
- Stabilize development environment and reproducible tooling.
|
|
- 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:
|
|
|
|
- Agreed glossary and architecture baseline.
|
|
- Documented contribution and branch workflow.
|
|
- CI skeleton in place for formatting, linting, and tests.
|
|
- 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)
|
|
|
|
Goals:
|
|
|
|
- User identity and basic authentication model.
|
|
- Core DIY project entities (project, materials, tools, steps, media, canonical links, tags).
|
|
- 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:
|
|
|
|
- A user can publish and update a complete project end-to-end.
|
|
- 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
|
|
|
|
Goals:
|
|
|
|
- Implement canonical actor and object mapping.
|
|
- Add outbox/inbox behavior for core project publication events.
|
|
- Add HTTP Signatures and key lifecycle strategy.
|
|
|
|
Exit criteria:
|
|
|
|
- Instance can send and receive baseline ActivityPub messages for supported objects.
|
|
- Signature validation and delivery retry logic are documented and tested.
|
|
- Interop checks completed against at least one external implementation target.
|
|
|
|
## Phase 3: Federation UX and Safety
|
|
|
|
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
|
|
|
|
Goals:
|
|
|
|
- Collaborative project patterns (forks/remixes, references, revisions).
|
|
- Better onboarding, templates, and curation flows.
|
|
- Operational hardening (backups, observability, incident playbooks).
|
|
|
|
Exit criteria:
|
|
|
|
- Multi-contributor workflows are clear and reliable.
|
|
- Admin operations are documented with tested recovery drills.
|
|
- Performance and reliability SLOs are defined and measured.
|
|
|
|
## Moderation Model Milestones
|
|
|
|
- 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
|
|
|
|
- Milestone A: Strictly scoped protocol subset with explicit compatibility statement.
|
|
- Milestone B: Progressive support for richer activity types.
|
|
- Milestone C: Interop matrix and periodic federation health review.
|
|
|
|
## Review Cadence
|
|
|
|
- Revisit priorities every 2 weeks.
|
|
- Re-scope phases quarterly based on delivery and federation feedback.
|