You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Split out of #228, which conflated two features under one title. #228 now covers the one-time deck importer; this issue tracks live, bidirectional sync, which is a much larger and later piece of work.
Why this is deferred, not just unscheduled
A server cannot reach AnkiConnect.AnkiConnect binds to 127.0.0.1 by default and gates browser callers through webCorsOriginList. An LWT server — self-hosted on a VPS, or lwt-online.org — has no route to a user's localhost. Telling users to rebind it to 0.0.0.0 and expose it to the network is not something we should ship.
The only viable architecture is client-side: browser JS running on the user's own machine talks to localhost:8765, with the LWT origin added to AnkiConnect's webCorsOriginList by the user. That means it is a frontend feature gated on a manual config step, not a server feature.
AnkiWeb has no public API, so syncing through Anki's own cloud is not an option.
Bidirectional sync is the conflict-resolution problem. The roadmap deliberately quarantines this to Phase 4: "Spike conflict resolution FIRST (the Anki problem) — it looks easy and isn't. Decide last-writer-wins+tombstones vs CRDT before committing." Two systems both mutating term state, both offline-capable, is exactly that problem.
Prerequisites
The scheduling half is now partly in place: Term status model: single source of truth + Anki/FSRS-aligned scheduling #238 phase 2a added FSRS-6 memory state (term_schedule) and an append-only review_log, with states matching Anki's cards.type. Phase 2b would populate cards.data + revlog in the .apkg exporter, which gets scheduling round-tripping by file — likely enough for most users who think they want sync.
Do the Phase 4 conflict-resolution spike before writing any sync code.
Recommendation
Ship the file-based path first (#228 importer + #238 phase 2b scheduling round-trip) and see whether real demand for live sync survives it. File round-trip covers the common case without owning a sync protocol.
Split out of #228, which conflated two features under one title. #228 now covers the one-time deck importer; this issue tracks live, bidirectional sync, which is a much larger and later piece of work.
Why this is deferred, not just unscheduled
A server cannot reach AnkiConnect. AnkiConnect binds to
127.0.0.1by default and gates browser callers throughwebCorsOriginList. An LWT server — self-hosted on a VPS, orlwt-online.org— has no route to a user's localhost. Telling users to rebind it to0.0.0.0and expose it to the network is not something we should ship.The only viable architecture is client-side: browser JS running on the user's own machine talks to
localhost:8765, with the LWT origin added to AnkiConnect'swebCorsOriginListby the user. That means it is a frontend feature gated on a manual config step, not a server feature.AnkiWeb has no public API, so syncing through Anki's own cloud is not an option.
Bidirectional sync is the conflict-resolution problem. The roadmap deliberately quarantines this to Phase 4: "Spike conflict resolution FIRST (the Anki problem) — it looks easy and isn't. Decide last-writer-wins+tombstones vs CRDT before committing." Two systems both mutating term state, both offline-capable, is exactly that problem.
Prerequisites
term_schedule) and an append-onlyreview_log, with states matching Anki'scards.type. Phase 2b would populatecards.data+revlogin the.apkgexporter, which gets scheduling round-tripping by file — likely enough for most users who think they want sync.Recommendation
Ship the file-based path first (#228 importer + #238 phase 2b scheduling round-trip) and see whether real demand for live sync survives it. File round-trip covers the common case without owning a sync protocol.