Oddbean

It's still a normal Web silo then. Just having a different auth mechanism doesn't change that fact. If that server shuts down or censors you (easy via your npub), then the URL is dead, so the link in your event is, too. It has none of the guarantees of real nostr events that are published to relays in the current form of the spec.

One could argue it's even worse than that (as of now), because e.g. on the fediverse, people publish media to 20,000 different servers/domains, while there are probably less than 50 media servers/domains used on Nostr today. And 90% of files probably live on only a handful.

The spec is a few months old. Servers won’t just be actively censored, people will also get bored or tired and take them offline. The hash is the identity, not the domain. I’m ok if you think it sucks or its stupid, I just want people to consider how it’s intended to be used. It’s not a server.

Blossom and in fact nip96 use file hash to address it, which is easily extracted from a dead url and client can lookup the author's list of used servers and ask for that hash from there. It can also query that hash on nostr relays among file metadata events. No apps have that implemented properly yet, because no big server died yet, but it will be implemented, and it will be much more resilient than yt etc

OK, I understand what you're saying. However, inventing an unspec'd, poor man's version of a content-addressed filesystem by just saying "look there are hashes" is not exactly a satisfying solution to the problem. First of all, and the biggest problem with this as of now: how would the files actually get anywhere else when lost? In almost all cases, they won't be stored with hash filenames on people's various devices that they used to post the media to begin with, even if they could theoretically find all missing source files (most people won't). But there are other issues, like e.g. nostr.build using file extensions in the URLs, but not every service doing that. It also changes filename extensions by its own choosing. Then there are cases like longer and high-res videos, where you don't want most clients to download a single 4K source file for example. You'd need a video-specific server and specs for this to solve it properly. I'm not saying these (and other) problems cannot be solved. However, my initial reply was about content creators currently not being able to "publish content natively on nostr" when it comes to media files. And just looking at the current situation, that is just true either way, hash filenames or not. So there's no point in shaming people for linking media files from any HTTP URLs, regardless of the nature of the underlying service.

The solutions would likely be different for different types of content. Let's take video as an example, because YouTube is such a pervasive platform. Bittorrent works well for video transport, but by itself doesn't solve adaptive streaming during consumption or compression and format conversions on upload. Peertube currently solves those problems, and can be used until there is nostr-native server software (already integrates webtorrent even). For bitcoiners, there is e.g. the https://bitcointv.com instance. Instead of rewriting all kinds of solutions, I think it would also be feasible to simply add optional Nostr integration to all kinds of software, like e.g. Peertube, so that instance admins who care about that could just flip a switch and allow all their users to publish to Nostr in addition to RSS and ActivityPub for example.

It doesn't, same as there is no solution to that on Nostr when it comes to (at least close to) YouTube-quality video hosting. But it is a real alternative that is better than only publishing to YouTube right now, which is what the original post and reply were about.

> If that server shuts down or censors you (easy via your npub), then the URL is dead, so the link in your event is, too. It has none of the guarantees of real nostr events that are published to relays in the current form of the spec. I explained how nip96 and blossom are our poor-man's solution to the problem you stated in this branch. You dismissed it, and proposed we integrate with something that doesn't even try to be a solution. Not sure where you're heading here.

I didn't dismiss it, I explained why it's insufficient to currently replace e.g. YouTube. * Peertube tries to be a solution for replacing YouTube with a decentralized system. It is working well, but isn't 100% on the decentralized end of the centralized/decentralized spectrum yet. Its video player embeds can be used on any platform or protocol. * NIP-96 tries to be a solution for replacing sites like Imgur, and both it and Blossom are preparing for being a solution (or you could say they're already half a solution) to the problem that e.g. IPFS is tackling. These are different problems to solve, and if you want someone to "post their content natively to Nostr" then you need a proper implementation of a client+server that implements a real YouTube alternative based on e.g. Blossom. Maybe I missed where you pointed me to that existing. If not, then I think the next best thing is to recommend publishing to a working YouTube alternative that is open-source, customizable, self-hostable, and not centralized to a single corporation. Please don't get me wrong, I'm not at all against solutions based on what you're suggesting! I just believe it doesn't help actual creators, or their perception of Nostr for that matter, to tell them "no zaps from me", if they post HTTP links to their own content on Nostr, but aren't linking to a single, large mp4 file using the most widely supported (thus much larger filesize) video codec on a pure file hosting server that you approve of.

Your last point might be the most important. People who are creating content just want something that’s easy and it works today. They are rarely concerned about the implementation details that we enjoy debating. They just want to know, “does it work?”