#devstr question
Why should I not change all publishing of Picture/Olas events in Nostur from kind 20 to kind 1 with k-tag 20. And same question with Yak/Voice Messages from 1222 to kind 1 with k-tag 1222
Seems better for network effect and backwards compatibility, what am I missing?
Wouldn't that thread get wonky, when embedded?
I embed kind 20 events in other kinds.
Could give an example?
If you have to add special rules to handle kind 20, you can also add special rules for kind 1 with k-tag 20
Existing clients don’t need to add anything and everything would still work.
Could you give*
If the embedded kind 20 in this example was kind 1 with k-tag 20 all could work the same, all the information is in the event. But with kind 20 its broken for existing clients that haven’t implemented it yet
If its kind 1, then it wouldn't be a gallery item, tho. 🤔
I'm not sure where this “gallery item” is defined but with kind 1 k-tag 20 I would call it a “backwards compatible gallery item”
It's not backwards compatible. It's a totally different data structure and ends up in different feeds.
I select kind 20 and kind 1, specifically.
I'm more interested in kind 20 handling multiple images in one event, so that I can group similar pictures, in the gallery.
Isn’t all the image info in imeta tags? its the same in kind 1 or 20.
Is something missing in these 2 embeds that could give a problem?
Nope âś…
So we can have more cotrol over the feed content. Kind 1 is way too overloaded and it really sucks for people who just want to use nostr for specific types of content
Kind 20 is only useful if it's an actual Photo Album event. In which case it should for sure not be kind 1.
For most pics people already use kind 1s, which is fine.
The extra needs of having descriptions per picture, tagging profiles ON the pictures, edibility,; etc... only come in when you're talking about actual photo albums or portfolios or inspiration collections or ....
:pointright: All of these use cases can be served by one :album: Album event kind, with some tags like `c`for category.
All the big-tech-copycatting is making people come up with a different kind per big tech app they want to copy. Instead of looking at the needs of the content type (and users) itself.
I like kind 20 to select specific items for my Lumina/Amethyst galleries.
Galleries indeed :Check:
For my portfolio needs, I just need Album events that I can put in a list. That's it.
My portfolio can then just be that list.
But then I have to limit the text in the kind 1 that contains the picture.
And how do you exclude album events from the kind 1 feed?
They are a different (editable) kind, so they aren't in there unless you embed them.
Same for the chat feed, I will be rendering :album: Albums differently from just embedded pics:
Your portfolio contains one item.
For Voice/Audio it comes down more to what you think should be part of Nostr short form text stuff.
Imo, any short form text, and thus all of these, can have audio files in them:
- Kind 1
- Kind 1111
- Kind 9
Are there any clients that focus on audio only? Like: display only audio posts and ignore everything else?
Like only get the the audio from kind 1s, kind 1111s, etc... ?
👉 I don't get the use case for this.
Or apps build around the Audio track events (31337 and 31338) ?
Or apps like YakBak ?
👉 I again don't see the use case. Especially if you then promote new kinds like that to be included in text based Twitter clones.
Organizing everything per content type is silly to me anyway, so I don't get the question I think.
The audio app I do need is a long form one that can take in Articles, Pods, YouTube, ... and let me handle one queue for all of them combined. Let's me highlight in text when I open up my phone, let's me comment in text or voice, etc...
I loved reading the thread and digging into this detail of nostr! Here’s what GPT had to say.
👉 the problem: most clients only know how to render kind 1 as plain text + maybe inline images. They won’t automatically say “oh this is a gallery” just because of the k tag. Some might ignore it entirely.
👉The real role of k tags:
They aren’t a substitute for using the “right” kind. They’re a disambiguation tool in threads:
“This kind 1 note is replying to an event of kind 20, not just another kind 1.”
Without them, clients may assume everything you reply to is another plain text note.
So k is about reply context, not defining object type.
We're going to ignore it. You can add all of the optional tags you want. Kind 1 is kind 1 and adding a k=20 tag doesn't change it to a kind 20.
We already pull media from kind 1, so this is superfluous, but it doesn't break anything, so have fun with that. 🤙🏻
Whatever.
Haha I love it! Kind 1 is Kind 1 🫡
