naddr1qvzqqqr4gupzqpxfzhdwlm3cx9l6wdzyft8w8y9gy607tqgtyfq7tekaxs7lhmxfqq35ummnw3ez65m9vd6hy6t50yk5zcmrda6kuapdfpskx6mn94h8zcm2d4jsfjd2gy
Discussion
What client is putting naddr in the text with no nostr URI? nostr:nprofile1qydhwumn8ghj7emvv4shxmmwv96x7u3wv3jhvtmjv4kxz7gqyqt48rwz5cnkn5y5g0cccd7tudv04ddmlxq3wd2z4f79lut3a4mugslsfzj
its just me copy and pasting alex
here you go
nostr: naddr1qvzqqqr4gupzqpxfzhdwlm3cx9l6wdzyft8w8y9gy607tqgtyfq7tekaxs7lhmxfqq35ummnw3ez65m9vd6hy6t50yk5zcmrda6kuapdfpskx6mn94h8zcm2d4jsfjd2gy
nostr:nprofile1qyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7qg6waehxw309akx7cmtvfhhstnxd9shg6npvchxxmmd9uq3kamnwvaz7tmjv4kxz7fwwajhxar9wfhxyarr9e3k7mf0qyvhwumn8ghj7mrfva58gmnfdenhyetvv9ujucm0d5hszynhwden5te0ve5kzar2v9nzucm0d5hsqgpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n57lddx7 this is why clients should just render nip19 stuff regardless of whether it's prefixed
that is what primal does
Also coracle
I specifically don't do a lot of things like that in Ditto because of the protocol bloat argument. Also what if I want to write a post with bech32 displayed in plaintext?
Kind 1 content format sucks. The only thing that would make it better is to expand/unify the imeta concept into "facets".
Please nostr:npub16c0nh3dnadzqpm76uctf5hqhe2lny344zsmpm6feee9p5rdxaa9q586nvr, you know as well as I do that this is a slippery slope.
I think primal team is working on this exact issue, by converting all primal.net/nevent to nostr native links (e.g. nostr:nevent ) etc
cc nostr:npub1zga04e73s7ard4kaektaha9vckdwll3y8auztyhl3uj764ua7vrqc7ppvc
The issue above is actually a bug in the latest iOS build of Primal. We’ll release a patch soon.
I agree with not rendering nip19 without the prefix.
i further say that clients must add the nostr: prefix or deth
Before publishing, Jumble now automatically adds the `nostr:` prefix if it's missing.
Testing
nevent1qvzqqqqqqypzpqf9hyg76r55m03spzstujx0uhxsczc9jg70l7gh4elg0k5yqzyrqy2hwumn8ghj7erfw36x7tnsw43z7un9d3shjqghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qpqucsf94hwpa0t0qqqgj9cwqycavzhhejttxxyjg6jwpwqvzcjhs2qmmf8yx
Hum, looks like didn't work.
yeah i had to add it
Remember to check the preview 🌝
What about render correctly posts with no nostr: prefix?
so, you want the client to have a whole logic for scanning for every nip-19 prefix instead of the prescribed proper protocol nostr:
the editor, ok, not the presentation, that is gonna slow it down
idk if you have used coracle on mobile but it's heinously slow at rendering
it's become very slow on web too, and the logical reason is that there is so much extra work being done for whatever reasons... Postell's Law apparently, which i think is silly
i don't think scanning for backticks to render plaintext has any great impact though, but scanning for every one of the nip-19 entities is at least like 6 scans for each post before it can be rendered to html
What clients could do is recognize these URLs at the time they're typed/pasted and prepend the "nostr:" prefix instead of forcing everybody to recognize them at render time.
Even the big platforms do it with URLs when you type just the domain name: they prepend the "https://" prefix (Twitter would famously add an "http://" prefix until recently and that would break some websites that didn't have an autoredirect).
It's common knowledge that we should try to put most of the work on the write flow, because it happens only once, while the read flow happens dozens, thousands, millions of times. That's what most scalable software end up doing.
Bluesky also does this, as you type your rich-text left-wing opinion the client builds a parser-optimized metadata thing that gets published together with your post and it gets published as plaintext + this thing attached so it gets easy on the render side to display.
Here on Nostr we like to think we're smart but here we have some of our best client developers wanting to do more and more fancy parsing on the render flow, slowing everything down, and then publicly shaming other clients into doing the same.
We should probably copy the Bluesky approach if we manage to keep the plaintext plain and the rich metadata optional. It's not very different from the imeta approach that nostr:npub1q3sle0kvfsehgsuexttt3ugjd8xdklxfwwkh559wxckmzddywnws6cd26p pointed out.
I think that's fine, but if we want the barrier to entry to be low, parsing on user input is just as much of a chore as parsing for display
Parsing on input keeps the network sane and helps everybody. You do it or not do it, it's your client's decision, self-contained and virtuous.
Parsing on on display is Postel's law and trying to fix people's mess while incentivizing them to do more and more mess until you can't fix it all. If you do it you create work for everybody else and protocol bloat.
💯💯💯
I like it how nostr:npub1n0stur7q092gyverzc2wfc00e8egkrdnnqq3alhv7p072u89m5es5mk6h0 does it for example
nostr:naddr1qvzqqqr4gupzqpxfzhdwlm3cx9l6wdzyft8w8y9gy607tqgtyfq7tekaxs7lhmxfqq35ummnw3ez65m9vd6hy6t50yk5zcmrda6kuapdfpskx6mn94h8zcm2d4jsfjd2gy