The thing about this is that it can be an anthology, a collection... anything that is assembled, grouped, or curated.

Reply to this note

Please Login to reply.

Discussion

But it is for texts only, right? Or are you proposing any list of events, like NIP-51 does?

we considered that, but decided that if someone wan't to use existing events to aggregate together, we will have a 'carbon copy' process, which transforms (automatically, or made by the user) it into a 30041. That way, the poster has agency over what they want in the collection.

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.