that's why i'm recommending to try to make the changes more open ended, like instead of adding one field to something, instead add a flexible type of field like tags, so that parsing doesn't break so easily on unrecognised field names (tag index zero in each tag) 

 then you don't even really need to specify it in a NIP PR until you have the necessary implementation ready, meanwhile other clients don't choke on the new tag types... nonbreaking changes > breaking changes 

 this is why i have been massively refactoring the go-nostr keybase, and i have built a fairly decent namespace that gives it a clear hierarchic structure

hopefully when i'm finished with my main task i can sit down and write up a detailed API specification based on the changes i made

it's one of the things about Go that is so beautiful - the way they strongly emphasise the use of concise, meaningful names for everything... of course many go devs have not actually read much of the recommendations and so they write stuff that has awful naming and structuring schemes... either ultra long names, or ridiculously long flat namespaces that need to be decomposed into a tree

it would be great to be able to engage someone to document the work but i don't really have the funds to do it, but you seem like you have motivations, at some point there may be some resources for it