Forms on nostr

[abhay-raizada]

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

[staab]

I appreciate the use of jsonschema, but I think this is too abstract to work well on nostr. Versions should be handled using new kinds, rather than references to schemas (this feels very xmlns ish). A few other comments:

• 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.
• 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.
• 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.

[abhay-raizada]

@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.

[staab]

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.

[abhay-raizada]

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

[staab]

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

[abhay-raizada]

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.

[vitorpamplona]

Interesting choice of putting the two keys in every tag. It does reveal to the public who can edit and who can view. But maybe that's not a problem. Is the goal related to performance? To not decrypt all the other tags as in #1228 at the expense of a bigger event?

[abhay-raizada]

yes in part, it also made semantical sense while writing the client code.

[vitorpamplona]

It does make simpler. We need to reflect on @mikedilger's concern on #1228 about not reusing the p tag for any of this.

[abhay-raizada]

I've thought about it as well, doesn't seem good to overload the p-tag. I thought of an agreed upon p<kindno> tags to solve this, but not using p-tags also risks users not being notified, since how many kinds do clients look for to notify the user?

EDIT: nvm, saw your comment on the PR, duplication works, tad wasteful.

[abhay-raizada]

@vitorpamplona @mikedilger NIP-72 also already overloads the p-tag https://github.com/coracle-social/nips/blob/groups/72.md?plain=1#L27

[staab]

NIP 72 is not a great spec, it should have used moderator or something rather than p tags

[vitorpamplona]

It's from the times everyone was moving to markers and away from positional tags. Now everyone is moving away from markers and into custom tags, like the q thing. :)

[staab]

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?

[vitorpamplona]

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).

[staab]

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.

[vitorpamplona]

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.

[vitorpamplona]

Cool! Are we moving to key then?

[abhay-raizada]

Cool! Are we moving to key then?

yes :P

[ghost]

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

This could be an interesting alternative to LinkedIn in Nostr.

[abhay-raizada]

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

[staab]

I think this is a big improvement. My one nitpick would be that keys should be in different tags, like I have in nip 87, rather than a single tag with many positional arguments, but like I said that's a nitpick.

I'm not sure I fully understand the polls section. I appreciate the trade-offs you outline, enforcing a single vote per poll (or form) seems pretty difficult, maybe it could be left out of the first draft, unless you're actively using it in formstr.