Nostr Web Client

nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhkcmmrdd3x77pwve5kzar2v9nzucm0d5hszxnhwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mf0qydhwumn8ghj7un9d3shjtnhv4ehgetjde38gcewvdhk6tc4rdlnm nostr:nprofile1qqsqvcu68pkfcyq5y9mz9n9u7sys33835rpnuglc6mtg7j4lv40c7ugpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3qamnwvaz7tmwdaehgu3wwa5kuegprpmhxue69uhkummnw3ezuum9vfshxarf0qhxgetk34tgct any idea about this? 🙏I think its good to go forward with this quickly, due of the possible network effect

if you edit an event the d_tag remains the same, if the d_tag is the link, the link is "immutable" you change the description, which in this case is the content.

https://github.com/nostr-protocol/nips/pull/1849

The d-tag will be the unique identifier

But what about when an URL change, redirects slow down, might be getting outdated and not working anymore at all and so. Bookmark tools such as pinboard and raindrop can handle this well related to its history, interactions and so.

you have to make another pin

Yes, so you will loose history. Won't there be a nip solution to keep the benefits and history?

in the current form, the one we are using now

published_at tag as in the long form

the history with a simple tag r, or "r", "","timestamp"

That’s up to clients to figure that out, just like other bookmark tools do.

I mean how do we find this out with Yumyume if there is no unique identifier for this

The d tag is the unique identifier and cannot be updated. If a client will integrate an 'update bookmark' feature, that will mean a new event will be created with a new identifier. Then it's up to a client to do some matching for whatever reason.

Maybe two kind is the best solution

simple link 39700 (without changing the spec) like https://github.com/symfony/symfony/

category link 39701 like https://github.com/symfony/symfony/blob/7.2/src/Symfony/Component/HttpFoundation/Request.php#L98