Oddbean

So, I'd go for #3: have a pre-selection dialog for the kind pattern (currently 30040/30041s or each kind alone), and have a small drop-down label, above or next to each section, where they can adjust the kind, but that is currently disabled and read-only. (They'll eventually need to be able to add/remove sections, as well, but that's future music.) 30041 alone because they may already have a 30040 and just want to add something new to the list. 30040 alone because they may just want to create an index for things that already exist.

LOL changed my mind, after Reading what @Low Information Voter said. Want three steps, like a little wizard, so that they can follow what the client is "doing". 1) Pretty asciidoc preview 2) Kind structure selection dialog 3) Split view with disabled kind labels

I would think that creating an index of things that already exist would be a separate workflow. It might start while browsing in reading view. The user clicks a button next to a note that says "remix" or "add to index," and they are taken to an editor/search view where they can find other notes to add to the index and/or write their own content. I still need to think that through, since it's different from purely writing new content. Kind selection also impacts how we might parse the AsciiDoc content. If a user wants to publisj a wiki article, we probably wouldn't break down the content into smaller events. Rather, it would be one large wiki event kind. I'll have to think through how to represent that in the UI. Changing kinds may cause sections to merge together and such.

30041 by itself is perfectly reasonable - something to group together later on, perfectly alignes with the idea of 'Zettel'. You can publish 20 events of random notes coming from spontaneous ideas, the benefit being that it's nostr native but explicitely won't flood your followers' feeds like wiki articles.