NIP consolidation and/or phase out?

[Societus]

So, I am not incredibly familiar with this, but have taken enough interest into the nostr project that I want to make this my first public thing to contribute to. I may not know the right lingo to use or whether this has been asked in some other way not totally obvious to me. I also apologize in advance if I am asking questions in breach of etiquette as I have only made small private projects and have not collaborated with anyone to do anything like this. especially with the definition of terms for a protocol, I don't know if making changes to existing implementations are taboo in context to my following question.

In short, I have an idea for a project that can be tied to existing nostr relays and/or clients that does something different enough it might require a new NIP. I saw the earlier discussion on how NIPs are running out (or have run out since I already see a 99), but was wondering, is there a mechanism in place that might combine the function of existing NIPs that are related, for example, NIP-72: You could probably consolidate it with NIP-29 by adding the kind and associated structures to the relay-based groups standard, which would allow the developer of of a client to split the reddit-style discussion format and relay-based group chats based on the kind attachment of events.

Similarly NIPs 71,73,89, and 92 could likely be consolidated into something more succinct that would equate to "define if media attached is video or audio, is uploaded or publicly web-hosted content, and suggests application handler with or without external content ID, as well as search for related references of an external content-ID using NIP-50 to display on action in clients"

Thanks in advance, Once I have worked out a draft for a proposal on my concept I will put that up here to see if it is something even plausible or desired going forward. If it is helpful, the basic summary is two pieces. First a system to allow for users to upload attachments as encrypted blobs to reduce the threat for relays (think harmful content) to store for retrieval without http style hosting long term. Second, a way to use relays to communicate uptime, live status, and known peers with other clients and relays for faster retrieval of events and content from relays not currently associated with a client's app, which might include being able to contribute storage per-client as a sort of distributed filestore and chain of trust for attachments.

[staab]

see #1470 for some recent discussion, there's no hard limit on nips, and consolidation is a bad idea because it will subtly change definitions. Everyone is free to create their own nip and PR it, or put it on wikifreedia, etc. The nips repo is still the most convenient and complete record of NIPs, and a convenient place to talk about new ideas, but isn't exactly canonical.

On your ideas, see blossom and #230

[Societus]

Thanks for the clarification there. I tried looking at wikifreedia and think I will put something up there once I have a solid full concept. As far as discussions go, I think that blossom might be a component of what I want to run (perhaps could even be a new bud extending blossom, and realistically there may not even be a reason to pitch a new NIP, the only reason the thought crossed my mind was that too many intersecting concepts are starting to lean into each other (I could have a Pepe Silvia board the way it is going), and I am still trying to understand how I would be able to make something which existing relay software would be capable of using, or even make something that any relay could use but still be compliant with the general flow of events from nip01.

No longer sure if this is the correct place for the current topic, but do you think it would be more productive to open a discussion with any of the main relay repos or with blossom to try and figure out where to point my research towards expanding on the custodial security and relay/client accessibility for an external content server?

[staab]

Nostr's dev culture has a bias towards "build first, ask questions later". I would write a nip, build a prototype (based on an existing project if that's easier), and see what people say.