William Casarin
unread,Oct 19, 2023, 10:07:57 PM10/19/23Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to nostr-protocol/nips, nostr-p...@googlegroups.com, d...@damus.io
On Wed, Oct 18, 2023 at 08:02:45PM -0700, arthurfranca wrote:
>A bit disappointing to know you are against it mostly because your app
>won't use it but I respect your honesty.
>
>I will just clarify that my intention isn't to force clients to change
>how they load threads. Adding a tag wouldn't accomplish that. I simply
>want to make lazy loading threads possible and for that I asked for
>cooperation. Adding the `E` tag without removing anything would make
>room for both approaches.
Keep in mind the ecosystem is very large at this point, if you have to
convince 100+ clients and microapps to update their code to support your
use case, then your approach is wrong. I am not against it mainly
because "my app won't use it", I'm trying to help you to understand your
approach won't work at scale, especially once nostr is much larger. If
damus had to do this everytime someone wanted some core protocol thing
changed to support their usecase, then the NIPs would be horribly
complicated.
I almost want to fork the NIPs repo and remove all of the extra stuff
people have been adding to NIPs I've written (custom reactions, zap
splits). I would hate to see nostr go the way of the browser where
people keep adding to existing NIPs until it's too confusing to build
new clients in a weekend.
Every time you extend a NIP its hardforking a subset of the protocol,
increasing implementation spec divergence and confusion.