Add a calendar for open community calls.

[tombentley]

We're going to try using Jitsi since it seemed to
offer the best combination of features:

• no time limit
• ability to record meetings + publish on youtube.

The .ics file is hand-crafted, but validated
using https://icalendar.org/validator.html and also checked in Google calendar.

Using the webcal: pseudo-protocol for the link on the page should mean the browser passes the URL to the calendar app to be subscribed-to there.
That should cause the calendar app to regularly
poll for updates, in case we decide to cancel/reschedule meetings. I thought that was preferable to the user downloading a .ics and importing and then us making changes to the schedule making the imported event
series stale.

Putting these two together means we should have the liberty to cancel (using EXDATE:) and reschedule events if we need to. Note that I've already excluded
New Years Eve 2026 using EXDATE:.

[tombentley]

The ics format lacks support for comments :-(

[tombentley]

I'm using UK-centric notions of morning and eventing, since those are compatible with the meetings being in UTC.

[tombentley]

Both the events in the calendar repeat every 4 weeks. You have to include the BYDAY thing to get the recurrance on the right day of the week (it doesn't just figure it out from working forwards from the DTSTAMP). I realised that the notion of day is problematic because of the timezones we work in. The schedule means that the meets are always on a NZ Thursday, but that means half of them are a UK Wednesday.

[tombentley]

This shows how we can exclude some events from the series.

[tombentley]

Physical lines need to be <72 chars. A logical line can be split over multiple physical lines, and I think WS at the start of a physical line is ignored.

[tombentley]

Splitting the URL is a bit 🤮 , but doing so gets rid of a warning from the validator.

[tombentley]

Note the webcal: protocol. I've not actually tested this bit yet.

[tombentley]

Pushed a 2nd commit which:

• reorders the cards on the 'join us' page and adds one for the youtube channel
• puts all the community call info on a single page, because there was a bit too much to say for the card on the join us page
• on the separate page I show the upcoming events using a js library.

[SamBarker]

trying to subscribe locally (webcal://localhost:4000/join-us/community-call.ics) fails jekyll logs

[2026-03-03 17:16:39] ERROR bad Request-Line '\x16\x03\x01\x05�\x01\x00\x05�\x03\x03���o�'�¬s���\b\vYT�3YN��S�R�\x10�\x17� 6Z\x12�0'�]k��hJyV�\x02-�\x12�Ώ���+t�aq\x00*JJ\x13\x02\x13\x03\x13\x01�,�+̩�0�/̨�'.
[2026-03-03 17:16:39] ERROR bad Request-Line '\x16\x03\x01\x05�\x01\x00\x05�\x03\x03&��5�Fo���\x0F\v/�wĉ\\Զ/b\e&�jF\ev\x7F ��QY\t�\\�\x19�����&\x02�\x19r�y�>6�[���\x00,ZZ\x13\x02\x13\x03\x13\x01�,�+̩�0�/̨�'.
[2026-03-03 17:16:39] ERROR bad Request-Line '\x16\x03\x01\x00�\x01\x00\x00�\x03\x01'.

[tombentley]

trying to subscribe locally (webcal://localhost:4000/join-us/community-call.ics) fails jekyll logs

Doh, I had the wrong URL after factoring it out to a separate page. Can you pull and try again? (you can set hostname: localhost:4000 in the _config.yml).

[tombentley]

trying to subscribe locally (webcal://localhost:4000/join-us/community-call.ics) fails jekyll logs

Doh, I had the wrong URL after factoring it out to a separate page. Can you pull and try again? (you can set hostname: localhost:4000 in the _config.yml).

After making this change local testing revealed that I don't have an application locally installed for this text/calendar content type. But that suggests that Chromium knows what to do with it.

[tombentley]

[SamBarker]

If I hit localhost:4000/join-us/community-call/community-call.ics using curl I get the file ics file as I expect however if I try and subscribe via the mac calendar app I see

[2026-03-04 09:08:10] ERROR bad Request-Line '\x16\x03\x01\x05�\x01\x00\x05�\x03\x03&E/t\x15~�I\x1E����\\�/;��o\x16vI�`D�\aH +��\x0F��6���9(�o\x04q�uU��\x15\x0F\x02��'.
[2026-03-04 09:08:10] ERROR bad Request-Line '\x16\x03\x01\x05�\x01\x00\x05�\x03\x03T�ib��D�e\x17�A�Xx�+?|�Q_\x10��\tV%\x19(� &Z#�(��ŀ\x15��*�ZD���<�y�e\x10M�`�t�\x00,jj\x13\x02\x13\x03\x13\x01�,�+̩�0�/̨�'.
[2026-03-04 09:08:10] ERROR bad Request-Line '\x16\x03\x01\x00�\x01\x00\x00�\x03\x01u�YO����)�5\x7F:\b+'\x13l�Db�\x7F�e)�4\t\x10�\x00\x00\x14�'.

I'll try and debug further.

[tombentley]

If I hit localhost:4000/join-us/community-call/community-call.ics using curl I get the file ics file as I expect however if I try and subscribe via the mac calendar app I see

[2026-03-04 09:08:10] ERROR bad Request-Line '\x16\x03\x01\x05�\x01\x00\x05�\x03\x03&E/t\x15~�I\x1E����\\�/;��o\x16vI�`D�\aH +��\x0F��6���9(�o\x04q�uU��\x15\x0F\x02��'.
[2026-03-04 09:08:10] ERROR bad Request-Line '\x16\x03\x01\x05�\x01\x00\x05�\x03\x03T�ib��D�e\x17�A�Xx�+?|�Q_\x10��\tV%\x19(� &Z#�(��ŀ\x15��*�ZD���<�y�e\x10M�`�t�\x00,jj\x13\x02\x13\x03\x13\x01�,�+̩�0�/̨�'.
[2026-03-04 09:08:10] ERROR bad Request-Line '\x16\x03\x01\x00�\x01\x00\x00�\x03\x01u�YO����)�5\x7F:\b+'\x13l�Db�\x7F�e)�4\t\x10�\x00\x00\x14�'.

I'll try and debug further.

The way I believe it's supposed to work is:

• the button link uses webcal:.
• the browser is supposed to know to pass the http:-ified URL to the calendar app.
• the calendar app GETs the ics (and polls for updates).

I think you're posting the webserver logs above? And it seems to be receiving a weird non-HTTP request. But what's the client/UserAgent (do we know for sure that it's iCalendar) and what's the method it's using.

Can you try without the splitting of the URL logical lines in the .ics?

[robobario]

LGTM, I deployed it to my fork with the change I've suggested

https://robobario.github.io/kroxylicious.github.io/join-us/community-call/

you can see the subscribe link is webcal://robobario.github.io/kroxylicious.github.io/join-us/community-call/community-call.ics

and I imported that into GCal by clicking subscribe in chrome, the calendar is named correctly and looks good

[robobario]

ah I can see a bi-weekly in the calendar, where I thought you'd picked Fortnightly earlier?

[tombentley]

@robobario I think I

ah I can see a bi-weekly in the calendar, where I thought you'd picked Fortnightly earlier?

Fixed already I believe.

[SamBarker]

The way I believe it's supposed to work is:

• the button link uses webcal:.
• the browser is supposed to know to pass the http:-ified URL to the calendar app.
• the calendar app GETs the ics (and polls for updates).

I think you're posting the webserver logs above? And it seems to be receiving a weird non-HTTP request. But what's the client/UserAgent (do we know for sure that it's iCalendar) and what's the method it's using.

Can you try without the splitting of the URL logical lines in the .ics?

So if I change the subscribe URL in the calendar from webcal to http it subscribes correctly but the log lies still appear. I Haven't figured out what the Mac OS calendar is doing but things look good

[tombentley]

@SamBarker

So if I change the subscribe URL in the calendar from webcal to http it subscribes correctly but the log lies still appear. I Haven't figured out what the Mac OS calendar is doing but things look good

I think that would mean the browser does the GET, sees the ContentType response header and passes off the content to the calendar app. Thus it would be a download, rather than a subscribe. My mental model could be wrong (I don't have a mac, so I have little idea how the Mac OS Calendar works). But I think the problem with download is that if we subsequently change the ics (e.g. to cancel a meeting) then it won't get updated in the calendar. I'd like to avoid that if possible.

[tombentley]

I managed to import the calendar into Outlook (the web version), though by pasting the webcal: link into Add calendar > Subscribe from web rather than by clicking on the button (because the Fedora doesn't have any native applications for ical).

[SamBarker]

@SamBarker

So if I change the subscribe URL in the calendar from webcal to http it subscribes correctly but the log lies still appear. I Haven't figured out what the Mac OS calendar is doing but things look good

I think that would mean the browser does the GET, sees the ContentType response header and passes off the content to the calendar app. Thus it would be a download, rather than a subscribe. My mental model could be wrong (I don't have a mac, so I have little idea how the Mac OS Calendar works). But I think the problem with download is that if we subsequently change the ics (e.g. to cancel a meeting) then it won't get updated in the calendar. I'd like to avoid that if possible.

I maybe wasn't clear the change in subscribe URL was within the calendar app. It seemed it understands that it is a subscription rather than a one off download, but doesn't understand how to resolve webcal as a protocol. If I tell it its http instead of webcal it starts a subscription and imports the events correctly.

[tombentley]

I've had second thoughts about the UX. My own inability to test this (given I don't have a native calendar application) led me to quiz Gemini about the usability of this for all visitors to the site. It's suggested a different approach which doesn't rely the combination of browser + calendar handler, but puts the onus on the user to choose the approach which works for them.

[robobario]

I'm freshening up my fork now, would be interested to see if you can subscribe to one over the public internet as opposed to localhost @SamBarker