Oddbean

https://github.com/nostr-protocol/nips/blob/master/96.md nostr.build does not implement it, nor does anyone i know of i'd be glad to be contradicted but i have a nostr.build subscription and the only way i put data on it that gets attributed to me is through their webapp, not had a single image upload via clients go to them even though all clients use nostr.build, practically, and my client is signing events of course so, maybe i'm misunderstanding this shit but it seems to me like either the clients are incompetent and/or nostr.build doesn't implement nip96 properly

If you are using Damus, Amethyst, Snort, Iris, Coracle or NoStrudel, and have nostr.build selected as your media host, all uploads to that client should synch to your nb account. It is actually a very cool feature! You should have to manually upload stuff to the web client.

Media uploads has always been an after thought in noStrudel unfortunately. I hacked it in quickly shortly before nostrica and haven't given it much love since. It only supports images right now because those upload quickly. I disabled video uploads because there isn't a good "upload" UI to let the user know their video is uploading, and most users refresh the page because it looks frozen. The current nostrudel.ninja version only supports nostr.build, but the next.nostrudel.ninja version has the option to upload to blossom servers. But the UI still needs work 😞

fishcake is not exactly the most assertive OG nostr user i can point a stick at, he literally has muted me because i grill him when he gives me equivocal answers probably it would me more useful to consider the idea that maybe you can do better and build a properly integrated protocol... or maybe you can find someone who can do it it's really not that hard, and supposedly most clients have had nip-96 working for ages, but nip-42 is the real showstopper, and here is another example of how it stops the show i've been banging on about this for about 5 months now, i'll be very happy when someone finally fucking gets it

there is an argument to be made about the separation of data storage and client apps and relays. what makes social networking built on #nostr decentralized is precisely that they are modular. each one provides a limited scope of functionality. if each client app has its own data storage solution, segregated from all others, outside of the protocol, you only own part of your notes in nostr, since migrating to another client could not be straight forward. and we would be back to Twitter. meaning data storage servers and clients need to agree on a common enough API, so that integration with multiple data storage solutions, and migration is even possible, even a self hosted, or self acquired one. that way, when you migrate from relay to relay, client to client, ALL data in your notes and other stuff will follow you. it's still early days in #nostr. right now, all those solutions are created and managed outside of the protocol. which means, to me, that integrating into an app is somewhat questionable, and could lead to bricking an app, if that solution doesn't stick. it's super easy to request a feature, but remember that the challenges to implement such features that we know from other platforms have been solved by segregating your profile to a single network and selling user data to the market. #Nostr allows for a different approach, and that's what we want from our clients and relays. but it doesn't disallow a centralized app/relay/datastore solution from existing, so we either must be patient in requesting these features, or start providing distributed, cooperative, highly available data hosting solutions that have a good enough API to integrate with #nostr apps and relays