[Proposal] replace TOAST UI Calendar with FullCalendar in the calendar app

[arisoik]

Greetings Peergos team,
Since Calendar app is by default in the main GUI of WebUI and looks
a bit outdated and it is not properly rendered in Android app, I decided
to invest time on refining and extending it but I wanted to check the direction
with you before investing the time needed. I made a plan with Claude Code
about the new library that can be used and also the extra features that can be
implemented to make the app more attractive to users.
What do you think?

Problem

The calendar app (assets/apps/calendar/) is built on TOAST UI Calendar
(tui-calendar.js, vendored). Both tui-calendar/@toast-ui/calendar npm
packages haven't had a release in ~4 years and appear to be unmaintained. In
practice this has made the calendar's layout fragile to work on - fixing
bugs has meant hand-patching the minified vendored bundle directly rather
than working with a maintained upstream.

The bigger motivation, though, is cross-platform usability rather than just
the maintenance status: the calendar needs to work well on mobile (the
Android app embeds this exact repo in a WebView; there's no native iOS app
yet, so iOS means mobile Safari for now) as well as desktop browsers, and
TUI Calendar's rigid, pixel-width-based layout is a poor fit for that.

Proposal

Replace it with FullCalendar (Standard bundle +
the RRule plugin):

• Actively maintained (10+ years, 100+ contributors).
• Both the Standard bundle and the RRule plugin are MIT licensed -
  confirmed via FullCalendar's own license page and RRule plugin docs. No
  Premium/commercial features needed for anything this calendar currently
  does.
• Ships a self-contained index.global.min.js UMD build usable via a plain
  <script> tag, so it can be vendored into assets/apps/calendar/ exactly
  the way the current libraries already are - no npm/webpack dependency
  introduced, consistent with the project's build philosophy.

Architecture stays the same. This would not change how the calendar is
wired into the rest of the app: same iframe-on-its-own-subdomain pattern used
by the calendar/code-editor/pdf/markdown-viewer sub-apps today, same
postMessage contract between Calendar.vue and the iframe, same .ics
file storage model owned by Calendar.vue (untouched). This is purely a
swap of the rendering library inside assets/apps/calendar/init.js - not a
rewrite of how the calendar talks to Peergos.

No drag-and-drop. Moving an event to a different day would go through the
existing edit popup's date field, not a drag gesture across the grid. This is
deliberate: FullCalendar has an open, closed-without-a-documented-fix issue
about event dragging not working inside an embedded Android WebView (works
fine in a regular mobile browser tab) - avoiding that interaction pattern
sidesteps the risk entirely rather than relying on it working.

Non-negotiable for this migration

• Full feature parity with the current implementation: recurring events
  (all RRULE options currently supported, plus per-occurrence exceptions and
  "this and future" edits), multiple calendars, sharing, ICS import/export,
  read-only/guest access, dark mode, timezone handling.
• .ics stays a standard, portable format. Export from Peergos must
  import cleanly into Google Calendar/Outlook/Apple Calendar and vice versa -
  this is already true today (plain RFC5545, standard PRODID tag) and must
  stay true after the swap.

Also proposing as new scope

• A basic event search box (search loaded events by title/location/
  description) - the current calendar has no search at all, and this seemed
  like a reasonable small addition while already touching this code.
• A "Duplicate" action on an event (creates a copy on a new date, pre-filled
  from the original, instead of a blank form) - also doesn't exist today.

[ianopolous]

Thank you for the proposal. I think it is good, and you are right that we need the calendar to look good on mobile. Rather than replacing the built-in calendar, the approach I would take is to get it working as a standard third party app. The only reason the calendar is built-in is because we wrote it before we had the app sandbox. This will quite likely need a few new permissions for apps like READ_CALENDAR and WRITE_CALENDAR, but we can add those. Then anyone can also write their own calendar apps with the standard permissions, we wouldn't have to be the gatekeeper.

[arisoik]

Sounds good. Two questions before I start:

1. Does the sandboxed-app approach change your view on the library (still
   proposing FullCalendar over TOAST UI), or is that still open?

2. The current permission list (STORE_APP_DATA, EDIT_CHOSEN_FILE,
   READ_CHOSEN_FOLDER, etc.) doesn't really cover what a calendar needs -
   automatic access to a dedicated folder plus cross-user sharing, not a
   per-use picker. What do you have in mind for READ_CALENDAR/
   WRITE_CALENDAR - one auto-created folder per calendar, and how would
   sharing between users work under this model? Are you implementing this
   yourself, or should I take a first pass at a proposal?

