Let users store maps in the cloud instead of (or alongside) local files — save/load/sync a project by account rather than by file on disk.
Related to the Blender Mode push (#27) and separate from live collaboration (tracked separately), though the two will likely share the same storage layer eventually.
Open questions: backend (existing Supabase setup vs. something else), sync model (single-owner cloud save vs. multi-device sync), conflict handling if edited from two devices.
Let users store maps in the cloud instead of (or alongside) local files — save/load/sync a project by account rather than by file on disk.
Related to the Blender Mode push (#27) and separate from live collaboration (tracked separately), though the two will likely share the same storage layer eventually.
Open questions: backend (existing Supabase setup vs. something else), sync model (single-owner cloud save vs. multi-device sync), conflict handling if edited from two devices.
Correction to the open questions, from the roadmap audit 2026-09-05.
"backend (existing Supabase setup vs. something else)" is out of date twice over. There is no Supabase in this project and there never was one behind this - CLAUDE.md now says so explicitly. What exists instead is backend/, roughly 1.4k lines of Dart + Shelf + Postgres, built 2026-08-12, already doing maps CRUD (/v1/maps), static share links, live sessions and the agent proxy, with OIDC auth through garage_auth_backend.
So the backend question is answered: it is that. This issue is now about the client half - a cloud open/save path in the editor sitting on top of endpoints that already exist - plus the two questions that genuinely remain open:
sync model: single-owner cloud save vs multi-device sync
conflict handling when the same map is edited from two devices
Those two are the real content here, and the second is the one that overlaps #30.
Also worth noting for whoever picks this up: mapDocId was silently not being written by MapSerialisation.toJson until today, so every load minted a fresh document id. That is fixed on development. Any cloud sync scheme keyed on document identity would have been building on sand.
Correction to the open questions, from the roadmap audit 2026-09-05.
"backend (existing Supabase setup vs. something else)" is out of date twice over. **There is no Supabase in this project** and there never was one behind this - CLAUDE.md now says so explicitly. What exists instead is `backend/`, roughly 1.4k lines of Dart + Shelf + Postgres, built 2026-08-12, already doing maps CRUD (`/v1/maps`), static share links, live sessions and the agent proxy, with OIDC auth through garage_auth_backend.
So the backend question is answered: it is that. This issue is now about the client half - a cloud open/save path in the editor sitting on top of endpoints that already exist - plus the two questions that genuinely remain open:
- sync model: single-owner cloud save vs multi-device sync
- - conflict handling when the same map is edited from two devices
Those two are the real content here, and the second is the one that overlaps #30.
Also worth noting for whoever picks this up: `mapDocId` was silently not being written by `MapSerialisation.toJson` until today, so every load minted a fresh document id. That is fixed on development. Any cloud sync scheme keyed on document identity would have been building on sand.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Let users store maps in the cloud instead of (or alongside) local files — save/load/sync a project by account rather than by file on disk.
Related to the Blender Mode push (#27) and separate from live collaboration (tracked separately), though the two will likely share the same storage layer eventually.
Open questions: backend (existing Supabase setup vs. something else), sync model (single-owner cloud save vs. multi-device sync), conflict handling if edited from two devices.
Correction to the open questions, from the roadmap audit 2026-09-05.
"backend (existing Supabase setup vs. something else)" is out of date twice over. There is no Supabase in this project and there never was one behind this - CLAUDE.md now says so explicitly. What exists instead is
backend/, roughly 1.4k lines of Dart + Shelf + Postgres, built 2026-08-12, already doing maps CRUD (/v1/maps), static share links, live sessions and the agent proxy, with OIDC auth through garage_auth_backend.So the backend question is answered: it is that. This issue is now about the client half - a cloud open/save path in the editor sitting on top of endpoints that already exist - plus the two questions that genuinely remain open:
Those two are the real content here, and the second is the one that overlaps #30.
Also worth noting for whoever picks this up:
mapDocIdwas silently not being written byMapSerialisation.toJsonuntil today, so every load minted a fresh document id. That is fixed on development. Any cloud sync scheme keyed on document identity would have been building on sand.