mister_monster on Nostr: There's a 4th solution: a client can make itself configurable to display any kinds ...

There's a 4th solution: a client can make itself configurable to display any kinds the user wants, warning them that if the client doesn't support the kind it will display the raw message.

Option a is the topic of discussion here and you don't even want to talk about it at all?

I think you're probably right about the ideal solutions. But I'll share a story with you so you can understand the frustration.

I'm currently developing a tool that uses nostr and torrents. I have read all the nips (which are changing very fast) and I came across nip-35. It is a torrent specification. The kind is 2003. I'm sure you're familiar with it.

It only supports v1 hashes. These are sha1 hashes. These are insecure. Of course, there's nothing preventing a user from sticking a sha256 hash in there, that's up to the client. Side point here: why is there a separate spec for a type for this that can and will simply be ignored by clients? Digression aside, this is not a very well thought out spec.

So, there's a part of the specification for "i" tags, that include website specific tags for imdb and myanimelist among others. What kind of silly shenanigans is this? A generic torrent spec for a decentralized protocol has a carve out in it's design for imdb? That's fucking silly.

Is this a generic torrent spec or a piracy specific spec? Is this a general type or designed by someone with a specific client in mind that they are building? It is very badly thought out. Looks to me like more of a "decentralized popcorntime" NIP than a torrent specification. Useful, definitely, but not suitable for general use with torrents.

So as a result of all that (and a few other considerations) I'm publishing magnet links in what I'm building as kind 1 by default. I will also code in the option to select kind 2003 so that users who want to use this kind can.

And a lot of event types and nips are like this, just badly thought out, that have been merged. I know, you don't want to artificially restrict development, you want to let this evolve how the userbase needs it to, you don't want it to be a generic transport protocol and all that. But a lot of this stuff is client specific, or not well thought out. There's going to be a lot of fragmentation, legacy support for deprecated nips, and things like that if this continues it's going to get away from you and the rest of us, just like how it is harder to build a web browser from scratch than to land a spacecraft on the moon. A little foresight would go a long way here.