Events and Discovering Relevant Information Later

[jarofgreen]

I’m looking into events and ActivityPub federation. I have a scenario in mind and I’m curious how other people approach it.

Jan: Paul sets up an amazing event for September. As he creates it, a Create message is sent with type Event to all his followers and put on his public stream.

Aug: Jessica follows Paul for the first time. Paul does not edit the event so no messages are sent out about the event.

Sept: Jessica totally misses Paul’s great event, which she would have loved to have been involved in.

I’m new to ActivityPub so excuse me if this is dumb, but am I missing something here?

Does the way that messages are sent in a timely feed make this kind of information discovery difficult?

Maybe in Aug, when Paul’s server gets a “new follower” ping, could it respond by sending all upcoming events so the new person sees them? Would that result in flooding people, is that bad manners?

Or should it be up to Jessica’s server to go back through Paul’s feed looking for old messages that are still relevant?

Thanks for comments,

ps. This may be related to this comment from Murmurations protocol for directories and maps:

@AdamM

My impression has been that AP is designed for more chronological, feed-like content, while Murmurations is (for now) mostly about more static identity information about organisations. It would be great to hear your suggestions on how we can bridge the gap.

pps. I’ve also seen Events in ActivityPub - sorry I missed it. Gathio’s thing of making the event the Actor is very interesting, but doesn’t fit my use case.

[how]

I would suggest this is the responsibility of the client to check upon subscription the timeline of the followed account for future events.

[tcit]

@jarofgreen

Or should it be up to Jessica’s server to go back through Paul’s feed looking for old messages that are still relevant?

Paul’s outbox should contain Paul’s recent activities. Jessica’s server should crawl Paul’s outbox and get recent activities, such as the event creation.

Paul could also restrict the event access to their followers only and Jessica would use an authenticated fetch using HTTP Signatures to crawl the outbox. Paul’s server would check that Jessica is indeed a follower.

[jarofgreen]

Thanks to both @tcit and @how. So far 2 votes for the subscribing server having to check old messages then, and none for the subscribed server doing clever push stuff.

BTW, Would I be right in saying this isn’t defined in the standard anywhere, but is just up to common practice?