Oddbean new post about | logout
 Also, developers tend to be focused on particular market-segments for an implementation. A change may make lots of sense for one market, but cause outrage among another.

That doesn't mean that one group should hold back innovation for the other, but the protocol should be able to successfully accomodate multiple use cases. 
 that's part of the reason why i made the suggestion to use a new tags field instead of yet another arbitrary, syntax-breaking field (tags open future innovation much more non-invasively) 
 Until now, the main use case was "shitposting", "dev chit-chat", and "techies trying out cool techy stuff", but the content is moving more into focus, I think.

People are posting things on Nostr that they actually put effort into, rather than the effort going primarily into the code.
This is new. 
 it's gonna bring a lot of specific changes too... i hope people think to try not to increase the footprint of the API and instead find ways to expand the flexibility of it instead 
 It needs more hierarchy or structure. It's too flat. There's too much that needs PRs. The repo owners are going to get drowned in PRs.

Imagine millions or even billions of people using this and each type of implementation from Timbuktu is screaming for a NIP? 😅 
That don't scale. 
 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