Replacing Event Generation from Google Event APIs to iCalendar (add serving own iCal feed)

[probablyangg]

Support RFC-5545

Goal

Update current Event management backend to support RFC-5545

• Update Recurrence rules (instead of duplicating events in the database use RRULEs)
• Create events
  • → send event invite to organizer
• RSVP to event
  • → send event invite to attendee
  • → update event to add attendee to the event
• Organizer Updates event
  • → update in database
  • → update the event on icalendar feed (SEQUENCE)
  • send event invite to attendees mentioning the calendar event was updated
• Organizer deletes an event
  • → make isDeleted = true in the database
  • → update event in the calendar feed
  • → send email to all RSVPs
• A new “Calendar” page that provides a iCal URL that anyone can copy and paste in their calendar app to subscribe to the events in that calendar
  • Data to display
    • calendar name
    • community name
    • iCal feed url
    • instructions on adding the ical subscription URL to calendar app (example)
  • A new email service that sends an email everytime an event is created (to the organizer), updated/deleted (to all attendees)

---

Current Events model and iCalendar data to implement

current `Event` model

model Event {
  id              String       @id @default(uuid())
  createdAt       DateTime     @default(now())
  updatedAt       DateTime     @updatedAt
  
  title           String
  descriptionHtml String?
  startDateTime   DateTime
  endDateTime     DateTime
  location        String
  ~~hash            String
  series          Boolean~~
  limit           Int
  
  // for deleted events
  // can be purged periodically
  isDeleted       Boolean      @default(false)

  ~~// google
  // gCalEventRequested Boolean      @default(false) // remove, deprecated
  gCalEventId     String? // KEEP, DONT REMOVE
  // gCalId             String? // remove, deprecated~~

  type            EventType    @default(JUNTO)
  proposerId      String
  proposer        User         @relation(fields: [proposerId], references: [id], onDelete: Cascade)
  rsvps           Rsvp[]
  collections     Collection[]

  ~~communityId     String?
  community       Community?   @relation(fields: [communityId], references: [id])~~

  calendarId      String?
  calendar        Calendar? @relation(fields: [calendarId], references: [id])

  // if the event was imported from convo.kernel.community
  // if it was, we do not have their RSVPs, since this version uses
  // user's addresses to make them unique and the previous version used
  // email addresses
  // having isImported = true, means
  // the UI will show an info box mentioning "This event was imported from the previous version of the app
  // and the total number of RSVPs might not be accurate. Please email
  // if you'd like to query any data related to RSVPs for this particular event"
  // the emails[], gcaleventREquested, gcalEventId will be accurate for these events
  // the proposer data will be inaccurate
  isImported      Boolean      @default(false)
}

`iCalendar` Event Data

export interface ICalEventData {
    id?: string | number | null,
    sequence?: number,
    start: ICalDateTimeValue,
    end?: ICalDateTimeValue | null,
    recurrenceId?: ICalDateTimeValue | null,
    timezone?: string | null,
    stamp?: ICalDateTimeValue,
    allDay?: boolean,
    floating?: boolean,
    repeating?: ICalRepeatingOptions | ICalRRuleStub | string | null,
    summary?: string,
    location?: ICalLocation | string | null,
    description?: ICalDescription | string | null,
    organizer?: ICalOrganizer | string | null,
    attendees?: ICalAttendee[] | ICalAttendeeData[],
    alarms?: ICalAlarm[] | ICalAlarmData[],
    categories?: ICalCategory[] | ICalCategoryData[],
    status?: ICalEventStatus | null,
    busystatus?: ICalEventBusyStatus | null,
    priority?: number | null,
    url?: string | null,
    attachments?: string[],
    transparency?: ICalEventTransparency | null,
    created?: ICalDateTimeValue | null,
    lastModified?: ICalDateTimeValue | null,
    class?: ICalEventClass | null;
    x?: {key: string, value: string}[] | [string, string][] | Record<string, string>;
}

defined here

Rethinking Communities, Events, Calendar, Collections and Users

• Each community gets associated Calendar(s)
• each Calendar has 1 associated community
• each Calendar has multiple associated events
• Events are only associated in a calendar (as a result each event is associated with one and only one community)

Event → Calendar → Community

