You should only do a NIP if your thing is meant to be a standard. If you're thinking about it as "an app" or "a software product" then it's likely not NIP material.
Discussion
(You should still reserve a kind number for your app in the NIPs repo.)
Thanks. So the progression is: build a product on nostr events -> first see if anyone gives a shit about it -> if they do, and if _lots of people_ give a shit about it, it starts to appear in more clients -> after some critical mass is reached and more people want to interop with the general shape of your product, make it a NIP.
Roughly correct?
No. It's the opposite, kinda.
You first must come up with a protocol that is generic enough and fits with the rest of the ecosystem as a small building block, and that will be the standardized part that becomes the NIP. "Products" must be built on top of that building block together with other building blocks that already existed.
I see. Yea I think that makes sense...
Sounds like I should re-think this NIP in order to find existing Kinds that might be able to be leveraged to replace the list of Kinds this NIP proposes (and then propose a NIP that _only_ suggests the creation of the new Kinds required for the use case described):
Not really, you shouldn't try to force new stuff into old buckets.
Well, honestly, I really don't know what is the true and good way to do things, but the reason why I don't like that NIP is that it's proposing a top-down list kinds that only fits one specific app and one specific usage flow. Maybe that is ok in this specific case, maybe not, but it smells like you're trying to take a model conceived for a proprietary platform and translating it into event kinds, which doesn't benefit anyone.
There is nothing wrong with doing these things with just an HTTP API. The only reason why you should be doing it on Nostr would be if multiple clients could join and leave in every step of the process and deal with these events in slightly different ways. Otherwise this is probably better as a standardized HTTP API that many different providers could implement, for example.
Reading through your NIP I miss a narrative description of the flow you have in mind. It feels like at least 2 or 3 of these kind definitions are unnecessary. And it looks like you're thinking everybody will have all events from everybody at all times, which can't be true in Nostr.
You aren't considering what happens if an escrow agent vanishes, or to what relay each of these events should be published and in which relay each person should be reading from. The tasks are pretty undefined, you just give a string field to them, which makes me think if there is any point in standardizing the process at all, since all the work will have to be done manually and nothing can be automated maybe you can just do it with kind:1 notes written by humans -- honestly that would be a good idea, so after having some experience with that you can elaborate better on how to automate the flow and standardize on fields and events.
I will take your suggestions into serious consideration. If you're looking for something more like a narrative, you'd find that here (in the UI repo readme):
https://github.com/vcavallo/catallax-ui/blob/master/README.md
and here (in the Khatru POC implementation):
https://github.com/vcavallo/khatru/tree/escrow/examples/escrow
After reading, I tried to come up with a better NIP design than yours. I failed.
The best I could think was that communication between agents would be private and not necessary through Nostr events, but could be. And the only public trails would be escrows announcing themselves (should be using a replaceable kind instead), task proposals -- published by whoever is proposing them, and then a summary of what happened, published by the escrow.
Mostly because no one is interested in what happens in between.
I much appreciate your attention and attempt to improve my rotten foundations! 😆
I'll reconsider things, adjust my relay and client and re-draft the NIP.
Here's the case for doing as much (and as little!) as possible in nostr. This is terrible UX and nobody will use it:
Almost as bad as "if you want to reply to my nostr note, post the reply on your own twitter feed and tag me in a new note you write with a link to the tweet"
Can you make the case clearer for me? Not sure I understand and eager to learn?
Fair points all. I'll reconsider if this "has to be on nostr"... The main reasons I want this on nostr is:
- Easy fodder for use by nostr-based reputation systems (and for this app to integrate reputation systems itself)
- NIP-60 wallets on day one - so that any ol' naive new user can come in and fully interact with the economics of this system
- Something like durable and decentralized audit trails of events (partially related to reputation above)
- Tighter integration with other nostr ecosystem elements: off the top of my head: bounties might be related to marketplace items or wiki articles. I could imagine some integration with groups and lists wrt "companies" instantiated as private groups, or lists used as preferred agents, etc. These are places where I would invite other nostr devs to propose refinements to the design in order to grease inter-op.