Well, if 99% of the clients do not support Markdown then no one will be incentivized to write Markdown. It would be like some crazy person writing Markdown on Twitter.
Do you agree with me that bloating the protocol by requiring Markdown is an undesirable outcome?
What do these do?
This would be like giving 4x blocksize increase along with SegWit: they will still hard fork and call you names.
In this case there are no shitcoiners, just Damus and Snort supporting Markdown and encouraging bad behavior. Astral and Hamstr have already removed theirs.
And I believe Damus and Snort they did it unwillingly. So we just have to ask them to remove support for the annoying Markdown parts and the problem is solved. Damus has a PR already. I tried to look at the Snort to submit a patch but couldn't find a place in their Markdown library to disable the annoying links.
I think this (mine) was a bad argument, but I have a better one now: why hasn't this language stuff ever been a problem on Twitter?
I like the idea of using relays to segregate types of content. When I talk to Bitcoin people I write in English, I expected everybody to talk in English in that universe. To other groups of people and interest I use other languages.
Today we talked about search note15djknj3kh6szcj82pp6sm98vk3pw40fg8ajsx8mrpfg3zadyeqhqfmsl2n, what about language filtering (that can be a search params, too)? Nostr now is english centric, but with the progressive expansion a language filter will help newcomers to discover new content and raise the signal-noise ratio.
I found this PR about the matter https://github.com/nostr-protocol/nips/pull/182 by #[0] and I think the tag is the right approach, because can be used on other kind types, if needed.
Ideas?
When you go to the internet to find things, do you really search for "italian things" or for the things that interest you?
You don't get my point.
DNS does not have anything to do with URL schemes. The best you can do is link to some page that will then have a link to nostr:...
You two must be from the time when email was cool.
Indeed, I think we can. But clients can still specify kinds if they want, right? Or authors? That would make sense -- although relays are free to ignore filters they don't support.
Do you want to rewrite the NIP with these changes and send a PR? If not I can try myself later.
I think that doesn't put any burden on relays. If they are filtering spam they exclude spam, otherwise they just assume nothing is not spam anyway.
But that would conflict with the stuff further down where you say "clients must include all notes containing all the keywords", for example, these are the parts I found restrictive.
Another small quibble: shouldn't "no_spam" be the default and the option be actually "with_spam"?
I thought "search_query" and one could write multiple terms there. Maybe just "search". What do you think? To do OR I think it is better to send two filters, as in ["REQ", "", {"search": "banana"}, {"search": "apple"}].
No, there is no tag. There is just a string "@npub...", which should not be considered a tag by clients.
This is why you shouldn't do it: #[4]
It is not interesting at all, it is a bug and clients are doing feature-creep bloating the protocol by accomodating for invalid tags. Please don't do this #[1] #[3].
No.