> I barely have any idea how one is _supposed to_ build on Nostr events.
What questions would you ask to help reduce the uncertainty you mentioned?
Discussion
- "Say I want to build a new software product on Nostr that has a business use-case for its own event type, how should I go about choosing between existing Kinds or claiming a new Kind?"
- "If I'm going to 'claim a new Kind', how should I choose the number(s)?"
- "Once I've got a full design worked out and implemented in a relay and a client, how (and when?!) should I draft a new NIP? Should I do this at all?"
- "Once I'm proposing a new NIP, how should I structure the document? what should be included, how do I submit it?"
- "Once the NIP is submitted, what is the expected process from there? who should I expect or request to review it? How do I know if the NIP is going through the normal process or if has been missed or otherwise ignored (basically, when and how do I pester people? what are the norms here?)?"
I think that's all for now :)
1. Read through the NIPs and if your use case sounds somewhat like what they are designed for. look into using them, otherwise invent your own and ask for a lot of feedback from other devs
2. Pick your favorite number. your birthday. the birthday or your cat. anything as long as you are reasonably sure your not going to conflict with other developers. (you can check this by querying popular relays)
3. Draft a new NIP before your finished. IMO the purposes for NIPs is to *invite* other developers to work with you by explaining to them how your data is structured and what its used for
4. Write it as simple and strait forward as you can, don't explain why users use your app / event kind. instead try to explain to other devs how they can use your new event kind
5. IMO there really isn't a "process". the closest thing we have to a process it the requirement that at least two independent clients implement the standard. beyond that its just developers arguing on the internet...
I would say a good way to think about NIPs is "an invitation for integration". your not writing a standard that will be enforced on other developers. your writing an invitation to ask them to work with you. and generally invitations are best kept short and to the point (think of wedding invitation cards)
Then if they accept, you get to share users and both your apps get better
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.
(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.