• 1 event can be associated with 1 calendar
• 1 calendar can be associated with 0 or many events
• 1 calendar can be associated with 1 Community
• 1 Community can be associated with 0 or many Calendars

Event → Collection

• 1 Event can be associated with 0 or many Collections
• 1 Collection can be associated with 0 or many Events

User → Event

• 1 event can be associated with 1 or many Users (currently it is only associated with 1 user)
• 1 user can be associated with 0 or many Events

User → Rsvp

• 1 user can be associated with 0 or many Rsvps
• 1 Rsvp can be associated with 1 User only

User → Collection

• 1 user can be associated with 0 or many Collections
• 1 Collection can be associated with 1 or many users (currently only associated with 1 user)

Recurrence UI

We currently manage recurrence by creating duplicates of a particular event and assigning the same hash to all the events so the UI knows which events to put together on an event’s page (which is stupid tbh)

We use rrule library to set recurrence rules only because it has a nice toText() API that will make it easier to display the recurrence on event page (read more here)

The Event model would need to updated to add RRULE associated with each event. If it’s empty the event is not repeating

model Event {
	...
	...

+	rrule String?

	...
	...
}

→ On the event page, we update the right section with events to display the recurrence rule string (eg., Every 2 weeks on Friday for 6 times) which is clickable/tap-able. When you click the list of events slides down and user can scroll through all the upcoming dates and times in a list (only display first 5 if it’s an infinite event)

Example UI - https://ical.marudot.com/

Location Considerations

• iCalendar feeds would be public since they are subscribe-able, but I guess it will be ideal to not have sensitive information as publicly available. eg., attendees and location
• We can add convo app’s link to each event’s description & location URL so each event has an external URL to convo’s webapp that users go to to get the latest info on that particular event
  • they sign in - claim they are a part of the community and view the event page with the latest changes

Caveats

• Google calendar provides no way to update refresh duration of an iCal feed — gmail users would need to be provided an email that an update was made to an event they were RSVP’d to and an update ics file
  • Apple calendar gives an option to “auto-refresh”

Changes Required

• New email service to send custom emails with attached ics/ical files
• Update Event model
  • remove the attributes not required anymore (association with Community, google stuff)
  • update foreign keys (remove association with community, add association with calendar)
  • update APIs
  • update hooks
  • While we’re at it, rename Event to Convo 🙂
• Add new Calendar model & associations with Event and Community
  • example

    model Calendar {
      id String @id @default (uuid())
      createdAt   DateTime @default(now())
      updatedAt   DateTime @updatedAt
      name String?
      description String?
      events      Event[]
      communityId     String?
      community       Community?   @relation(fields: [communityId], references: [id])
    }

  • Add API to create a calendar & associate a community to it
  • Add API to update/delete a calendar
  • Add API to read a calendar
  • Add hook to fetch a calendar
• Remove Google model and associated APIs and backend services
  • Remove all google services & api usage
• Recurrence
  • add rrule to Event model (rrule String?)
  • Update propose form to add recurrence input + generate and send recurrence rule string to the backend along with all other event info
  • Update event page UI to display the recurrence text + 5 upcoming events
• Create
  • remove internal API call to google calendar create event
  • store rrule string to the database
  • create ics calendar file, attach and send email to the organizer
• Edit / Update / Delete
  • Add recurrence UI to edit page
  • update api: send email with updated ics for the event (update sequence)
  • delete api: delete the event from user’s calendar and send them cancelled ics (read in rfc)
• RSVP
  • send email to attendee with the ics file
• A new Calendar page /calendar/<COMMUNITY_SLUG>/<CALEDNAR_ID> that displays a list of all events in the calendar and a subscription URL
• iCal Subscription URL for the calendar feed (/api/services/calendar/feed?community=COMMUNITY_NAME)
• .ics attachment URL for each event in the database (also downloadable from the event page) (/api/serivces/calendar/event?eventId=EVENT_ID)

---

[vs77bb]

This is great work. While I digest, one question I have immediately is on: "Events are only associated in a calendar (as a result each event is associated with one and only one community)".

It feels to me that (one or more) communities, could be a nice pattern. Thoughts?

[probablyangg]

another very very relevant RFC - https://datatracker.ietf.org/doc/html/rfc5546