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.

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).
ADR for persistence layer architecture (PostgreSQL as primary target; repository abstraction pattern; query library selection; SQLite future-option strategy).
Documented container packaging path (OCI/Docker image build/run flow and configuration contract) alongside existing Nix and Flatpak targets.
Periodic packaging/tooling review policy so the flake and shell environments stay aligned with active roadmap phases and do not accumulate stale dependencies.
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).

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.
Support extension payloads on material entries using the same extension mechanism, enabling domain-specific material attributes (yarn weight, filament profile, component spec) without changing the core material record.
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 project-level extension payload can be stored, validated, and rendered as non-breaking optional data.
At least one material-level 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.

Goals:

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.

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.

Goals:

Exit criteria:

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.

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.