FSRS

[migueltorrescosta]

Is your feature request related to a problem? Please describe.
FSRS outperforms SM-2 in memory retention, having been adopted by Anki and other similar tools.

Describe the solution you'd like
Replace SM-2 with FSRS

Describe alternatives you've considered
Forking the repo to implement FSRS

Additional context
The algorithm used reduces annoyance with revisiting cards unnecessarily

[DavidMiserak]

Thanks for bringing this to my attention. It may be a good idea to support multiple Spaced Repetition algorithms that a user could select.

[DavidMiserak]

Please checkout the develop branch and try to manually test the FSRS.

[migueltorrescosta]

I have. Thank you for the quick work. Questions:

• Why do individual cards need to store the algorithm used?
• FSRS requires a few per card values to be stored: stability, difficulty, retrievability, elapsed time history, optimization parameters. These are not described in the task.

There are 2 main issues:

1. Ensuring that FSRS has all that is needed for it to work
2. If a user changes memorisation algorithm, the values above should be stored regardless: they are needed to allow users to change the algorithm used at any time.

[DavidMiserak]

Thanks for testing and for the detailed technical feedback — these are valid points.

Why do individual cards store the algorithm?

The per-card Algorithm field is used by the scheduler dispatcher (ScheduleCard()) to know which algorithm computed the card's current state (its Ease or Retention values). The deck-level field is the user's global preference; the per-card field records what was actually used when the card's SRS parameters were last updated. This matters during transitions: cards individually migrated to FSRS state carry "FSRS", while cards still holding SM-2 parameters show "SM2" — the toggle operates card-by-card. That said, this design does create redundancy in the common steady-state case, and we're open to simplifying it if a cleaner approach emerges.

FSRS state completeness

You're right, and the code acknowledges it directly — the FSRS scheduler is explicitly marked as a placeholder (internal/srs/algorithm.go lines 117-118):

// Approximate FSRS formula (placeholder for MVP)
// Real FSRS has 17 parameters; this uses fixed approximate values

What's currently in the Card model:

• Retention float64 — a proxy, not true FSRS retrievability
• EaseBackup float64 — snapshots SM-2 ease at toggle time for rollback

What's missing for real FSRS:

• Stability float64 (S) — the forgetting curve anchor
• Difficulty float64 (D) — card-specific difficulty (note: the YAML difficulty: key currently maps to SM-2 Ease, which would need resolving)
• The 17 FSRS optimization parameters (could be global defaults or per-user tuned)

Your second point about algorithm switching is also correct: if real FSRS state were added, it should be preserved when switching to SM-2 (not zeroed out), so switching back to FSRS restores the real state rather than restarting from scratch.

An ask

You clearly understand FSRS deeply — you identified exactly what's missing. Would you be interested in opening a PR to implement the real FSRS state and scheduling formula? We'd be glad to review and merge a proper implementation. If you want to discuss the data model changes before starting, open a design discussion and we can work through the schema together.

[migueltorrescosta]

Unfortunately I don't currently have the availability to implement it.