Froze on me after three swipes and sound wasn’t on 😭

If you want to try out reels... 👀 https://beta.lumina.rocks/reel

You can use https://e.nostr.build to get a player and preview

or maybe this gets a preview https://a.nostr.build/vm7a.mp3

I heard a rumor than nostr.build might be getting kind 20 support and it made me so excited, that I extended my subscription for three more years. You had to be there. It was a whole... thing.

Like this?

Worked well. Would be nice if there was a confirmation message, or something, so that there's feedback that it worked. That's been confusing me, for a while now. Would also be nice, if there were some way to view which event ID or nevent it had, so that people can easily find media notes they posted.

Nostr.build now supports posting of kind 20&21 events. If you do not know what they are, your client are likely not supporting it. #kind20 #nostrbuild #newfeature

I’ll get you one today, need to read up that NIP again, and give you that option. I hope you don’t mind a checkbox that would duplicate 1&20

👀👀👀

Yes, very few realize that backwards compatibility is more important than something that is needlessly different and adds nothing to improve the user experience

Iris will continue to use kind 1 instead of kind 20 for image post creation: * Works on most clients, doesn't break existing clients' reaction / reply based feeds * Kind 1 events reach larger audience than 20 * No added complexity, no different handling for kind 20. Keep nostr client implementation simple. * Clients that don't support images can just show the text content, or filter out notes that have images * Clients that only want images can filter out posts that don't have images * Optionally, they can use ['l', 'picture-first'] or similar tag for relay indexing of image posts nostr:nevent1qgsy2ga7trfetvd3j65m3jptqw9k39wtq2mg85xz2w542p5dhg06e5qpz3mhxue69uhhvct4d36zu6tjd9ejuar09uq3wamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmny9uqzqpdj0dmmuqxgt4u6xe86au3zyh6v2lkq9xzpuajdrqusv4n0fm3yqskns0

People lacking the fundamentals can never achieve greatness, only mediocrity

Ignore vibe coders, when they tell you what their software does. They don't actually know what it does. They also have no clue how computers work and networks function. They couldn't design efficient and effective algorithms, if their lives depended on it. They say they tested it. They're good testers. No, I am a good tester. And part of being a good tester is... Knowing precisely what the software is meant to do. Knowing how computers work. Knowing how networks function. Knowing how to design efficient and effective algorithms. The jokes on you: Good testers know what the software does, better than the people who coded it. Also, be honest, the AI writes the tests, too, doesn't it? They've "reviewed" it. Except that it's also code. So, no, they didn't. This is like purchasing food from people who can't tell you what the ingredients are or how it was produced. It's usually going to turn out fine.

You can read all you need at https://blossom.band with all the links to all the BIPs, I’ve done the mental heavy lifting for ya 🤣

I legit can't figure Blossom out. I've read the specs, but "Ich verstehe nur Bahnhof." 🤷🏻‍♀️

Is Blossom the reason why media servers are downloading copies of my pictures and serving up their version, instead of the original? Cuz, I find that sorta creepy.

Redirect can get you only so far, because it redirects from the upload endpoint, making it a single point of failure. Integrity of a media is undesirable by the majority, since it prevents any sort of transcoding or asynchronous optimization, resulting in slower uploading times (if sync optimized) or shitty user experience that is caused by gigantic files with a ton of redundant and unused by the client info. Lastly, the assumption that service MUST deduplicate content to be compliant, is naive at best. People want to own their uploads and not share them with others, services want to provide individuals with their own libraries, making things more challenging. Lastly, deduplication of the content based on hash is highly inefficient at scale, forcing services to come up with a bunch of workarounds, and maintain risk of deleting/overwriting someone else’s files at any moment. Overall, I understand what you are preaching, but at the same time ideologies are never productive in the real world. Mirroring could have been added easily to nip96, if it wasn’t for people hyping toward the next thing. That’s exactly how we are ending up with fragmented clients that cannot keep up with 4 standards for DMs, 4 standards for media hosting, and so on.

Serving media in Blossom can be managed with a redirect, like you do, and this offer a good degree of flexibility to separate the upload endpoint and the actual storage. > Note that the "<sha256-hash>" part is from the original file, not from the transformed file if the uploaded file went through any server transformation. Instead I find this part quite problematic because it does not easily permit to test the file integrity. I need a nip94 event or an imeta tag with the "x" value to check it. Media transformation is a powerful feature but adds a lot of complexity. Finally I don't read in the nip anything about mirroring (not only multiple uploads) of the assets, and fallbacks in the download procedure, aspects that seem important in the decentralized context of Nostr.

NIP96 does not prescribe how I serve the media (endpoint to be specific) and allows me to make a more reliable service with a clear separation of concerns. In blossom I am forced to accept uploads and serve media from the same exact hostname, therefore forcing me to make trade-offs that hurt speed or availability.

I got it, thanks. Btw it seems that Blossom is getting more traction than nip96, isn't? Why do you prefer nip96?

The standard (and recommended) way is nip96, blossom protocol in our case is just an addon and it gives you a link that will redirect to the original media

Oh, image.nostr.build is not Blossom? Now I see that blossom.nostr.build exists.

That’s not how it works, only Blossom, not the standard one.

nostr:npub1nxy4qpqnld6kmpphjykvx2lqwvxmuxluddwjamm4nc29ds3elyzsm5avr7 this image has the wrong hash in the url: It should be e63f8c6dbe7423b2d5cf62a0b5b64b556bac5234ad501ea295742d5cda4717e4

Totality of our (nostr) dataset is under 0.5TiB uncompressed and easy to search 😂

Follow lists are the solution to the problem of finding some particular subset of items (in this case, npubs) within a very large set. A set the size of "all Twitter users" or "all Instagram users", for example. They are a solution to a problem we do not have. Our problem is the opposite: We have lots of disparate data sets and need to find particular items somewhere in them.

I haven’t implemented it, let me take a look and see if I can do it fast and easy. Should be fairly simple, I just need to somehow give user a choice so they can decide 🤔🤔🤔

nostr:npub137c5pd8gmhhe0njtsgwjgunc5xjr2vmzvglkgqs5sjeh972gqqxqjak37w is there a way to share kind 20 from build?

Test of sharing from nostr.build.

gifbuddy.lol ded?

Good morning. Today is our 25th wedding anniversary. We have been blessed with two wonderful children, and I am truly happy. Thank you, my dear wife. I look forward to spending many more years with you.

People are better-looking, now, than when I was a kid, but you can't tell because so many of them got really really fat.

Yeah, that's what I'm talking about. I mentioned Bowie above.

Relays are the new file servers. 🤙🏼