NIP-29 Bookmarks

[plantimals]

This is a first pass at adding bookmarked events and pinned events. The specific form of this is largely inspired by balas ( 9ec7a778167afb1d30c4833de9322da0c08ba71a69e1911d5578d3144bb56437 ).

tl;dr:

• introduces kind 8
• bookmarks are e tags
• an event may be pinned by placing the event ID alone in the content field

A functioning prototype can be found implemented on profile view pages of nostr.io.

• example bookmark event in the wild
• example pinned event at the top of a profile page

[fiatjaf]

At first glance I think it makes more sense to separate bookmarks from pinned events. Maybe put the pinned event under the kind-0 metadata event? I don't know.

Aside from that this looks good.

[jb55]

The bookmark list should probably be a replaceable event type? but agreed with @fiatjaf, pins and bookmarks seem like separate concepts to me.

[eskema]

When I thought of it, it made sense at the time, but now I see that it may be cumbersome to load all the user bookmarks to display a single pinned post. how about adding a "pin" field to kind-0 content object? That way you get the pinned event directly from the profile. Bookmarks still need a NIP. * Edit: oops, fiatjaf already said this, not sure how I missed it and wrote the same thing about kind-0... which I took from a jb55 reply from another NIP..

[plantimals]

thanks for the prompt feedback everyone. I'll break out pins into their own NIP and make this purely about bookmarks.

[plantimals]

I've updated the branch to remove references to pins. You can find an updated prototype implementation of bookmarks at: https://nostr.io/p/dd81a8bacbab0b5c3007d1672fb8301383b4e9583d431835985057223eb298a5, with the bookmarked events being those indicated in the included event json in the NIP29.md file.

[vishalxl]

Pinned event is something that can go into the About/Meta kind 0 event. Because kind 0 event already has information about the user, and a pinned event is along same lines, that it tells us about the user.

Kind 0 content field is supposed to be json, with "name", "about", "picture" fields, and there is also "display_name" being used. Adding a "pinned" field with value as any event id is possible. Then when one wants to change the pinned event, or remove it, they send out another kind 0 event with that change only, rest of the fields remaining same.

We may leave up to the user what event they want to pin on their profile. This will allow users to pin other people's events too, if they so wish. BUT, that my be used by bots and fake profiles to mislead people, so ideally the clients should not allow other people's events to be pinned on a user's profile.

[plantimals]

thanks everyone for the suggestions around pinned events. I've modified nostr.io to look for the pinned_event field among the other profile metadata on kind 0 events. an example event can be found here: nostr.io

{"id":"71412d5cdb7e675b9806d23bda3d7c4878ca7f8e72ae3477c7179938e857cb9b","pubkey":"dd81a8bacbab0b5c3007d1672fb8301383b4e9583d431835985057223eb298a5","created_at":1661777381,"kind":0,"tags":[],"content":"{\"name\":\"plantimals\",\"picture\":\"https://plantimals.org/img/avatar.png\",\"pinned_event\":\"c76166d9384355e8f55abfc071294fb815ac5f4050e2b9373b997b4bed66c669\",\"about\":\"[plantimals](https://plantimals.org)\",\"nip05\":\"[email protected]\"}","sig":"295aa6091dbe2bde0233a7909c094e4ae162f973475a7197a4a884c0614d9c24338849deb2571d57c308792205c5f8ad74aaf2796873c9bf1d150d69d2e3af6c"}

and the behavior of nostr.io profile page displaying the pin here.

does it make sense to make a new NIP for this, or should NIP-01 be amended?

[eskema]

not sure on how people here do that, but I think a new NIP extending NIP-1 should be the way to do it.

[plantimals]

@eskema I will proceed with that approach unless I hear otherwise. thank you

[plantimals]

I have submitted the "pinned events" NIP in #44

Unless there are other suggestions, or perhaps a minimum period of time for comments, I believe this PR is ready for final review.

[Semisol]

Could we use a replaceable event kind? We probably don't need to know about older bookmarks.

[eskema]

maybe adding an optional relay is not a bad idea, to know where to get the bookmark. If we go by the same syntax as kind-10, it would then be:

Bookmarks: ["e", "<event-id>", "<relay-url>", "<note text>"]

[staab]

Superseded by NIP 51, I think.