This is a test post that includes image metadata (blurhash, dimensions, etc). Please ignore. 
Login to reply
Replies (41)
No fuck you I’m paying so much attention to this post
Cool chicken
🙈
*Writes in invisible ink* What do I need to do to see all that info
Nah
Very ignored
Too pretty to ignore!
Nice... Thats 1k sats for u..
Works fine on Amethyst 😄
🤣
Wow 😯
Where is the ignore button?
I’m having a hard time ignoring this, sorry.
How to ignore it?? It’s completely ignoring #Nostr, probably...
Image metadata for the win! 👍
Why the custom encoding on tags?
Why not just doing [ "iMeta" , "nip94json" ] like we do with other things like private zaps?
In that way we don't need to duplicate tag definitions in 2 places.
Definitely thought of that, just seemed bloaty for no reason. This is not nip94, it would be a different nip specifically for image metadata in kind1 notes.
I may not even implement nip94, I don’t even think it’s *that* good. This is more concise at least for images.
Yes, but it creates more issues. For instance, where do I put the hash if the user doesn't use a filename with a hash?
I think the nip94 tags are more organized than this. And it avoids building yet another encoding scheme inside Nostr.
not sure what you mean, you can include a hash in the tag array or not: “sha256 abcdef….”
Can we add as many tag properties as we want?
I thought many relays handle 4-5 columns max. Especially those that convert these into database columns. It's not going to fit.
So you would be fine if it was nip94 tags encoded in a string or something? You don’t need the whole object. The reason I have the whole object in private zaps because the signature matters, unless you’re using saved images from other people in posts ?
Also Amethyst reuses NIP-94 when people reshare links in another kind 1.
Your proposal duplicates the meta content in every use of the image URL which can become problematic.
I'd prefer a full event inside the tag. Bringing NIP-94 tags to kind one can be messy.
It can be as simple as:
['r', 'url', 'nip94 event']
Otherwise, it will be a little messy to rebuild the object.
['r', 'url1', 'hash', '...']
['r', 'url1', 'descriptor', '...']
['r', 'url2', 'hash', '...']
['r', 'url2', 'descriptor', '...']
Also, I am not sure how well relay indexes will deal with this.
It’s ambiguous today how to handle more values in tags - except for a few NIPs that define second, third and forth value - like pubkey, relay pet name (NIP 03) or hex, relay, marker (NIP-27).
Data architecture wise it should likely be split into a tags and tag values m2m table.
However does [p, PUBKEYA, PUBKEYB] become two instances of tag values both pointing to tag p - or does PUBKEYA have a relationship to PUBKEYB, and it wasn’t a normal p tag.
SQL wise, it’s hard to model correctly.
1. You shouldn’t use single chars for tags because many relays add indices for single char tags which is not necessary
2. This has tons of duplication for what gain?
I will likely go with something like what I already have in damus. I feel it’s space efficient and concise, and most importantly, backwards compatible. If I implement nip94 I will just treat that separately instead of trying to contort it into this spec.
If you know anybody Who likes foot pictures plese share : Hi its like onlyfans for foot fans, but cheaper... So if you send 100 sats, i Will place a photo of my foot on tiles... On first level...
repost my post please
More image metadata tests don’t mind me 
Where?
not bad at all! 😍🤙🏻
Me jelly’ .
Looks nice in the day too :-)
now thats a view
Great photo! 💫
Beautiful
Two words; Coconut baseball
Canada looks different than I imagined it.
PV!