we should have spec’d nostr:nevent… as @nevent… instead. Would have saved a lot of pain and confusion for users and implementors.
If you do @nevent… in damus it will convert it to nostr:nevent… at the protocol level, but maybe it should have just been @nevent because people try to do this now in other clients and it doesn’t work :[
for what its worth, if you manually type nostr: then the nostr object it should work in all clients, but I don’t think people know that.
now there is discussion to make @nevent a convention/design nip, but bleh, more complexity 🥲
Is this a yes to design NIP workshop at nostr:npub1nstrcu63lzpjkz94djajuz2evrgu2psd66cwgc0gz0c0qazezx0q9urg5l
No please
learned today, bit @ would be more intuitive
nostr:nevent1qqsqq0mr9gaw6cpn3qrk5fyfvkpczxr2qcz5aqkh8lrnkn47dg62vnqmrzcht
From a UX perspective @ is useful only if you fire a search and let the user type some characters to autocomplete, and this is not so feasible on a generic event (maybe you can cache and filter already visited contents that have a title).
So for the UI should be sufficient to parse the plain nevent/nprofile/naddr without any prefix, possibly requiring it to be between whitespace chars. As soon the user paste the string, replace it with a sensible preview to confirm that it's correct.
At source level `nostr:` is robust and coherent with the scheme of the Nostr protocol.
TIL 🤔
