Iris will continue to use kind 1 instead of kind 20 for image post creation:

* Works on most clients, doesn't break existing clients' reaction / reply based feeds

* Kind 1 events reach larger audience than 20

* No added complexity, no different handling for kind 20. Keep nostr client implementation simple.

* Clients that don't support images can just show the text content, or filter out notes that have images

* Clients that only want images can filter out posts that don't have images

* Optionally, they can use ['l', 'picture-first'] or similar tag for relay indexing of image posts

nostr:nevent1qgsy2ga7trfetvd3j65m3jptqw9k39wtq2mg85xz2w542p5dhg06e5qpz3mhxue69uhhvct4d36zu6tjd9ejuar09uq3wamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmny9uqzqpdj0dmmuqxgt4u6xe86au3zyh6v2lkq9xzpuajdrqusv4n0fm3yqskns0

Reply to this note

Please Login to reply.

Discussion

Yes, very few realize that backwards compatibility is more important than something that is needlessly different and adds nothing to improve the user experience

primal does not support kind 20, backtrack 😀

Primal doesn't support hardly anything. 😂

Neither does Damus 😂

Yup. 😂

I can always tell who is using those clients, as they pop up in my replies, every few weeks or months, to say, "Wow, I haven't seen a note from you in FOREVER! Where have you been?"

🥴

mostly a reflection of how i use the app. If i wanted these things i would probably add them. The rest comes down to if someone wants it enough to add it to damus, but that rarely happens.

not to mention we’re blocked from updating our app until we remove zaps again which i don’t want to do again… so i can’t even push new features if i wanted to. 😪

WTF Apple is doing? Aren’t they supposed to not block 3rd party payments?

Very few realize that it's incredibly irritating that I can't post to my gallery from my nostr.build media server account THAT I PAY FOR, and instead have to use lumina.rocks to upload my images to other media servers, to get them into my gallery, or I have to use my book app to publish kind 20, which is ridiculous.

You could at least give us the option to post kind 1 or kind 20, geez. Total rugpull.

Why didn’t you say so. I didn’t know that you depended on that to keep you gallery running

I told you that, before, but you were like, we're doing kind 1, now. And basta.

You did, but you never mentioned that it caused you pain and blocked you from doing what you needed to do. I was able to add it in a simple form long ago, but figured I’d wait until I have a cleaner interface to implement it in.

Maybe someone will PR Olas & co. to use kind 1 instead 😅 Would prevent the same problem from happening over and over again.

Probably fork it, and redo it from scratch would have been better

I don't use Olas. Lumina has kind 1 and kind 20. Those are two different use cases, with two different displays.

Good decision. Made the same on Plebs app. We just need to revise NIP-01 to include Parameterized Replaceable Events, and leave it up to the relays/clients to decide which version to show (or all but annotated with a “edited” link to see history), much like NIP-09 (kind 5).

how would a kind20 client query images? also images in kind1 can be memes/gifs which would ruin kind20 clients ?

They could query based on the ["l", "picture-first"] label tag.

If they choose to show kind 1:s that don't have the "l" tag they'd need to client side filter by event / image format.

Oh, stop. Nostr developers are just incredibly lazy.

Takes a grand total of 4 seconds to add kind 20 support. "Mr. AI, please add kind 20 support to the social feed. Thank you."

Even #Alexandria supports them and it's a friggin book app and doesn't even have a feed.

It’s unnecessary complexity

Images is not my domain, but it would make sense to ask photographers or other people in that realm what the type of features they can think off that leverage kind20 tags data which could be implemented in kind20 clients to suit their needs.

I disagree with "keep nostr client implementation simple" to begin with, in the sense that you could just choose to opt for a simple (half-assed, feature poor) implementation of kind, rather than encouraging a shitty practice that undermines feature rich specific clients.

I really am too lazy huh...i have a half done video on this very subject, gues i will have to finish it asap to drive the point home