Bridging calendars (.ics/iCalendar feeds)

[craigS89]

Something i have been thinking about is in the same way the bridge currently converts RSS feed entries into posts, it could bridge .ICS iCalendar feeds in a similar fashion.
Nearly all popular calendar services give the option to share a subscribable ical feed, so the ability to bridge this to social protocols would be very handy.

Use-case Example

GIVEN I Maintain a publicly viewable google calendar for community events called "fun events"
and i wish to Make these events available to a wider audience.
WHEN i enter the calendar's iCalendar feed address into cal.brid.gy
THEN people can subscribe to the calendar at @[email protected] on an activitypub service
And people can subscribe to the calendar at @fun-events.cal.brid.gy on an atproto service

For activitypub

For bridging to activitypub the entries in the ical feed would be bridged into "Event" and "Location" object type posts (https://www.w3.org/TR/activitystreams-vocabulary/#dfn-event),
these are currently used by Gancio, Mobizillion, and the Wordpress Event Bridge Plugin, and are visible through most activitypub sites like mastodon as posts showing the details.

For ATproto

For ATproto posts would be translated to the calendar event and location lexicon currently used by Dandelion and Smoke Signal

Further Considerations

This could also lay the groundwork for Being able to bridge the aforementioned AP and AT Services already in use.

[snarfed]

Interesting idea, thanks for filing!

#1004 and snarfed/granary#1036 are probably prerequisites here. Notably, we'd probably end up bridging AP and AT events, RSVPs, etc before we add ICS support, not after.

The main reason I'd be reluctant here is that (afaik) ICS is primarily one-way, not bidirectional, and we're mostly interested in networks that we can bridge fully, bidirectionally. Evidently RFCs 2446 and 2447 (iTIP) extend ICS to do collaboration, but I don't know how much adoption they have. I suspect not a ton, and primarily in enterprise environments, which obviously isn't us.

This could be a good candidate for a standalone service, a la https://bluesky-atom.appspot.com/ . granary and arroba could do much of the heavy lifting, at least after snarfed/granary#1036 is implemented. You might only need to add a bit of glue code. Happy to help if you want to try!