Oddbean new post about login | logout Just merged https://github.com/nostr-protocol/nips/pull/1185, which introduces NIP 73 for external identities via the `i` tag. A different form of them is already in use in NIP 39, for linking external identities to user profiles. NIP 73 IDs are instead fully-qualified, and include a second parameter which is a suggested URL, which allows clients to easily link out when they don't want to special case every ID type. What's neat about this is that this will allow platforms like Fountain to reference podcast episodes in nostr comments, which can be displayed and linked out to by regular nostr clients, expanding the scope of the nostr-enabled web!
Podcasts, movies, books, music, etc. a lot of Nostr content can be expanded upon and improved by linking to external sources, making Nostr that much more powerful by bringing the existing Internet into the fold. nostr:nevent1qqsdjt4nl5t4y0v8lzxn67z4mu5p5k37mfpxtd482us47zrnz8rf6cgpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygyhcu9ygdn2v56uz3dnx0uh865xmlwz675emfsccsxxguz6mx8rygpsgqqqqqqskhu35k
are there any clients that allow you to add nip-39 ids to your profile? i didn't even know about that nip. pretty cool. reminds me of keybase.
@wavlake can you add an `i` tag on zap receipts and comments on a song? spotify has this. you could just copy their format. spotify:track:54KIAHa71rBTDubyUPwiks is the URI for https://open.spotify.com/track/54KIAHa71rBTDubyUPwiks
We started adding an `i` tag like this just last week, though it only applies to zaps coming from the mobile app. Have chatted a bit with @fountain_app about the format. Here's the mobile code: https://github.com/wavlake/mobile/blob/main/hooks/useZap.ts#L39 There is also the `a` tag that references the track/episode id, that'll likely change though once we update how we're publishing tracks as nostr events.
Looking at it now. You’re using the podcast prefix for songs. Wouldn’t it make more sense to make a new wavlake prefix since songs are not podcasts?
Yeah probably, I think this is so a client is able to locate the corresponding RSS feed for all the content metadata, which is within the podcast namespace. @merryoscar Does that sound right? https://github.com/Podcastindex-org/podcast-namespace I suppose this is a transitional period until everything becomes nostr native in the future? Not sure how the RSS/nostr relationship will wind up looking down the road. Could wind up being redundant/parallel systems? 🤷♂️ Here is a fountain example using the same `i` tag format: nostr:nevent1qqsvuu996n42u4swzgysp5sh6grgeladcvjrc8vm0kdzx4kre0aeraszyrrtam5st3nvh0kwwuupx7jj775dyyl42gx2cce9gzusslyx8qqf5lxcdvl