-
Notifications
You must be signed in to change notification settings - Fork 577
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Instagram feeds #1551
base: master
Are you sure you want to change the base?
Instagram feeds #1551
Conversation
Looks good at first glance. |
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? |
I'm a fan. Text only kind 1 events are clearly different. |
Pinstr uses
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:
The |
Co-authored-by: Pablo Fernandez <[email protected]>
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