Oddbean new post about login | logout True for text content, but media content "on" nostr is already not on nostr. Those files are just uploaded to nostr-auth-enabled silos and linked via plain old DNS, same as linking any other resource on the Web.
True but that still publishes your content to nostr in a native way instead of driving traffic away. There is also content indexing from search engines. Publishing content to nostr first (as an alleged Nostrich or Bitcoiner) will give the app or site you're using the search ranking. Publishing elsewhere first to then publish the same thing later on nostr is deemed duplicate content and it will get strikes by the engines. Just another thing to consider as "nostr creator".
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!
I understand what you're saying. It does however not drive nostr's content to centralised sites. With nostr there is no need to send me to your X to give me a link to your twitch to then send me to YT to watch a video only for the description to send me to Medium for your latest blog before the link in the blog is sending me to your Instagram. Point is that there is creators on nostr who're only here to drive content to other platforms, the platforms where they earn their fiat bucks.
nostr-auth-enabled is the unlock which prevents the content from being in a silo. Once enabled it can flourish in the ecosystem using relays, blossom, and zaps. It’s not the same old web.
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.
It’s dns for objects, it sits on top of http, uses npubs for identity, zaps for payments. It’s not replacing the internet, it’s improving it.
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.
No one is shaming anyone. What is the satisfying solution to the problem?
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.
How does Peertube solve the problem of dead instance/links?
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?”
followed!