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.
Should paid relays accept zap receipts, if the pubkey that signed the contained zap request is on the allowlist to post? I think it would make sense.
I'm asking, because my Lightning account just received a zap with not a single relay in the list that it could post a receipt to:
["relays", "wss://nostr.wine/", "wss://theforest.nostr1.com/", "wss://filter.nostr.wine/?broadcast=true", "wss://purplepag.es/"]
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.
Catus amat piscem, sed non vult tingere plantam.
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.
That's already the case, chat control laws or not.
So I don't see why it's a problem to have some prominent companies running centralized services battle this one out publicly with the Eurocrats.
Maybe at least it draws some attention to EU surveillance and control issues in general, and especially in regards to the Digital EUR and European E-ID wallet that they're planning to launch.
I'm sure it'll be easier than today at least.
If they care enough, sure.
Although the more likely scenario I imagine is that Meta and Signal will just officially pull out of the EU, and then the Eurocrats can embarrass themselves publicly if they want to actually enforce app and network bans for encrypted messaging apps. I have my popcorn ready for that.
There is no way to control user devices and the software they run for any of our open protocols, so there's simply no way for server providers to scan E2EE content transmitted via their services.
Let them cripple WhatsApp and Signal. Why do you care so much?
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.
Because you can't upload a podcast's actual audio files directly to Nostr relays, so it's much easier for everyone (creators, clients, servers) to host the RSS feed with the domain hosting the content in the first place. There's no reason why you couldn't *also* have a NIP for additionally publishing and consuming feed updates on Nostr relays. But the protocol is working very well as it is, and is used by hundreds of millions of people without dramatic censorship happening. Which, yes, is one of the important reasons for defending it.
That said, RSS is extensible, so you could easily add new attribute types to feed items to e.g. point client apps to social interactions on Nostr.
RSS is extensible. You could easily add an npub and other new metadata to the feed. No need to use Websockets to fetch podcast episodes, but a client that supports nostr can then also add the social aspect to it.
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.
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.
No, it does not "publish your content to nostr in a native way". It simply uploads to a separate HTTP server and inserts a normal HTTP link in your nostr event. Unless I missed something, in which case I'd love to learn what!
What exactly in NIP-96 makes that possible? I don't see anything. It's the same old uploading to a normal HTTP server and requesting it from there, unless I missed something.