Any event type. It's content-agnostic, as we've already come up with working examples for MP3s and stuff. Can also have different types of data in one. Like text interspersed with videos or graphics. Or indexes within indexes, to create a hierarchy, like in a ToC.
>>
Kind 30040 MUST have events listed in e tags in the order that they should appear, in the client. The events may be any already-existing events (including nested kind 30040s).
<<
Like so:
I wouldn't make it that generic otherwise it's just a list and should be part of NIP-51
But I do question if it makes sense to merge every type of event into just one kind. Clients will need to support all types of content just to be able to comply with the NIP. That is terrible for adoption.
You could do an event kind for a collection of articles, another for a music collection, etc.. Then clients that support them would only code the kinds that they offer support for.
