nostr-protocol
Instagram feeds
Adds a simple kind for picture-first clients building Instagram-like feeds, where the picture should be attenuated and the descriptions are less important and might not even be displayed in the main UI.
No, I don't think Kind 1s must be reused for these clients.
And no, NIP-94 became too generic for this.
Read here
I am starting to wonder if NIP-71's "vertical videos" is too broad. They should be short vertical videos. No one wants to see a movie in these feeds, not even vertical movies.
NIPs like these are essential to move the ecosystem forward! Relying on a few broad NIPs just doesn't cover all advanced use cases. For example, with Pinstr, I had to create custom events that other clients don't recognize, which disrupts compatibility and limits potential growth for those kind of clients.
@sepehr-safari which kinds do you use? Would you switch to the new kind here or should we just use your kind?
@sepehr-safari which kinds do you use?
Pinstr uses kind: 33889.
Would you switch to the new kind here or should we just use your kind?
I think none of the above! Pinstr needs more options than this NIP and it's not a replacement of Instagram.
ohh I see, so a pinstr only shows boards and each board is basically a list of links that can be sorted in any way the user sees fit. Cool. Yeah, they are different.
Wouldn't it be simpler to have JSON data where there is the description and the imeta? After all, they are the content of the post. I think putting them in tags will complicate the parsing of this in the relay and in the clients.
I think it's great and would be a great addition to galleries, replacing their content with these.
Tagging with a geo location might be good. NIP-52 uses:
// Location
["location", "<location>"],
["g", "<geohash>"],
The annotate-user in the list of imeta-fields looked a bit strange to me, but I guess we need it at that level.
@pablof7z i think you forgot the imeta tag: https://njump.me/nevent1qqsdnxzaw49t4h8h60zjmn6x6emvl2chayte4zj2m85cwkdr3jln4fcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsyg86np9a0kajstc8u9h846rmy6320wdepdeydfz8w8cv7kh9sqv02gpsgqqqqq2qtd56d4
If you put the imeta tags in as root tags we won't know which tag relates to which image.
You are killing me, @pablof7z
iMetas have multiple strings, not all in one string. https://njump.me/nevent1qqs0xl90yge92lajjhdlxr8mepjse8kdjm8s98c7lnly8nt4kwtv5xgpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsyg86np9a0kajstc8u9h846rmy6320wdepdeydfz8w8cv7kh9sqv02gpsgqqqqq2qe8m32k
oh jesus, thank god, I thought it was all in one string and I was dying inside
Shipped on Amethyst v0.93+
Since we got Amethyst and Olas, can we merge this?
That's the law 'round these parts
That is not the law at all. It's not like two cowboys can come up with some stupid idea, implement it in two clients no one knows about, then merge it into the repo, that would be a nonsense policy destined to make the repository suck and be useless forever and just confuse everybody.
But in this case I believe it was good to merge.