Re: [nostr-protocol/nips] Add E tag to NIP-10 (PR #830)

12 views
Skip to first unread message

William Casarin

unread,
Oct 19, 2023, 10:07:57 PM10/19/23
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.
Reply all
Reply to author
Forward
0 new messages