Open SuperSonicHub1 opened 12 months ago
This could also be decoupled from account functionality; we currently have a functionality for URLs pointing directly to schedules, and we could similarly encode the schedule data into the URL itself to generate ics data and avoid keeping any knowledge of what user generated it (thereby presumably evading most privacy concerns).
encode the schedule data into the URL itself to generate ics data
this loses the "update as the user edits their schedule" aspect of the feature, although it would be a nice feature too
Oh, true. So, I guess this requires us to grow our own authentication or else somehow co-opt FireRoad authentication, either of which would require a proper backend.
Maybe it could edit the iCalendar URL using Google's OAuth, as the user updates their schedule, all completely from the client-side? Although this would go into why did Google Calendar export stop working in the first place?
Depends on #47; resolves #8.
Building on top of our ability to export schedules as iCalendar files (#22), this feature would expose users' schedules publicly over HTTP so they can be accessed by any calendar client and, crucially, update as the user edits their schedule. Users would have to opt into exposing their schedules public and the path to the schedule would be a hash/UUID as to avoid enumeration attacks and other kinds of information leaking.
We would also need to link to documentation explaining to users how to add their schedules to popular calendar clients; for MIT students, the most important ones to link to would be Google Calendar and Outlook Web.