Nostr Web Client

I was thinking about this at one point myself and thought that maybe it would make sense to be able to embed multiple URLs for the same media file so if one host goes down it would still be accessible via another one. Maybe also with some sort of hint as to how the multiple URLs are dealt with, e.g. primary/secondary, round robin etc. The client could also potentially then load from the lowest latency host to improve image loading performance.

I think the NIPs that push media to relays could work for images if we had special purpose relays specifically for hosting images, but I agree they aren’t the best solution in general.

The Fishcake (nostr.build) 2y ago

Relay media is not a solution, it’s just not efficient and doesn’t scale. Embedded multiple URLs also doesn’t solve the problem, if both URLs are dead. I think a good abstraction layer here would be a solution but I am not sure if I didn’t miss something fundamental that will break things in adverse ways🐶🐾🫡

Reply to this note

Please Login to reply.

Discussion

⚡️🌱🌙 2y ago

What’s wrong with URL’s?

The Fishcake (nostr.build) 2y ago

You don’t own it! 🐶🐾🫡

⚡️🌱🌙 2y ago

Because you don’t want to?

The Fishcake (nostr.build) 2y ago

Domain name is a rental property that you are not guaranteed to hold, that’s all. 🐶🐾🫡

⚡️🌱🌙 2y ago

Ah, I see.

URL works with IP, but same issue?

You can use @note as address space, maybe create a NIP that uses @file instead of @note and suddenly you can store media in multiple relays and retrieve them easily.

The Fishcake (nostr.build) 2y ago

No, no meadow on relays, that’s not smart. Doable, but inefficient and doesn’t scale, and also legal issues may arise. NIP-95 tried to propose just that, and most of the relay operators refused to accept (rightfully so). I am talking about resolving specialized nostr URL to an actual hosted file URL. Then, we need a mechanism to resolve it, something like gossip or torrent magnet link, or something else. 🐶🐾🫡

⚡️🌱🌙 2y ago

Existing relays use @note I was proposing @file.

I wasn’t meaning the same relays serve both.

@file would probably work like CDN.

The Fishcake (nostr.build) 2y ago

Ok, now I understand what you mean, yeas probably a good idea and additional abstraction 🐶🐾🫡

phil 2y ago

You would ideally embed enough URLs so hopefully they don’t all die but yeah it isn’t a perfect solution. I agree that an abstraction layer would be good but how exactly does the discovery work and how is the media distributed across multiple hosting services?

The Fishcake (nostr.build) 2y ago

Many ways to go about it: host config in profile, gossip type of discovery, preconfigured mirrors/archives, special configurable proxy that does the discovery, etc. 🐶🐾🫡

phil 2y ago

I actually thought about a caching proxy type layer a while back that would sit in front of the media hosts as an alternative to using commercial CDNs. I was thinking about it more from the point of view of improving performance but the same sort of concept could work. Proxy would serve the content locally if it has it, otherwise fetch from the media hosts using some sort of discovery mechanism. Clients could have a list of proxies in the same way as they have a list of relays so if one goes down it uses another one.

The Fishcake (nostr.build) 2y ago

There can be many ways, and translation layers/methods I guess 🐶🐾🤷‍♂️