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.

Reply to this note

Please Login to reply.

Discussion

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.