Maybe we are already there? Maybe your life is just a simulation? How do you know you have a past? Maybe your memories are an implant and you live the same day over and over again. How do you know people are dying around you? Those people in wars or your close relatives? You haven't died yet. Maybe it's all a sophisticated program to entertain you or a spectator.

Nip-27 is strictly more flexible than nip-08.

nip-08 entangles tags with content. While not terrible as both are available at the same time, it was lacking as it did not allow to reference a profile without also including a such tag. As you mentioned, this is particularly important when "gossipping" about third parties in DMs but users might decide to not notify somebody simply because for them it would only be spam. Fiatjaf or Jack for example - you know which Jack but to be unambiguous, I could "mention" him - can't consume all their notifications as they get notified all the time. By cutting back on the notifications, their experience would improve.

* #[] **always** notifies, conveys profile/event and where to find it

* nostr:... conveys profile/event and where to find it (in the "profile" variant, not the "npub"). Notification is optional.

In nip-27 the notification p-tag would not need to duplicate the relay information but would duplicate the pub key or event ID part, which is some extra bytes but that is acceptable in nostr where we care about being simple to work with. Maybe in a far future where all the world uses nostr, we will optimize this again but it should be easy to compress into a binary format to keep the optimization to the transport and persistence layer and away from the client devs.

So a profile referenced in a p-tag would be exclusively for notifications and in the content for display. Slightly more bytes than keeping nip-08 alive but simpler and complete for sure.

Should we mark nip-08 as obsoleted by nip-27 or are there any strong objections? Clients will probably forever want to render these first text notes correctly but maybe if clients stopped authoring them, it could be a lower priority task in every new client.

You blame JS but I was working mainly with Java for a long time and things like

```

Map eventCounter = new ConcurrentHashMap()

```

would be totally normal in an Android app and had little room for simplification. Gladly Kotlin (or more modern Java) is less verbose but with this simple assignment already over 100 chars long, I'm happy about any indentation I can skip.

As a friend of long and self-explanatory variable names I strongly prefer 2-spaces to the point I was suggesting IDEs to render leading spaces as colored lines without indentation. 😘

Uhm ... yeah but I actually meant "buyers of analog art".

Are there any art buyers on here?

Few clients support this so far. Nostrgram does. And you can find scripts to achieve this with noscl. It's really trivial to do except for relays nowadays throttling requests, so ... I hope to see it offered by more clients soon.

https://www.nostrapps.com/ is nice but very limited aka curated.

https://www.nostr.net/ is hard to navigate but extensive and open source.

https://nostr.info/resources/ is content from the second, more navigable and open source. I started this one but paused as I think it should be backed by nostr events, not on GitHub. PRs are welcome though.

For anti-caps, mentioning money's utility for anything at all is "wrong" and "you reduce all to its monetary value".

I think anti-caps are not necessarily what client devs should cater to but with onlyZaps you repel not only the anti-caps but also the shitcoiners that favor their respective flavor of shitcoinery at least if it doesn't support lightning. And of course you repel all those who think that both Bitcoin and crypto are a huge ponzi.

I get it, nostr was born out of Bitcoin so to say but it was always a big priority to not push Bitcoin into nostr users' faces on a protocol level.

That's an ok-approach for technical users but the fact that these details are little known to even client devs should show that some further abstraction would be good.

I understand the argument and you certainly will keep anti-capitalists away with #onlyZaps.

In nostr, likes and zaps are gigantic +500B messages to add 4B of data (utf8 or amount) to a message. That's why many were against likes even before zaps were a thing. And then there is those who find a like too cheap to even show. Vanity stinks.

Zaps at least carry value, so it's less cheap to zap than to like but if you have no money to spare, zap one sat. It's as good as free. But anti-caps won't do that ever.

I like Rocket-Musk. I hate Twitter-Musk. ;)

So there appears to be much confusion about how mentions should work and I think it comes from

* some clients implementing their own thing

* two nips around how to encode mentions in events

Events should either notify the mentioned or not. That's where the two standards differ.

If no notification is desired, the event.content should just contain the bech32 encoded reference.

If notification is desired, a tag should contain what is referenced and the event.content should only reference the respective tag.

When authoring TextNotes, the editor should not expect the user to know the difference. Opening a list of people when pressing the "@" symbol is convenient but does not mean that the symbol has to be part of the Note's serialization.

I would suggest to add some bell icon 🔔🔕 next to every reference which would allow the user to switch the notification on and off.

Advanced clients should allow notifications without references in the content.

#[0] #[1] #[2] #[3]

Ironically I do not know now if the references to four client devs above will trigger notifications as irisTo renders them as @npub

Deployed.

My habla.nostr.info currently has a version deployed where I had not finished an experiment of mine. It's currently not allowing to publish regular posts neither.

I did publish from localhost with one of the versions that did work. Will deploy a working version on nostr.info in case others run into the same issue.

Well, still a bug in the client if it doesn't tell me how to move forward. It should tell me "failed to connect to relay xy" and work otherwise. Ideally it would keep track of which relay the event failed to publish to but no client is good in that aspect.

Habla.news won't let me publish. Neither on FF nor on Chromium. nostr-tools update appears to have introduced the issue. Using nos2x-fox.

https://github.com/verbiricha/habla/issues/21

Snort won't allow me to whine about Habla neither.

https://github.com/v0l/snort/issues/527

Somehow Nostrgram is ... oh, ok, it appears to have loaded now, 5 minutes later. Anyway, ... posting from iris.to ...

Nice. Keeps you entertained with trivia while scrolling. Links would be nice. Would also be nice if the space elevator went all the way to the end (geo-stationary and beyond) and not only to space.

Gnah, I can't work like that. Spaceship exploded? BitcoinMagazine Twitter account disappeared at the middle of them holding a Spaces? Surely all more important stuff to look into than my work!

Why are brains wired to gravitate towards this news stuff? BitcoinMagazine will be a Twitter-glitch-nothing-burger tomorrow and yeah, Spaceship is a bummer but nothing changes if I find and watch the video now or not. Damn, brain! Stick to the plan for once!