nostr:npub1l77twp5l02jadkcjn6eeulv2j7y5vmf9tf3hhtq7h7rp0vzhgpzqz0swft nostr:npub18c556t7n8xa3df2q82rwxejfglw5przds7sqvefylzjh8tjne28qld0we7 nostr:npub1qe3e5wrvnsgpggtkytxteaqfprz0rgxr8c3l34kk3a9t7e2l3acslezefe what do you think? https://github.com/nostr-protocol/nips/pull/1847
Discussion
To be honest I am still too much in a NIP & Kind detail learning phase to give a good opinion on this. We find out, learn by trail & error. Currently it's working basically, but as you suggested it's not a good technical approach we should optimize it. In the future with nostr:nprofile1qy8hwumn8ghj7srwdaejumr0dshszxrhwden5te0ve5kcar9wghxummnw3ezuamfdejj7qgswaehxw309asjumn0wvhxcmmv9uqkvamnwvaz7tmxd9k8getj9ehx7um5wgh8w6twv5hkuur4vgcnqcth0f4ku6n8x4er2mrpdfh8ydfnxsensmnyvduk57tvvachxunwwf68zdt8wfengwf4wc6ryutrxeshwum2xs6hjueh8a38ymmpv33kzum58468yat9qythwumn8ghj7ct5d3shxtnwdaehgu3wd3skuep0qqsdc8dhmzvvclfgf3hwcevla6az3ufu3zq286xe8067s73a56ny4vc770yv8 (and other social bookmarking tools) I would like to see:
- Signing date of the first bookmark per profile (who started bookmarking an URL)
- Signing date of the updated bookmark per profile
- Optimally (speed) filter the social bookmarks on hashtags, bookmark / URL, profiles
- Search within descriptions
- Public & Private bookmarks
- Enhance with tools to optimize social bookmarking such as repeatedly 404 detection removal of bookmark (DVM?), LLM to filter on bookmarks during browsing (browser plugin or so). Idea I had for years , and also saw something similar suggested by nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgnwaehxw309ac82unsd3jhqct89ejhxtcpr9mhxue69uhkwun0w4c8xtnxd9shg6npvchxxmmd9uq3uamnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46z7qgkwaehxw309aex2mrp0yhx6mmnw3ezuur4vghsqgrkcud2uwjfruweamz8ewshug5umfq38g9mkmn2u9mk6ajru2w2lg26q8zu
I believe the scheme above allows for all these features to be built, and I can't think of anything else better, but there may as well be, who knows.
The only problem with finding out is that when you find out it's often too late to switch because of network effect (this is the fate of Nostr itself and probably all of its subprotocols). Any small network effect is already too much. This is not to say you shouldn't try and error, I'm just stating a conundrum.
What's the problem of 39700?
This was also my thought / question
Same question for me as well
Sebastix approved the change??
if there is no unique identifier in NIP-B0 then how can we track it properly.
If we track only by kind:pubkey:d-tag, what happens when a kind receives comments and zaps, but the d tag is later updated? How can we track it again along with its related comments and zap kinds?
Additionally, if a bookmark is deleted after receiving some zaps and comments, and later the user creates a new bookmark with the same URL, will the previously deleted comments and zaps be mistakenly linked to the new bookmark, even though they are not actually related?
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.
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.
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
Or maybe a smart relay which can figure that out and provide that (extra) metadata around those events
URLs break, that's what the internet does. There is no way around it. Even when URLs don't change the content inside them can change drastically.
One good solution is to keep a WARC copy of the referenced page stored somewhere, there is a DVM spec for that and I was working on such DVM but couldn't finish yet.
The generic solution is: make a new bookmark, keep the old one as a piece of history or delete it entirely.
If you're going to say a centralized system that is just a database can change the way it stores internal data and therefore it's better than fine, but Nostr is not such a thing and cannot ever have all these "features". Nostr is just a system that allows everybody to shout stuff so others can read, tradeoffs exist.
Primal kinda hid this note from me—didn’t even get a notification. I only saw it thanks to my very own Nostribe! 😅 Not saying Nostribe’s better or anything, lol. Anyway, sorry for the late reply! I’ll catch up on the discussion on Github.