nip05 badges are probably a mistake. One of the most common questions I get is “how do I get verified” and “please verify me”. Very rarely will nip05 badges mean anything close to verification. Maybe for rare cases like mine where my domain is the same as my username, but most of the time it just means “some random domain points to my pubkey”.

Thinking I should remove the badge altogether.

After sleeping on it I’ve kinda changed my mind. I’m now favoring #[2]​‘s approach. It gives accessibility options and if the file is changed or goes missing (404) then the relays can be queried for another URL for the same file. That’s kinda major. That to me is backwards compatibility and worth the hassle of the change.

Does anyone use that in real life for images or is it just for script/css files?

I don’t agree with this at all. It’s way better to just put file metadata on relays and have file data hosted elsewhere. Not only for performance/scalability reasons, but also to minimize legal liability for relay operators.

THE CASE FOR #NOSTR (& #ONLYZAPS)

Nobody asked, but here’s my 2 sats on the evolution of online interactions:

There once was a time when the “like” (👍) was the be-all and end-all in terms of measuring content effectiveness.

In the early days of social media, "likes" played a significant role in determining a post's popularity and reach. This was particularly true on platforms like Facebook, Twitter, and Instagram, where users could easily show their approval of a post by clicking the "like" button.

Likes were seen as ~thee~ measure of social validation. They also played a role in determining which content was promoted on a user's newsfeed or discover page, as posts with more likes were given priority 📈

However, in recent years, many social media platforms have started to de-emphasize likes as a measure of success. Some have even experimented with hiding like counts altogether in an effort to reduce the pressure on users to seek validation through likes and to promote more authentic engagement.

The goalposts of metrics are changing.

Vanity out. Value in.

Traditional web2 platforms like Instagram and TikTok began treating content that had a high save to like ratio more favorably in terms of the algorithm 📱

And you know what’s better than a save (which is essentially a glorified bookmark)?

A #zap

This is the future of social media.

Even those on trad web2 social are catching on.

We’re no longer just interacting for the sake of interacting.

The possibility for more intentional responses encourages more intentional creation. And more intentional creation contributes to a value exchange that fosters a self-sustaining ecosystem ♻️

Here’s the desired hierarchy specific to #Nostr:

#Zap - This is worth its weight in sats

#Repost - I need others to see it

#Comment - I need to share my opinion about it

#Like - This resonates

Do you see how little the 🤙 compares to the other interactions in terms of existence?

Now, not every piece of content we make is necessarily created for the sake of attracting a lot of engagement or for making a lot of money. And to an extent, likes may always matter to one degree or another because they help indicate how much said content resonates with one's audience 👥

But it’s interesting to see the role value plays and what value means when both creators and consumers can engage on social media in ways that have not been possible previously.

I’m excited to continue to explore this relationship on Nostr and I’m grateful for everyone who’s here now on the journey.

What kind of value are you hoping to bring to and receive from Nostr?

#socialmedia #content #plebchain #monetization #tiktok #twitter #instagram #facebook #creators #consumers #bitcoin

GM nostr!

what are we fighting over today?

I've helped 3 people in real life set up a nostr account a wallet of satoshi and blue wallet. And they only set it up to shut me up because they don't use any of it. 🤣🤣🤣 I try

Would be interesting to see the retention metrics of OnlyZap vs. Non-OnlyZap users

I feel like this could work fine on Damus with a little tinkering. When Damus initially received and renders an event that mentions a file attachment it can show it as a note mention, and once it pulls in the note and sees that it’s an image file it can upgrade the display of the note from inline note mention to an inline image. If the transition can be done smoothly without screwing up your scroll position it would be nice.

It’s definitely more complicated than regular inline image URLs, because now to render you need to have both the text note and the file attachment note, but it’s not impossible.

Damus can of course do it but it’s making nostr worse by forcing this update on everyone and making it harder to show images. Damus will never implement creating image uploads this way for this reason.

The point is that NIP-94 wasn't meant to be for embedded images in kind:1 notes. If someone really wants to reference a kind:1063 they should be able to, paste a nevent code and that's fine, but they shouldn't expect other social clients to be able to understand these events, so it makes no sense to make that the default way of loading images.

The best way to ensure that the protocol is kept simple is to not assume other clients will implement whatever NIP you think it's cool -- you can implement anything you want, but you should still make it so the experience works for others that don't.

Any Nostr event can be quoted in a Kind 1 with nostr:nevent... That means any new event kind can be quoted.

Damus doesn't need to load the preview if they thing the preview is slow. They can simple do an @note1 text and get users to click on it.

Having two different ways to display images is too confusing.

A much better and backwards compatible way could be done in either two ways:

1. nevent with internal kind and image url tlv. This would at least allow other clients to use the url if they don’t want to implement the attachment nip.

2. Keep the url and reference the metadata event id in a tag with a url index.

3. Probably many other ways that wouldn’t break anything.

If you really want this to be a file attachment instead of image then you could just keep the original upload method and let users know that clients might not be able to see your image if you use a file attachment.

All up to you, but damus will not be implementing this nip for image uploads, as stated before I think it’s simpler to encode this information into a completely optional small string so that its available on the post itself and so that clients can use the information to do all the hash checking stuff, but when they are ready, not forcing it on them.

Cheers,

Links to any other kinds are fine, the only thing that is of concern here is breaking images.

That's not changing, it is clarifying.

I know is not the right time to bring this up but...

I think I need to go off-spec on NIP-51