Scope otherwise is parity with what the built-in calendar does today
(including sharing/guest-link access) plus two small additions: event
search and a "duplicate event" action.

[ianopolous]

1. Fullcalendar looks nice yes.
2. The dir structure for the calendars and ical files would need to be the same, that is what the new permissions would grant access to. I don't think any new permissions are needed for sharing, that api already exists for apps (or if it is in the outer calendar wrapper I can port it - I need to check). The sharing would work exactly as it does now, via that api. Efficient search probably needs a new api.

[arisoik]

Hello @ianopolous,
I'm replacing the calendar with the FullCalendar as external app in this draft PR Peergos/example-apps#12.
Now it has mock data and I would like to hear your opinion for the current state of implementation.
Below you can find how to run it and some open points that I have. Note that shared calendars/events are not yet implemented.

Calendar app: two backend asks — permissions + search

The sandboxed calendar app is otherwise feature-complete against mock data —
every FullCalendar-facing mutation call is already written against the
shapes below. Two things are needed from core before it can go live: data
access, and real search. Both matter equally — without search, the app
only ever searches whatever's currently loaded client-side, which doesn't
scale to a real calendar history any better than having no data access at
all would block editing it.

Running it

No Peergos account needed for a quick look — it's static files, mock data
only, nothing server-side:

cd calendar/assets && python3 -m http.server 8080

then open http://localhost:8080/index.html?isPathWritable=true (append
&theme=dark-mode to preview dark mode).

To try it as an actual sandboxed app instead: upload this calendar/
folder into a Peergos drive, then select its peergos-app.json → Run App,
per the documented install flow. Either way the data is still mock/
in-memory until READ_CALENDAR/WRITE_CALENDAR land — this is for
reviewing the UI, not real storage yet.

1. READ_CALENDAR / WRITE_CALENDAR permissions

Asks for the same REST mechanism STORE_APP_DATA already provides
(GET/POST/PUT/DELETE/PATCH on /peergos-api/v0/data/path.to.file),
scoped to a different, existing directory instead of a fresh per-app one.

Note: the current built-in calendar (web-ui's Calendar.vue) never
used this REST API at all — it's privileged and calls
this.context.getByPath(...) directly, in-process. So this isn't "reusing
a REST path," it's a new REST-mediated route to data that today is only
reachable from privileged code. What is reused is the directory layout
itself, confirmed from Calendar.vue
(CALENDAR_DIR_NAME/DATA_DIR_NAME/NEW_CALENDAR_FILENAME/
CONFIG_FILENAME), not guessed:

<username>/.apps/calendar/App.config
<username>/.apps/calendar/data/<calendarDir>/calendar.inf
<username>/.apps/calendar/data/<calendarDir>/<year>/<month>/<id>.ics
<username>/.apps/calendar/data/<calendarDir>/recurring/<id>.ics

Granting access to this specific path (not a fresh per-app directory) is
what makes it migration-free for existing users.

Ask: READ_CALENDAR → GET, scoped to .apps/calendar/.
WRITE_CALENDAR → POST/PUT/DELETE/PATCH, same scope. Same shape
STORE_APP_DATA already implements, just pointed at an existing directory.

Open question: is .apps/calendar/ special-cased in core since it
predates the app sandbox, or does granting a permission access to it work
exactly like STORE_APP_DATA does for a fresh directory? Can't tell from
client code.

2. Search API

Client-side search (matching against whatever FullCalendar currently has
loaded) is already built and works, but it isn't real search — it can't
see anything outside the loaded date range, which for a long-running
calendar is most of a user's history. You flagged this yourself as needing
a new API. Proposed shape, consistent with the data API above:

GET /peergos-api/v0/data-search/path.to.dir?q=<query>

scoped to READ_CALENDAR, returning matching file paths under
.apps/calendar/data/<calendarDir>/ — the app already has everything it
needs to turn a path back into a real event (same id/year/month encoding
as the file layout above). Text match against title/location/description
would cover what the client-side version already searches.

[arisoik]

I would like also to point out that with calendar being in an iframe you are not allowed to download lets say an event as an .ics file or you can't have calendar reminders in Android app. I think that these feautures could be valueable for Android app users and having this app as external they can't be used. What is your opinion on this?