Hmm... I wasn't planning on doing the media server part, as I have nostr.build and sovbit.host accounts.

This is more about the metadata and organising the media into different albums and people commenting on them. Adding the social layer to the media, without every media item or pic just getting dropped into the kind 1 feed.

Also thinking that I could do searches of the metadata, or let people search over nostr.land, once you get that up.

Reply to this note

Please Login to reply.

Discussion

Immich is a private media hosting app, so I guess the use case you are targeting is (semi)public galleries.

Maybe just photo events + galleries as lists

Then yes, Nostr makes sense. But not for everything 😂

Personally I want to keep the private photos and albums, but have a way to share them publicly (or semi privately) if I decide to do so, and I cannot think of a better tool than nostr for that.

Sort of like relay.tools, but for media. 🤔

If you used an event wrapper (kind 20), then the visibility would be controlled by the event's location. If you put it on a public relay, everyone would see it on the app. If you put in on a private relay, it would be semi-private (the media is public, but the event is private). Semi-private is obscure and off-Nostr, but not completely hidden.

When you want content to be private you use encryption.

Well, yeah, but you can encrypt the content separately. Don't need Nostr for that.

This is more about selecting what gets displayed in Nostr apps and how/where.

Encrypt the Nostr event to the people that should see it. Better solution than relays

Like DMs? 😬

No one said blast it all over the place

auth gated could work also, ultimately whoever is trusted can leak anyway. the URL won't be guessable if it's made with a hash.

yes, except without encryption, the relay is one more party that could leak the URL

What if we forked immich and put a little specialized relay in it?

You could also optionally make the events expire. Add an expiration tag for 60 days, or 1 year, or whatever.

Then they'd still be in your media server, as image files, but your app albums wouldn't contain old stuff.

Yes, yes. I wanted you to look at the picture, is the thing. There's lots of stuff on there, not just a media server. Like, he uses machine learning.

This one:

https://immich.app/assets/images/app-architecture-795c91a0b17db21b192945b4650d24c8.webp

It’s just a bigger scale version of the mobile camera roll with more features. For personal use only.

It's not. It includes so many more features. Even the search alone is a wonderful experience. I can search using vague natural language and find the picture I want in seconds (and I have over 1 terabyte of photos)

“with more features” :)

Yeah, but the "more features" is the cool part.

The use case is for personal hosting. I guess what is really needed is

- some way to bridge personal archives and Nostr archives (extension to self-hosted media libraries)

- a spec to organize media that is not kind20

Yeah, I mean, with the proper interface, you could host your images anywhere. Could put them on Pinterest, GitHub, a CMS, homepage, etc. Just get them someplace reachable with a URL, create a wrapper (Kind 20) and add it to your pins or album or etc.

Bookmark images you've seen and add a comment.

And something like nostr.build ties into that, as you can upload your own stuff and publish the wrapper from there.

They have albums. If they used an album event, then you could have albums that are displayed on this app.

Then other people don't need to use nostr.build or sovbit.host or self-host, or whatever, to see your albums. This app would pull in albums from all over. You could then wrap other people's media and add it to your own pins. Could add an e tag showing the original source of the media.

I was thinking about this, fooling around with https://github.com/Silberengel/copyparty

Seemed like it was slightly-off, as a concept, but I liked the disambiguation-layer idea.

Is there even a need for a complete app? I'm also an immich user, personally I just use tailscale to give access to the server to my family, but I would also like a Nostr integration, with encryption for shared pictures, but I feel like there should be a way to do this by just building a plugin on top of immich?

Yeah, that's what I'm thinking. That's the sort of middleware Nostr is good at. We have Blossom, right?

Seems like a natural sort of synergy. Media server disambiguation layer.

That's what I'm thinking, yeah

I think this is the right track.

IMO there's no need to try to jam images into Nostr. Like you said, there's Blossom, and there are also any number of other preexisting image hosting services.

Nostr events are great at wrapping stuff in metadata. That's all kind 20 is: metadata wrapping a ref to an image. If you want to organize that into albums, you could use the drive events we've been talking about.

An integration with Immich or any other media host would probably be a small utility that can do the following:

- If desired, copy a hosted image from a private location to a public one.

- Obtain a shareable link to a hosted image.

- Wrap the image in a kind 20 event.

- Organize kind 20 image wrappers with kind 30045 drive events.

- Optionally encrypt all of these events.

- Send these events directly to another Nostr user, or broadcast them on a relay.

Ah, I forgot about drives. Of course!

I'm thinking about nostr:npub1m3xdppkd0njmrqe2ma8a6ys39zvgp5k8u22mev8xsnqp4nh80srqhqa5sf's vision for Alexandria as making connections. You can wrap anything in a Nostr event, which means that you can connect anything across Nostr.

The stuff itself doesn't even have to live "on Nostr"; we can just use the great tools that already exist and add a layer on top of them.

Yes, I just want to make different kinds of media "Nostr-ized" so that I can manage them with Nostr. I don't want to store them on Nostr.

Send them via public message, maybe? You could then send them to a group of people, or only one person.

