This is pretty much what I was thinking of, no reason why it needs to be kind1 only.
encrypted content contains the draft note, you could have k tag inside or outside depending if you want to leak and query on that.
For nostrdb I would just pull down all the encrypted draft notes, decrypt the content and then store the unencrypted draft note inside nostrdb so that I can query them locally, so inside works for me.
ohh I was thinking on encrypting the entire json of the event, not just the .content. In that way, you not only have the inside kind, but also all tags that were prepared for the event previously.
Then think the `k` tag should be on the outside event so that Clients can filter drafts by kind. Otherwise, it might be too many drafts for some clients.
Just thinking out loud though, I haven't tested any of this. It might be a bit hard to reassemble the New Post screen from a Nostr event as opposed to whatever the client uses to keep the state of the new post.
Draft zaps?
Scheduled zaps?
🤔
> ohh I was thinking on encrypting the entire json of the event, not just the .content. In that way, you not only have the inside kind, but also all tags that were prepared for the event previously.
This is what i meant
But then what's the use of the k encrypted inside?
I was thinking of an actual draft note kind since we need additional attachments that aren’t necessarily a part of the note (yet) like attached image urls (those get appended to the end of the note when draft is rendered to a kind 1). Although how that is represented would need a spec as well.
