Ideas for complete control over a curated gallery (behind a setting).

Only show people their own saved images in the public gallery. Other galleries can work as normal, but images they didn’t add to the public gallery are hidden from the user.

The owner can see all images in the public gallery, nothing hidden there. But they can mark (and unmark) images as being part of the actually public facing gallery that everyone can see. Maybe just an extra button to toggle this is shown on the image if the owner is viewing it. (But also an always-visible icon or border colour or some indication as to whether it’s already in the true-public view or not.)

So then you have a situation where the owner has full control over what everyone sees, but anyone can still add their own images to the public gallery. This is all smoke and mirrors, really, just filtering out images not owned, unless you’re the owner of the generator itself. So it may not be too much server-side stuff to do.

Another take, perhaps even simpler (but more annoying to maintain for the owner): Have a property on the prompt/gallery call which contains a list of allowed images. Maybe one for blocked images too (which people have been requesting).

This could potentially be part of a separate call that just reminds the server what the settings are for this generator.

Or a property that can be set on the text_to_image function itself which is then taken into account for any images or galleries generated after that. Which would avoid having to send it every time a call is made. (I’m guessing the user block list etc. is currently sent on every call?)

Or ideally it would just be something stored on the server–which brings us back to the original idea if having an interface for it built in.

Could potentially use a separate generator for it though… like you pass in the id of a generator as a property on the gallery/image call. The server can then look that up without any extra AJAX stuff or message passing required at all, cached server-side until it’s edited, etc. And a similar solution could be used for ban lists also. This method gives a lot of flexibility to the creator, and lower overhead on performance and network traffic. And it’s even extensible with more “server-side data” options into the future. (Though I have no idea if this method would be better or worse from a dev standpoint.)