This question has been asked few times: "Why wasn't this built on the VJOURNAL concept of the CalDAV standard?" It's a fair question that deserves a detailed answer.
The Promise vs. Reality of VJOURNAL
VJOURNAL exists in RFC 5545 as part of the iCalendar specification. On paper, it sounds perfect for journaling. In practice, it's a cautionary tale about the gap between standards and implementation.
Here's what I discovered when researching CalDAV as a foundation for Journiv:
Server Support is Inconsistent
- Nextcloud's VJOURNAL implementation is minimal at best
- Radicale and Baïkal have basic support with no extensions
- Apple Calendar doesn't support VJOURNAL at all
- Google Calendar ignores it completely
The Specification is Underspecified
- No standard for rich text formatting (only plain text in the DESCRIPTION field)
- ATTACH property is primitive and inconsistent across implementations
- No concept of tags, moods, or metadata as first-class citizens
- No query capabilities beyond basic date filtering
- No agreement on extensions for modern journaling features
Building on VJOURNAL would mean inventing a parallel extension layer anyway, which defeats the entire interoperability benefit while dramatically increasing complexity.
Calendar Thinking vs. Journal Thinking
CalDAV was designed for calendaring, and that design permeates everything about it. The data model, sync mechanism, and query patterns all assume you're working with time-bounded events with recurrence rules and scheduling.
CalDAV is optimized for:
- Time-bounded events with start and end times
- Recurrence rules and exceptions
- Scheduling and free/busy queries
- Synchronizing discrete, structured events
Journiv needs:
- Long-form narrative text as a first-class citizen
- Rich formatting with inline media
- Photos, audio, and video embedded naturally in entries
- Tags, moods, and custom metadata
- Deep analytics and insights across entries
- Memory resurfacing based on content and patterns
- Semantic search
Forcing a journaling application into a calendar abstraction creates friction at every layer. The mental model doesn't fit, the data structures fight you, and the complexity leaks into every client implementation.
Performance Matters
CalDAV uses XML-based protocols (WebDAV with iCalendar bodies). For calendar events with structured fields, this works fine. For journaling with potentially thousands of words of rich text and embedded media, XML becomes a performance liability.
Journiv's REST API with JSON is faster, more compact, and better suited to the content-heavy nature of journal entries. Journiv is being built not just for now, but for the future. When you're writing or searching through years of memories, that performance difference matters.
What Real Openness Looks Like
Here's where I want to challenge the assumption in the original question: that using an established protocol equals openness, and not using it equals lock-in.
True openness isn't about protocol compliance. It's about data ownership, portability, and long-term accessibility.
Journiv is open in ways that matter:
1. Self-Hosted and Open Source
- You run it on your infrastructure
- The backend is fully open source
- No company can change the terms of service and hold your data hostage.
2. Your Data, Your Database
- Take a database dump anytime
- Feed the schema to any AI tool and ask it to explore, analyze, or convert your data
- No proprietary formats, no vendor-specific encoding
3. Your Data, Your Database with Open Standards
- All data lives in PostgreSQL/SQLite with an openly documented schema
- OpenAPI/Swagger for comprehensive API documentation
- JWT authentication following OAuth2 patterns
- JSON for data interchange (the gold standard for interoperability)
- Standard media formats (JPEG, PNG, MP4, etc.)
4. Export Architecture
- Full JSON export of all your data
- Human-readable and machine-parseable
- Import/export plugin architecture (more on this below)
- Journiv-viewer (launching soon): a standalone, client-side browser application that visualizes your JSON exports without any server
- Convert exports to Markdown with frontmatter for ultimate portability
5. Long-Term Sustainability
Journiv is designed for decades of use. In 2045, you should be able to:
- Read your journal entries without Journiv
- Import your data into whatever tools you want
- Give your children your journals without depending on any service
Anchoring everything to a 20-year-old CalDAV abstraction that was never designed for journaling would freeze the data model and limit future innovation.
Interoperability Through Adapters, Not Constraints
The plugin-based import/export architecture means interoperability doesn't require building the core on CalDAV.
Want to bridge Journiv to VJOURNAL? Build an export adapter. Want to import from Day One, Obsidian, or plain Markdown files? Build an import adapter. The freedom of open source and open standards is that anyone can create these bridges without constraining Journiv's data model.
This approach keeps the internal architecture clean and purpose-built while still enabling standards-based integration where it makes sense.
If someone has existing VJOURNAL data, they can write (or request) an import adapter. If they need to export to VJOURNAL for some workflow, an export adapter can handle that. But Journiv's core isn't limited by CalDAV's calendar-centric worldview.
Standards Are Tools, Not Goals
Using a standard protocol should make your software better, not worse. CalDAV would make Journiv:
- Slower (XML vs JSON)
- More complex (calendar abstractions for journal entries)
- More limited (no rich features without custom extensions)
- Less maintainable (working around CalDAV's assumptions)
- Dependent on inconsistent server implementations
In exchange, you'd get theoretical interoperability with clients that mostly don't exist and servers that barely implement VJOURNAL anyway.
That's not a good trade.
The Real Question
The question isn't "Why doesn't Journiv use CalDAV?"
The real question is: "Can I get my data out of Journiv in formats I can use anywhere, now and decades from future?"
The answer is yes:
- Database dump with open schema
- JSON export with documented structure
- Markdown with frontmatter conversion via Journiv-viewer
- Standard media formats
- Plugin architecture for custom exports
Your memories belong to you. You can read them, export them, analyze them, and preserve them without depending on Journiv, CalDAV, or any other specific technology.
That's what openness means.
Have thoughts on data portability, standards, or journaling? I'd love to hear them. Journiv is built in the open, and decisions like these benefit from community input.