Not sure if anyone is thinking or doing encrypted draft backups yet, but damus is starting to look into this. We’re leaning toward nip44 envelopes of a new draft note kind.

Reply to this note

Please Login to reply.

Discussion

Was just about to head into the lab and work on this πŸ€“πŸ”₯

πŸ‘©β€πŸ”¬

Thank you πŸ™

β˜ΊοΈπŸ’œπŸ˜‚

I'd like to find a better solution than having Draft event kinds for every other event kind. I'd like to have drafts for everything, even reactions and custom zaps.

I was wondering if we shouldn't have just one Draft event kind where a full event is encrypted in .content and a `k` tag defines what event type this is about. Then apps could easily just download the drafts they have support for and decrypt them.

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.

I understood all of those words individually