But this is not true. Using strings to differentiate between what could have been differentiated by a number doesn't make anything more flexible, it just adds confusion and inefficiency. Take [NIP-58](https://github.com/nostr-protocol/nips/blob/master/58.md) for example. It's the NIP that defines **badge creation, award and acceptance**.

It makes sense for the badge creation to be _parameterized replaceable_ (kind 30009) and differentiated by the `d` tag, as each pubkey can create multiple badges, and it makes sense for the badge award to be a normal, non-replaceable event (kind 8), as badges can be awarded to many people and the awards never change. But it **doesn't** make sense that for each badge receiver to craft a list of badges they have accepted and want to display they have to use a _parameterized replaceable_ event (kind 30008) with a `d` tag set to `"profile_badges"`. Why this magical string?

I believe the idea was that people would be able to craft different badge lists. For example, they would use the `"profile_badges"` value for badges they want to display in their main profile, and some other value, for example, `"hidden_badges"` for badges they have accepted but don't want to display in their main profile, and `"rejected_badges"` for badges that they want to explicitly reject -- or something like that.

The idea makes sense, but does it really? We could have done the same with a kind 10007 meaning _profile badges_, kind 10008 meaning _hidden badges_ and kind 10009 meaning _rejected badges_. That would save disk space and bandwidth, it would make it easier for relays to index these events and, most importantly, it would make implementation simpler. In the world of `d` tags, every programmer that tries to implement creating these badge lists have to go to the NIP and hardcode the kind 30008, then look for the magical string that must be set at the `d` tag and write it, exactly like in the NIP, as a string, and add that as a tag to the event, the same is valid for when a client wants to support reading the tag lists. While in the multi-kind world you only need to hardcode one magical number. It's undeniable that `{"kinds": [10007]}` is a simpler filter than `{"kinds": [30009], "#d": ["profile_badges"]}`. You may say the differences are negligible, but I'm just trying to illustrate a principle.

I have the impression that in the minds of many programmers to be able to write a string gives them the impression that everything is more flexible and magical: "oh, I can write _anything_, while if the stuff is in kinds I would have to first get authorization from the NIP overlords". Maybe the NIP process can be improved, but ultimately this makes little difference. You can definitely write _anything_ in the `d` tag, but you can also write _anything_ in the `kind` field too, the actual requirement that exists, and that exists for both, is that others start using the exact same kind number or `d` string that you're using, and vice-versa, and there is no shortcut for that, you necessarily have to come to an agreement with others -- which is what the NIP process tries to facilitate.

With the Bitcoin Connect feature provided by nostr:npub1getal6ykt05fsz5nqu4uld09nfj3y3qxmv8crys4aeut53unfvlqr80nfm , you can now zap all the mods of a community using zapddit.com #zapddit

And oh yes, dark mode is made the default for new users 🙂

And, one more thing, the UI is a little non-ugly than earlier. A lot more of non-ugly to come in the near future ✨

#plebchain #nostr #communities #zaps #alby #clientlife #grownostr