That would work for direct sharing. Or else post it publicly like a regular Nostr note.

Okay, sounds cool. 😊

I can actually add public messages to the Lumina profile. Then you can go there and see the events people shared with you, either as individual wrapped media or as albums.

Like "pics from our dinner party, last night" or something.

Sounds like a fun idea! Sort of like AirDrop or Pinterest or something like that.

It's cool, as people can then click on the individual wrapped media events and comment on them with kind 1111, and none of that ends up in the kind 1 feed.

The Kind 1 Gremlins keep harrassing me to put everything into Kind 1. They get on my last nerve, fr.

So completely lacking in imagination.

Sometimes I am like, wow, everyone else here is so smart and I'm so dumb.

And then I have days like today and it's like, wow, almost everyone else is dumb as a door knob.

It's probably that everyone is a different kind of smart. Sometimes the braincells bounce around in sync, and sometimes they run into each other.

you know my opinon about kinds as being some kind of weird incomprehensible tag. i personally would:

- deprecate the kind field

- expand tags to require all tags be indexed with up to 16 character long strings

then the kind thing would be irrelevant. it can all be kind 1 and good luck to the primal circus keeping up

That would work well for sharing photos from your PurpleKonnektiv meetups

EXACTLY!!

Nobody else understands me. 😭

🧠⚡🧠

And the point here is that you don't need to self-host this. One person can host it and everyone else can use it with their own media hosted wherever.

Any media that can be reached by URL could be integrated, even if it isn't your own. That's the idea behind Pinterest, for example. You pin other people's stuff and your own stuff and comment on their stuff and share their stuff and etc.

But applications and features like immich offers are designed with the intention and scale of 1-4 users in mind, hence self-hosted. These same features at scale are not really economically viable imo. This goes for many things in the category of everything apps.

For example, running something like Plex in the cloud is unaffordable for more than 1-2 users with a library of like 100 movies depending on your provider. Youd be talking renting $10000 of hardware or more to host a plex machine for maybe a dozen users with a library of maybe 1tb of images.

When were talking external users the criteria changes. Hosting media now becomes an economic battle of

- How can I compress this shit as much a possible to save space on my server and keep costs and maintiance down

- How can I deliver this content with as little bandwith as possible to keep network costs down

- How can I keep the content cached and available as best as possible.

- How can I police content at the scale of 1-10000 users so I don't get in trouble

- How can I effectively load balance traffic without breaking the bank etc.

- How do I continually police bots hogging traffic and CU

Once you're talking more than just yourself, the architecture of your stack changes dramatically.

I have no idea what either of you are even talking about. I think you don't get the concept, at all.

they are eating menus. the storage is elsewhere. the indexes are small and easily hosted and replicated.

> they are eating menus

XD I like that phrase

Well, I had the dream of meshing my cmnext cms project with nvault, such that sharing media on nostr was as simple as hovering an image over any web client and it would get uploaded and a url inserted into your cursor, all hosted on your own machines.

cmnext is different in that the webUI is designed to be self hosted and for a small number of users, but the media itself relies on a virtual file system backed by ftp S3 or a file path. Which means I have the HA infra to host the media, and a neat and portable frontend to manage it.

I understand your concern of "I just want to upload shit and share it" so help me understand better? You want self hosted or a service? There is no in between, it's either trusted users or the public, no in-between. I think they are two fundamentally different and incompatible architectures.

cmnext is my attempt at bridging that gap for slightly more technical users.

Neither. I'm working on expanding Lumina to show videos and organize events in albums.

I'm not interested in hosting anyone's media. 😂🤷🏻‍♀️

You both have a total one-track mind.

We were just talking about a Immich-Nostr fork, so that it emits kind 20 notes with Blossom URLs and stuff.

Who's we?

You and Semi.

I like to think of it as narrow-tack. Keeps me focused XD

Schmalspurbahn

About the operating cost, I feel like it is a matter of perspective as well.

When someone runs their own Plex server for example, they can easily justify it as one-time costs, they take responsibility for certain things, certain costs are “indirect” like power/bandwidth, and they do not see the value of their own time.

But if you wanted to do something similar for a larger user base, now the users see one big number that includes the hours you spend, “infrequent” hardware failures becoming a weekly occurrence, and you now taking on risks like copyright.

I would be willing to bet that many services are cheaper to rent than self host if you include all the hidden costs and time and other resources spent.

Exactly! Plex eats a few cores just idling with a large content base.

Like I'm not even making a living of my gear, but I have over 80 hard drives that I have to monitor across 10 machines. 50 cooling fans, 30 power supplies, 3-4 switches. That's just the hardware which gives me far less problems than the software, which is usually configuration related lol.

There is a massive step between one machine I put my plex on, and Im hosting media for 1000s of nostr users to pull, with minimal downtime.

Like try taking down a whole machine without losing uptime XD

i think that it needs to be a big fast cache and many small archive repositories. renting a small one that only answers to you and to the caches you make arrangements with doesn't have to be 99% uptime, it can be down for a few minutes and only the very newest events probably won't already be cached.