Aside from the RSVP / email reminders type of product focused on running events, there is a calendar / aggregator set of use cases.
For example, I run the atprotocol.dev account and also add events from the London, SF meetups and other ATProto stuff. I also run DWebYVR and Z-Space calendars in Vancouver where we encourage folks to submit events (all on Luma right now)
The pattern there is to make a “pointer” event if it’s not on Luma — eg link to Eventbrite. Or include a “native” Luma event.
My friend Andy is part of a crew in Vancouver who want to aggregate music events. He’s been doing some scraping. I’ve suggested a dedicated Smoke Signal instance — and maybe that’s the right size for aggregation?
eg if I want to run an ATProto Events calendar, because there is no “calendar” today, I run an instance.
That way I can control aggregation, including running a block list (don’t show events created by these DIDs), or an allow list (show all events by these DIDs only).
Smoke Signal Core is the global network aggregator today.
Lots of this would be visual and MIGHT be covered by a simple front end app and use SS core, but also if Railway template and one click hosting then maybe it’s simple enough to run instances.
Other directions: “claiming” events - eg if I enter in an event for IETF124, I’m not the organizer. But I’m curating it. IETF is unlikely to claim “my” event … but I do want to actually include the “real one”
Hmmm. DNS text record for a domain for proof of organized.
More later.