I agree. Additionally, if the user just wants to display the nevent string instead of a nostr: link, it would become very difficult if every nevent is recognized as a link.
The OS will try to open something? No, the app will parse that much more easily and display the quoted event, or turn it into a link of its choice. There are literally no downsides. It's super easy for the client that is publishing the event to automatically prefix quotes with a `nostr:`.
But if the normal thing is to expect all clients to parse all nevent strings for all events ever that is unnecessary overhead that literally overheats the planet much more than necessary.
What is next? Expecting clients to also go through all of the events' contents multiple times with a huge list of TLDs or an infinitely slow regex to try to find URLs because publisher apps can't be bothered to prefix URLs with `https://`?
Discussion
Use backticks. Not linkifying nostr entities without nostr: prefixes is like not linkifying example.com/my/path/here. Hyperlinks aren't invasive, and they're helpful. Expecting links to always have a protocol in front of them isn't really realistic. People do copy and paste non-prefixed entities, and they often type non-prefixed domain names.
Facts are not arguments. People do what they need to achieve their goals.
The same rationale you're using could be used to defend edits, markdown, bbcode syntax, whatever. As long as enough clients support these things people will start doing them, then you can start claiming it's not realistic to remove support.
Your point about edits is hurtful and insensitive
I see a qualitative difference here, though.
There is no "users will do it with ____ expected result" when it comes to edits. If the devs don't add the ability to edit kind 1 notes to their clients, then users won't edit them, because they can't. Not without overcoming a significant technical barrier, at any rate; namely, building their own client.
Meanwhile, when it comes to users adding or not adding the `nostr:` prefix to Nostr URIs, I believe that good design includes the application producing outputs the user expects when they provide a given input that a non-technical user is likely to provide. The exception would be applications that are only built for technical users.
Is it likely that a non-technical user will paste in a Nostr URI without the prefix? Not just likely. It can be seen in countless examples. Indeed, it is the way users will naturally paste the URI, until they have been instructed otherwise.
Can users learn by trial and error and/or assistance from other users that they should add the prefix if they want it to work consistently? Absolutely! But to the degree that they are required to do so is the degree to which the application's UX is not intuitive. Better if an application updates the URI for the user. Better still if the app's UI notifies them of the update and why, with the option to turn off this "URI autocorrect."
Coracle already fixes the URL on behalf of the user, which is the correct implementation if you ask me. Damus also does this at least in part, and others I forgot. I think it's going to be well.
Jumble too.
Users should be warned though
On Coracle there is clear visual feedback.
It definitely shows that the event referenced will be treated as a Nostr URI rather than a plaintext string. That's probably enough, particularly since the user can preview how the post will be rendered prior to publishing it.
Jumble, by contrast, doesn't give any visual indication in the composition window unless you toggle over to preview how it will be rendered. I definitely prefer the way Coracle handles it.
Ok ok I’ll fix this. It’s not hard to change. Do we have the preferred way of embedding links between notes in the content documented in the nip?