Recurring Events in Federation

Just a short update to let you know things are still moving forward!

The last months have been used to gain insight how and to which extend recurring events and series of events (as well as related events in general) might work in federation and be of benefit. This has involved a lot of exploration, design iteration, and discussions with people who are building or operating in this space. More interviews are planned to deepen this understanding further. If you want to have a chat about this, too, you’re welcome.

Before a first version (Fediverse Enhancement Proposal) is drafted a series of non-technical articles with findings, open questions, and options for broader feedback will be published in the upcoming weeks

Fediverse Reactions

All posts are licensed under CC-BY-SA 4.0

Comments

7 responses to “Recurring Events in Federation”

  1. @blog Does anyone out there who handles repeating events use anything other than RRULE and other related iCalendar spec properties? Even internally.

    1. @ekes @blog

      I think that @lauti by @klasse_methode is just using a very restricted subset of RRULE with their own logic internally.

      I haven't seen anything using https://schema.org/Schedule in production so far! I haven't searched a lot though!

      But I wonder, did your question have any concrete intention?

      1. @linos @blog @lauti @klasse_methode For UI input I'm sure I've only seen a subset of RRULE. I guess it's actually the only possible option. That subset even to how the same rule is produced FREQ=MONTHLY;BYDAY=1MO or FREQ=MONTHLY;BYSETPOS=1;BYDAY=MO for example. But the underlying libraries, of which there are so many now, can usually handle anything thrown at them though?

        1. @ekes @blog @lauti @klasse_methode

          True. I drafted a recurrence picker for the WordPress world using WordPress Gutenberg components and https://github.com/jkbrzt/rrule and it was charm, though tricky and not easy.

          In the backend I used https://github.com/rlanvin/php-rrule/wiki/RSet which was really straightforward.

          Maybe LAUTI will want to migrate too sometime, but first someone please give them the donations/funding so that they might be free to do so!

          1. @linos @blog @lauti @klasse_methode Last bit of code I pushed yesterday https://git.drupalcode.org/project/xdate_recur/-/blob/1.x/src/Element/XdateRRule.php?ref_type=heads also using rlanvin/php-rrule Still requires the handling for when it can't edit a rule, somer more js and formatting and some other bits.

          2. @ekes @blog @lauti @klasse_methode

            I went for storing a meta object for each event which contains:
            – rRules: array of RRules (=RFC-string)
            – rDates: array of RDates
            – eXdates: array of ExDates

            And in the Backend I just construct an RRuleSet using all of those if available.

            So I didn't need to construct any custom API at all and if I add new rules I wont have to change how backend and frontend communicate.

            And WordPress makes this really easy to validate and use in front and backend.

Leave a Reply

Your email address will not be published. Required fields are marked *