The Last Mile of Local-First
Feedback from Vojto
- wing the prompt - think it through
- introduce the idea of a last mile problem earlier in the talk - let them ponder on it!
- 4 things from my personal history: images / logos / image of daylight tablet
- Local-first Software Paper
- QR code
- snapshot of the paper
- Quotes are too much
- three words per slide
- JUST EXPLAIN
- three words per slide
- Phone line and the house
- "Not JSON"
- screenshot for import/export
- recording a screengrab of Linear -> Google Sheets
Feedback from Chad Fowler
- Don't make the AI stuff a bonus. Make it key.
- Move the OCIF announcement to the end.
Develop the analogy
- File export is like opening up the box to get to the data outside of the person’s home, but not running any cables to the home itself
- Continuous export is like running the read cable, but not the write cable
- bi-directional sync, you run both the read cable and the write cable
Abstract
We've mastered sync engines and seamless collaboration and our software rarely sees spinners, but we're still neglecting two of the core ideals: users have hardly more agency over their data than they did five years ago.
User data is still trapped inside applications in proprietary formats. We're delivering data to the device but not to the user's "premises": this is the Last Mile Problem of local-first software.
Researchers and framework authors have done their part to solve some truly hard problems. Now it's time for app developers to step up. I'll show you three levels of support that give users true ownership: basic export, continuous projection, and bi-directional sync.
If we get this right, users will control their data across applications forever—no more digital sharecropping, no more vendor lock-in, just data that flows freely between tools and outlives companies.
We've mastered sync engines and killed the spinners, but we're still failing at a core promise: users have no more control over their data than they did five years ago.
Why? Data is still trapped in proprietary formats inside apps. We're getting data to the device but not to the user's "premises"—that's the Last Mile Problem of local-first software.
The good news: Framework authors solved the hard technical problems, now app developers can solve the final piece. I'll show you three levels that unlock true user ownership: basic export, continuous projection, and bi-directional sync.
Get this right and users control their data across applications forever—no more digital sharecropping, just data that flows freely between tools and outlives companies.
Talk Notes
- Hi I'm Jess Martin
- Future of computing - app interoperability
- Local-first software can enable this
- a few problems yet to solve...
- Applied research - bridging the gap from academic research to build real systems imbued with these qualities
- A Local-first Scorecard → Just completed this landscape so I have a good sense of the progress
- In order to develop this resource, had to look at all of the systems that can be used to build local-first software and understand their capabilities
- Six years the article... we have solved many tech challenges
- uniquely positioned: Let's take a look at our progress on the Scorecard:
- No spinners: ✓
- Software has gotten faster!
- Multi-device is common: ✓
- Sync engines are amazing
- Network optional: -
- Still a lot of work to do to make P2P fully reliable and easy, but it's getting better
- Seamless collaboration: ✓
- Lots of hard work on CRDTs and other methods of reconciliation
- Security and privacy by default: -
- Some good talks on this!
- You retain ownership & control: ?
- The Long Now: ?
- No spinners: ✓
- one solution to the User-owned data and Long Now: file formats
- How might we solve these things with file formats?
- The last five years of advances have largely been solved by frameworks and libraries and a few intrepid software companies
- Pioneering, hard work!
- Here's an architecture diagram of what this looks like today:
- The "Last Mile" of local-first will have to be solved by application developers.
- <show image of telephone lines, tell story of the internet>
- We are getting the data all the way to the device, but not able to access it
- But just because data is on the device doesn't mean users can access it
- Especially if the data stays trapped in proprietary formats
Challenge for local-first app developers: levels of support
- This talk will be a challenge to app developers. I'm going to provide a set of levels to grade yourself on the support you provide to your users.
LEVEL 1: Export to flat file formats
- Just choose open formats
- markdown, CSV, etc → your app domain
- So many available - and you don't have to choose just one!
- markdown, CSV, etc → your app domain
- Sometimes, you have to invent one...
- Obsidian is well known for file > app
- Introduced a canvas feature - there's no file format
- JSON Canvas
- Introduced a canvas feature - there's no file format
- At the time, Orion Reed and I were doing canvas work
- DXOS - TLDraw - Doing export to file work, interop, etc
- Tried JSON Canvas - found it was too limiting to express the TLDraw, and other, infinite canvases
- Local-first Conf last year we wrote the version of a new spec & minimal implementation to handle many canvases
- Will come back to that story...
- Obsidian is well known for file > app
LEVEL 2: Continuous export
- Think of this as a continuous projection of the app's data to an external source
- Every write in the app causes a re-render of the projection
- Doesn't handle reads - just overwrites
- We already mentioned Obsidian
- Kanban.md demo
- Kanban.md demo
- Doesn't have to be files!
- Linear → Google Sheets DEMO
- Build charts, run calculations, etc
- Linear → Google Sheets DEMO
LEVEL 3: Bi-directional sync
- Much harder!
- Obsidian implements this via the file system
- Kanban.md can write, too!
- So satisfying to drag a card over!
- So satisfying to drag a card over!
- Kanban.md can write, too!
- But now we are back in the land of open research problems
- Substrate matters...
- File system? CLI agent? Desktop app?
- Particularly challenging for real-time collaboration, as changes aren't automatically available as "diffs" or "patches"
- And merging of offline edits
- Substrate matters...
- But amazing things are possible if you do the work...
- Show a Obsidian Canvas ⟷ TLDraw demo powered by OCIF
- Collaborate across applications!
- Show a Obsidian Canvas ⟷ TLDraw demo powered by OCIF
- What is powering this?
- So, resuming my story... we kept working on the infinite canvas file format...
- The Open Canvas Working Group met 25 times over the past year
- Git issues
- Input from 15 canvases
- Spec versions
- 3 implementations
- New collaborators
- Happy to announce today the OCIF 1.0 Candidate Recommendation
- We are following the W3C process
- Candidate Recommendation means:
- We feel the spec captures the majority of cases and is relatively complete and stable
- And now it's ready to be implemented
- Two app that have implemented already and we have a handful of demos
- But the spec will still change as we seek to incorporate feedback from implementers
- Candidate Recommendation means:
- Feel really good about the spec
- If you are working on a canvas, consider implementing import/export
- You can implement in our "tools" package which will give users access
- Through the CLI tool
- And through the exporter website
- You can implement in our "tools" package which will give users access
- We are following the W3C process
LEVEL 4: An added benefit/perk (?) AI understands open formats
- A few quick demos of AI working with OCIF
- AI explaining a canvas
- AI writing a canvas based on a prompt, etc...
- Use the local TLDraw instance & the OCIF file watcher...
To wrap up...
- App developers will have take us the last mile..
- Reiterate Last mile story - show the phone lines again
- Show score card again
- Encourage us to give users control and solve for the Long Now!