also chiming in here after i referenced this in this discussion.
id mostly tend in the direction of putting more stuff directly in the event records for one reason mostly (hereby joining @essentialrandom.bsky.social in the crusade against sidecars :D): its easier to use for everyone, both for writing and for reading records, plenty of websites/apps want to display events and having to look for a bunch of sidecar records just to display complete event info is more work than it should be imo. there are also a few different ways to implement sidecars and its not clear which one is being used and you have to know to look for them (as usually theyre not being referenced by the main lexicon).
thinking about a website where i wanna display my events, the ideal flow is:
- i look at the lexicons for event and rsvp
- i get all my events from my pds
- i look for backlinks to those and get all those records
- …and thats it, i have everything i need.
(sidenote: rsvp is already more annoying than it should be imo, getting just the number of people that are going to an event requires me to fetch all rsvp records for that event and filter by #going)
regarding the point about rsvps being a strong-ref: as @gui.do pointed out events are expected to change anytime before their start date anyway (title, description, uris, location) and we usually expect rsvps to still be valid (atmo.rsvp already ignores the strong-ref part of rsvps 
)
my preferred schema would be adding a person array or something to event like this:
"person": [
{
"did": Did,
// open but include a few suggestions like in `media`, e.g. 'speaker', 'organizer', 'sponsor', 'guest'
"role": string,
// maybe some more stuff here...?
}
]
and then in rsvp also add an optional role so the other side can confirm.
gonna make an extra post regarding parentEvent, but id probably also add an extra eventRefs array with {event: at-uri, role: string} where role is again open and can e.g. be ‘parent’, ‘child’, ‘side-event’ etc