Oddbean new post about login | logout If you don't rug yourself are you even a nostr dev? Starting today and for about a week by blossom server cdn.hzrd149.com is going to be down (rugged) which means all of the images I've posted so far will be broken... unless your using a client that is aware of blossom servers 😀 I just pushed an update to next.nostrudel.ninja so when it detects that an image failed to load and the image has the sha256 hash in the url it will start going down the users blossom server list to find the image It works something like this 1. Image fails to load 2. Does image have a sha256 hash in the url? 3. Get other users blossom server list (using pubkey in kind 1) 4. Replace the image urls host with the next server on the list The end result is that anyone using next.nostrudel.ninja will still be able to see my pictures because they are still hosted on cdn.satellite.earth and media-server.slidestr.net https://cdn.hzrd149.com/72cb99b689b4cfe1a9fb6937f779f3f9c65094bf0e6ac72a8f8261efa96653f5.png I added a few helper methods to "blossom-client-sdk" for any other clients that want to use the users blossom server list to handle broken images https://github.com/hzrd149/blossom-client-sdk#handling-broken-images
@The Fishcake🐶🐾 nostr.build is you, right? would be cool if you created a new path for files where the hash can also retrieve them not just the nice short names
Not possible since account images are not deduplicated and one hash can reference and does reference multiple media files. Beto you ask for a reason, given that the storage is private, users may choose to have a duplicate posted in the note and then deleted from the public eye while a copy remains in the storage. So in short, not a good use case for account specific storage. 🐶🐾🫡
no, the chances of a hash collision from different files is so small as to be practically zero the hash does not reveal anything unless you know where to find it and the short codes you already use are way more likely to have a collision than a full 32 byte, 64 character hexadecimal (or shorter bech32) - now, those hashes, yes, they can collide much more easily, but even still they are at least 48 bits by my estimation which is far far less than a full 32 byte, 256 bit hash
I am not sure if I said it clearly, but what I mean is that identical files do coexist in the same account. User uploads same image more than once.🐶🐾🫡
if you stored them by hash you could deduplicate them
also, if you mean "how do i have multiple filenames refer to one file" it's called a hard link
who is paying for all these servers ? i don't think this is the innovation anybody needed at this point in time. what would be better is to use some kind of AI image recognition to find all similar images and substitute the missing image with the closest looking one. for example there are thousands of images of a Nostrich or Bitcoin and you could replace any one of them with any of the others and it would make no difference. there are also thousands of images of Trump or of fat feminist with purple hair and so on ... our problem is we have TOO MANY REDUNDANT images already, and your solution is to increase redundancy further 10X i'm not hating by the way. you build cool things for free and we are grateful. but my ideas are always best. you know it, i know it and everybody knows it. @fiatjaf
Running servers and hosting a small collection of personal images isn't expensive, people do it all the time with wordpress and other blogging platforms. The purpose of blossom is to use the sha256 hash of those files in the url. that way you can verify the file hasn't been tampered with. and if its no longer available from the original server, a client can ask other servers since the hash is universal Also since sha256 is a universal ID for a file. it allows you to re-upload the exact file if it was take down or your moving servers. most apps that allow image uploads (like discord etc) don't even have a concept of re-uploading an image also why do you tag fiatjaf on every other post?
instead of using a hash to find images you should use a lower resolution version of same image to find the full resolution version. even Bing image search has a feature where it will automatically show you different "image sizes" for the same image, for example the following are different sizes grouped by Bing https://i.pinimg.com/originals/d0/0d/59/d00d5967e65b05124e5d277a7c6fb83e.jpg https://i.pinimg.com/736x/0d/b9/44/0db944ce8f8e469988d35cda0eee9501.jpg a truly smart system wouldn't even save the image but simply find the highest quality version of it on the web and save just the address. i tag @fiatjaf because he appears to capable of understanding my brilliant ideas.
the smart thing to do would be to save a 100 x 100 pixel "avatar" version of an image to act as a checksum plus the addresses of five highest resolution matches of that image found online. then display the highest res version that loads first and matches the avatar visually. almost every image posted on Nostr was originally downloaded from somewhere online where it is already hosted for free. those images which are original can be marked as such by user, but frankly the user should just host those himself. there is no need to save 10 different copies of an image every time somebody posts a picture of Putin riding a bear.
Its not about all about images and media though. There are tons of other files that need to be hosted and re-uploaded in their original form IMO a big shortcoming of most hosting services is they only focus on the media, as if that where the only things the internet was made of Also, brilliant ideas? If I ever claimed to have brilliant ideas I would end up eating my words within a month
if a file is treated as a black box there is only so much we can do. if we can open the file and understand what it contains we can do more. for example we can see that a word document and pdf document may actually be the same document. this is obviously not going to be practical for some exotic file types as a computer can't be expected to recognize them all. but my guess is over 90% of all files uploaded are JPEG and nobody says we can't adopt different approaches to different file types. i bring all this up because recently GAB was in the news for restricting file uploads only to paying members. GAB was banned by credit card processors making it harder for them to make ends meet financially. any anti-establishment social media should expect the same fate of getting cut off from mainstream banking channels and looking for ways to cut costs. these costs may be low now, but assuming NOSTR grows they could grow exponentially - might as well start thinking about reducing them now. text and images are fundamentally different. text takes a lot of energy to create but little to store or transfer, thus decentralized redundant approach is right for text. images are the opposite. one size does not fit all. @fiatjaf
sorry by "avatar" i meant "thumbnail" ... so for any image you save the exact pixel dimensions for example "1200x800" then your hash, then a THUMBNAIL and links to five instances of that image found online. if any image matches the hash you use that, if not then you use one that matches dimensions, if not then just the thumbnail etc ... or something like that ...
In a world of AI image generation I don't want a central service that decides that an image is "close enough" to the original. I want exactly the original image that the author intended. Cryptographically Identified by the hash.
you remind me of people in early days of Mp3 who said the quality wasn't good enough because the compression was lossy. the same folks also said that you need $10,000 cables to get good sound quality. and then blind tests revealed none of them could hear a difference between a $10,000 cable and a steel wire clothes hanger used as a cable. does anybody still buy compact discs or use FLAC files ?
can you remind me where was the blossom server list stored?
https://github.com/hzrd149/blossom/blob/master/Nostr.md Although I'm working on writing up a small document on how clients can use it
yeah, a filename->hash index would be a good start... and it probably can be merely 8 bytes of the hash prefix without much chance of collision, 16 pretty much certain to have no problem
Look, I am not going into details of the implementation, you can look it up on GitHub, but as I said, that does not fit with the use case that NB accounts provide. Yes we have hash and yes I can make a mapper to fetch based on it, and no I will not make it because it violates principles of design and user experience for the account uploads case. 🐶🐾🫡
