Solid Calendar App

Build a Solid App Ideas for Solid Apps
1

A thread for people looking to work on a calendar app.

1 Like
I need help for my thesis proof-of-concept
2

I’m planning on building a calendar and task management app on top of linked data technology.

4 Likes
3

I’m also interested on building calendar app although I have only limited time to work on it.

1 Like
4

I think team/family calendars and to do lists are a great show case for how to use private data without centralizing them.
I have some - very traditional though - IT background and could support such an undertaking in my free time as a hobby.
Is there any activity going on?
Regards Eberhard

1 Like
5

Only “activity” what I have done is just checking how could I start implementation. So basically I haven’t done anything concrete. I was thinking to get some open source React based calendar as a base and then add Solid functionality to it.

But, due lack of time, this is all I have done so far.

6

I am working with a team which recently created an alarm app which has a backend similar to a calendar which can be found here http://forum.solidproject.org/t/common-core-ontology-with-linked-data/1860. We would be able to easily create a calendar app that can read/write data from a user’s solid pod.

5 Likes
7

Hi @Dylan24Martin,

Wonderful! Perhaps you could add it to the app listing https://github.com/solid/solid-apps

Mitzi

8

I will add add it to the app listing, currently I am in the early stages of development. Currently I plan allowing users to create and store events in their pod as well as querying events back that occur on a specific date. If anyone has any additional ideas or features they want to see added or want to help please let me know. Thanks.

9

I just completed the alpha version of my calendar app which stores data in a user’s card. I did not implement remote hosting yet however you can clone it from https://bitbucket.org/dylanmartin/solidcalendar/src/master/. This is one of my first web apps so please give me feedback. Thanks.

5 Likes
10

Just rolled out an update for the calendar app where the app now stores the events in a document called events in the user’s private folder instead of appending it to the card.

13

It’s a great idea to create your own calendar app. If you are interested in this process, I recommend that you read the Cleveroad article. How to Make a Calendar App: Use Cases and Tech Stack

1 Like
14

In case this is of interest to anyone. As a quick PoC I made a quick and dirty calendar app based on ICAL files stored in a Solid pod. If nothing else, I had fun making it :slight_smile:

1 Like
15

Hi everyone,

I’d like to share a project I’ve been working on and get some feedback from the community.

PodCal is a scheduling tool — similar to Calendly — built on Solid Pods. It gives users a public booking page where clients or colleagues can pick a time and book a meeting, with all the scheduling data stored in the user’s Pod.

Live at podcal.eu — source code at GitHub - zerolimit-es/solid-scheduler: Privacy-first scheduling powered by Solid Pods — a self-hosted, open-source alternative to Calendly · GitHub (MIT licensed).

How Solid fits in

  • Authentication: Solid-OIDC. Your identity is portable and not locked to PodCal.
  • Data storage: Bookings, events, and availability live in the user’s Solid Pod as the source of truth.
  • Performance cache: We also maintain an encrypted EU database (Scaleway, France) that acts as a read cache for the public booking page. Visitors picking a time slot don’t need Solid credentials — the booking page reads from the cache. Writes go to both the Pod and the cache. Users can wipe the server copy at any time.

This dual-storage approach was a pragmatic trade-off. Pod-only reads were too slow for a public-facing booking page, especially when the visitor doesn’t have a Pod themselves. It works, but I’m not fully satisfied with it and would love to hear how others are handling this.

What it does today

  • Multiple event types (custom durations, buffers, availability windows)
  • Built-in calendar at calendar.podcal.eu (day/week/month/agenda views)
  • CalDAV sync with Nextcloud, Radicale, Google Calendar, iCloud
  • ICS feed output — works with Proton Calendar
  • Email notifications with .ics invites
  • Timezone detection for visitors
  • Team scheduling (round-robin, collective)
  • Webhooks (Zapier, n8n, custom backends)
  • Custom branding on booking pages

Questions for the community

I’d genuinely appreciate input on a few things:

  1. The caching pattern: For those building Solid apps with public-facing UIs — how are you handling the performance gap between Pod reads and what users expect from a modern web app? Are there patterns emerging that I should look at?

  2. Serving unauthenticated visitors: A booking page needs to show availability to someone who may not have a Solid identity. Right now we solve this with the server cache, but it feels like there should be a more “Solid-native” approach. Any thoughts?

  3. Pod provider compatibility: Which providers are people here using most? We’d like to broaden our testing.

  4. The app directory: I saw @nikolaswise’s app directory — I’ll be submitting PodCal there. Are there other directories or listings where Solid apps should be registered?

SoSy 2026

I’ll be at the Solid Symposium in London at the end of April. If anyone wants to chat about the architecture, the trade-offs, or just see a demo, I’d love to connect there.

Thanks for reading — looking forward to the discussion.
Damien

16

Great work, PodCal is exactly the kind of real-world application that stress-tests Solid’s practical limits, and I appreciate you being upfront about the trade-offs rather than overselling the architecture.

Your dual-storage approach is pragmatic and, honestly, probably the right call for a public booking page today. I’ve run into the same friction building on Community Solid Server, cold Pod reads on a resource that has no warm HTTP cache are slow enough to break UX expectations for unauthenticated visitors. I don’t think there’s a “pure Solid” solution yet that matches what users expect from a modern scheduling tool.

One pattern worth considering: if the public booking page only needs availability windows (not full event data), you could structure that as a small, highly cacheable public resource in the Pod, essentially a read-optimised projection of the user’s schedule and let standard CDN edge caching do the work. That narrows what needs to hit the server cache. But it still requires the user’s Pod to be reachable, which is its own reliability concern.

This is one of the genuinely hard design problems in Solid today. The spec assumes both parties have a Solid identity, but most real-world interactions involve at least one party who doesn’t. I haven’t seen a clean native solution emerge yet, the server-side cache you’ve described is what I suspect most teams end up building.

I run privatedatapod.com. Happy to be a test target and I’ll check out PodCal today.

If you’re looking for somewhere to list PodCal alongside other Solid apps, privatedatapod.com/apps is a directory I maintain — happy to add PodCal there. It’s aimed at end users evaluating what they can actually do with a Solid pod, so a scheduling tool would be a natural fit.

17

Nice job.
I tried your app very quickly with a free account.

  • usually to not impose a definitive location solid apps use follow your nose discovery
    • in webID find publicTypeIndex and store the app container/folder
      • you ask the user for container/folder location with a default
      • and store the app container/folder
  • to improve performance you could consider
    • creating an index
    • and/or re-group the meetings by d/m/y or w/m/y or m/y (you could look at solidos Longchat chat.ttl that also works as Append only)
18

Thank you @pod42 for the feedback and pointer, much appreciated.

19

Thanks @bourgeoa Very detailed and useful feedback, super appreciated!

I have implemented the publicTypeIndex registration.

I like your idea about the regroup by meeting date as it will reduce HTTP requests and make date-range queries efficiient but it is a significant architectural change so I need to think carefuly about how best to tackle this one.

As for the append-only on Turtle on Solid pods, do you not believe it will create concurrency issues? Maybe I’m deeply wrong on that point but it is my initial feeling.

20

Append only and signed meeting may not be of any use in your case it may be helpful when more than one user can create/edit delete meetings.

I was thinking about your question on meeting with people not having webID’s.
You may use an app webID. I have no experience, but you may ask on the forum or better on Matrix chat