nostr-protocol / nips

Nostr Implementation Possibilities
2.39k stars 582 forks source link

Instagram feeds #1551

Open vitorpamplona opened 3 weeks ago

vitorpamplona commented 3 weeks ago

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

fiatjaf commented 3 weeks ago

Looks good at first glance.

vitorpamplona commented 3 weeks ago

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.

sepehr-safari commented 3 weeks ago

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.

vitorpamplona commented 3 weeks ago

@sepehr-safari which kinds do you use? Would you switch to the new kind here or should we just use your kind?

derekross commented 3 weeks ago

I'm a fan. Text only kind 1 events are clearly different.

sepehr-safari commented 3 weeks ago

@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.

vitorpamplona commented 3 weeks ago

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.

frbitten commented 3 weeks ago

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.

believethehype commented 3 weeks ago

I think it's great and would be a great addition to galleries, replacing their content with these.

flox1an commented 3 weeks ago

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.

vitorpamplona commented 3 days ago

@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.

pablof7z commented 3 days ago

hmmm, strange, will investigate

pablof7z commented 3 days ago

correct, I had a race condition

vitorpamplona commented 2 days ago

You are killing me, @pablof7z

iMetas have multiple strings, not all in one string. https://njump.me/nevent1qqs0xl90yge92lajjhdlxr8mepjse8kdjm8s98c7lnly8nt4kwtv5xgpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsyg86np9a0kajstc8u9h846rmy6320wdepdeydfz8w8cv7kh9sqv02gpsgqqqqq2qe8m32k

pablof7z commented 2 days ago

oh jesus, thank god, I thought it was all in one string and I was dying inside

vitorpamplona commented 2 days ago

https://github.com/nostr-protocol/nips/blob/master/92.md