This is a really rough draft, but I think something like this might be a good start to allow users to collection reaction gifs and memes and have them synced across clients
https://github.com/hzrd149/nips/blob/image-collections/652.md
CC nostr:npub1hee433872q2gen90cqh2ypwcq9z7y5ugn23etrd2l2rrwpruss8qwmrsv6
I see you've provided a GitHub repository that appears to be a starting point for building a decentralized image collection platform. The code is written in Rust and uses the Nostr (Native Post-Quantum Secure Transport) protocol for decentralized communication.
To help you build upon this foundation, I'll provide some general guidance on how to extend this project to allow users to collect reaction gifs and memes and have them synced across clients.
**Key Components:**
1. **Image Storage**: You'll need a reliable storage solution for images. Consider using a decentralized storage solution like IPFS (InterPlanetary File System) or a cloud-based service like AWS S3.
2. **Gif/Meme Processing**: To handle gif/meme processing, you may want to integrate a library like `imageio` or `pillow` that provides functionality for image manipulation and compression.
3. **Nostr Channel Management**: You'll need to manage the creation and participation in Nostr channels to enable decentralized sharing of images between users. Consider using a library like `nostr-rs` to simplify channel management.
4. **User Interface**: To make it easy for users to interact with your platform, you'll need a user-friendly interface that allows them to upload images, create collections, and sync data across clients.
**Additional Features:**
1. **Image Validation**: Implement image validation mechanisms to ensure uploaded images meet specific requirements (e.g., size limits, aspect ratio).
2. **Collection Organization**: Allow users to organize their collections using tags, categories, or other metadata.
3. **Syncing Mechanisms**: Develop a syncing mechanism that ensures images are updated across clients in real-time or with minimal latency.
**Next Steps:**
1. Review the existing codebase and identify areas for improvement.
2. Research image storage solutions like IPFS or AWS S3 to determine the best approach for your platform.
3. Consider using a library like `imageio` or `pillow` to simplify gif/meme processing.
4. Develop a user-friendly interface that allows users to interact with your platform.
Please let me know if you'd like more specific guidance on any of these points, and I'll do my best to assist you!
I like how it gets a portion of the context. A tiny tiny portion lol
whatever you do please make sure it is properly interoperable with the Fediverse ( activity pub )
all the content is still on the Fediverse and probably will be ... forever to be honest
NOSTR should aim to be a resilient extension to the Fediverse where you can't be banned and your instance can't be taken down
most people will never think that far and will use Fedi because it is easier. that is fine. it also provides them with an upgrade path to NOSTR, like for example nostr:npub1alykt5h5q5nkuf8rjy8047rah5nzcx9rwje8s9s7n57zdnpyercsxkqzxg started on the Fedi and when his instance went down transitioned to NOSTR.
in other words NOSTR should only be different under the hood - but on the surface, for the user it should look and feel just like Fedi.
and when people talk across the bridge the emojis and so on should look the same on both sides.
nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c nostr:npub1q3sle0kvfsehgsuexttt3ugjd8xdklxfwwkh559wxckmzddywnws6cd26p
Why not just reusing the Custom Emoji NIP for this? I don't see an issue and we already have clients that implement both sides of it.
I don't want gif packs showing up in my reaction emoji picker. gifs are generally bigger images with text or memes. and custom reactions are smaller images for "liking" a note
Also NIP-30 does not have support for thumbnails which is going to be very important for larger gifs. IMO a new kind with "imeta" tags is going to be much easier to work with
Can we provide an event example in the NIP? Those always help me
I’m not sure how to structure the event “imeta” tags with “thumb” previews
Originally I was expecting it to be a directly clone of NIP30 for emojis, but would just be for images
tags:[[“image”, “shortcode”, “
%E2%80%9D%5D%5B%E2%80%9Cthumb%E2%80%9D, “
%E2%80%9D%5D%5D
Ill update the draft I made and open a PR to the nips repo... or maybe I won't, not sure if I want to go through that debate...
Let’s just build it and NIP after it catches it on
Otherwise, GIFs are gonna be emojis
Added some examples to the doc https://github.com/hzrd149/nips/blob/image-collections/169.md
Ideally the events would just be a new kind of NIP-51 lists / sets with NIP-92 "imeta" tags. that should give plenty of flexibility to add thumbnails, alt, and summaries to images so the are easier to search for
I also changed kinds to 10169 and 30169 since the original was conflicting with some stuff
I’ll start working on an implementation and will hit you up if I run into any issues/conflicts
Also:
I have an implementation working currently
I just published a test event (hex_id = "79c96ab3dc70a8bb9e713072ed32e26498e67c565db4cce8e821032db58326f0")
You can try it here (requires nostr web extension):
https://specified-agnella-nublar-88c7462e.koyeb.app/collection
I know it matches nip92, but I prefer the method of nip94 for parsing events client-side
By that I mean:
["url", "website.com"] instead of ["url website.com"]
But you're the one with an actual client so I'm interested in your thoughts when you have the time
Looks like its working nostr:naddr1qqyhgetnwssxw6txwvpzqfngzhsvjggdlgeycm96x4emzjlwf8dyyzdfg4hefp89zpkdgz99qvzqqqr4myqs6amnwvaz7tmwdaejumr0dsht0vfu
For NIP-94 the separate tags are best because its only describing a single file / image but for the collections we need a way to have multiple
If it helps I recently added a few helper methods to applesauce for parsing imeta tags https://github.com/hzrd149/applesauce/blob/master/packages/core/src/helpers/file-metadata.ts
Yeah, I figured that was the reason
Next steps for me are to add a personal collection tab like Emojito so users can view their collections and then I’ll probably launch it
But it’ll likely be pretty useless as first until clients implement it
Noob-question: why exactly are lists better for collections than labels?
1) Is it because then it's easier to zap / share / fetch / etc... a specific collection?
2) How does that way up against the complexity and redundancy it introduces, as compared to labeling things?
Noob-question to your noob-question:
What are labels?
Is that another nip?
We were just doing the same thing as emoji packs but for bigger images
Did you remove it? I was going to start working on an implementation.
