FedDIY/docs/ROADMAP.md

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.

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.

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.

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.

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.

Exit criteria:

• Moderators can block/mute remote actors and instances.
• Remote project visibility follows local moderation policy.
• Audit trail exists for moderation decisions.

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.
• Milestone B: Remote actor and instance policy enforcement.
• Milestone C: Transparent moderation history and appeals guidance.

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.