@staab

Versions should be handled using new kinds, rather than references to schemas (this feels very xmlns ish)

forms would need to have multiple versions in parallel. For example see something like typeform and google forms, both have a separate set of features and need a different template to work with, but both could exist in parallel. I agree i'm not a fan of such namespacing either, but I don't know if new kind for every new template update is a good solution, templates can update based on certain features and updating a nip every time that happens isn't ideal.

Forms should be described using tags. This can help avoid some json-in-json, and I think will make this spec easier for developers to adopt just by reading the NIP.

It'll be very hard to add certain things in tags? like multiple choice options? or even prerequisites on questions? or logic based flows. JSONs are just much more configurable.

Rather than baking password protection into the spec, I would just re-use NIP 59 for both private forms and private responses (which allows for hiding metadata, not just the response content). You could send the required private key out of band as described, or in any other way, allowing privileged access for whatever use case

seems too complicated for a small usecase. just encrypting certain fields with a shared password is a simpler option IMO.

Client-specific stuff shouldn't be in a NIP. NIPs are here for interoperability, which is at odds with client-specific details. That stuff can go in NIP 78 instead if needed, or a client's own database.

agreed, although i think I've wrongly used client specific in the nip, when it should actually be "schema-specific" . Interoperablity doesn't break if clients are able to use schemas interoperab-ly which is why i have tried to collate schemas on the nip. Will update this.

JSONs are just much more configurable.

Tags are JSON arrays, which can be used to model associative data structures. It's really no less powerful, and more idiomatic.

just encrypting certain fields with a shared password is a simpler option IMO

It's not though, that's exactly what sharing a private key does, except you have tooling already available in clients to do encryption with secp256k1.

Tags are JSON arrays, which can be used to model associative data structures. It's really no less powerful, and more idiomatic.

Hmm, you have a point, I'll evaluate on it and iterate if i see no reason for a push-back here.

It's not though, that's exactly what sharing a private key does, except you have tooling already available in clients to do encryption with secp256k1.

passwords make for a better UI, than sharing an entire key, I agree that it makes it less secure, but i think in this particular usecase (hiding the form template) it makes sense, also passwords would give flexibility to obfuscate only certain fields in a form.

EDIT: after going through #1189 I realize it makes much more sense to share forms via p tags itself. Incorporating that into this nip

I would even go further and flatten out the settings tag rather than nesting json there, but that's a nitpick.

We can flatten some keys from there like "description", but an optional settings pram still needs to exist.

All the encryption stuff seems very ad-hoc to me, with the downside that private forms will always leak metadata. Why not wrap forms and send them using something more like NIP 17 or #875?

We could generalize kind:24 to work for any event (not only for kind:35834) and include the possibility of containing two keys: one to edit the event (signing/encrypting key) and another to decrypt the event (viewing key).

Otherwise having to create a 35834 to define the group + a wrapped kind:24 for each viewing and editing member + merge all operations of kind:27 so editors know who the other editors are for each replaceable/form seems like an overkill. For rotating keys, it will be important for clients to sync with multiple kind 24s and 27s with their respective versions of the replaceable. The design of this PR and #1228 is not as private (I am not sure if we need wrapping levels of privacy for this) but it does solve all of these needs inside a single event (no version <-> permission syncing needs).

We could generalize kind:24 to work for any event (not only for kind:35834) and include the possibility of containing two keys: one to edit the event (signing/encrypting key) and another to decrypt the event (viewing key).

That's sort of what I was thinking. Some wrapper that handles the key management in a way that's orthogonal to the thing being wrapped seems ideal.

That's sort of what I was thinking. Some wrapper that handles the key management in a way that's orthogonal to the thing being wrapped seems ideal.

Hum.. we might also not need wrapping of kind 24 if participants are public, like in this and the Spreadsheet specs.

Cool! Are we moving to key then?

Cool! Are we moving to key then?

yes :P

Working version here: https://deploy-preview-151--hilarious-cupcake-5ce684.netlify.app/#/c

This could be an interesting alternative to LinkedIn in Nostr.

@staab @vitorpamplona moved the key-sharing to gift wraps, the previous method didn't make sense in case of polls.

What's the status here? Should we get rid of the poll part since that has been merged?

@vitorpamplona sorry for the late response, somehow i missed the notification altogether, I have simplified the NIP and removed the voting part