quotinghttps://pinboard.in/ is a thing that would work great on Nostr: it's personal and social at the same time. You collect links that interest you and add comments for yourself, but with enough people doing that it creates a hivemind of potentially interesting content.
nevent1q…2uhx
The only requirement is that it is blazingly simple and fast for managing your stuff.
This morning I integrated this behaviour too on https://ccns.nostrver.se. So new created links are now broadcasted as kind 39700 events to several relays.
So we have now 3 clients using this kind number and I have some suggestions to improve the currently used event structure which I wrote down in this article:
(fallback URL: https://nostrver.se/blog/links-posted-ccns-are-now-broadcasted-nostr-events-kind-39700 for client who don't render those bech32 formatted keys).quoting
nevent1q…dmxwhttps://ccns.nostrver.se is a (Drupal powered) website that I started to build in January 2024 (source on Github and Gitlab). It’s a fork of an earlier (abandoned) project https://cchs.social/.
Currently CCNS is a link aggregration website and for now it’s only my who is using it to save and share Nostr related links. When you post a new link, you have the option to cross-post it as a Nostr note (example here).Kind 39700
Last month Jurjen and Abir has started to work on a social bookmark client built with Nostr (inspired by Del.icio.us from the past). Earlier this month they changed to event kind 39700 for broadcasting the Nostr event with the bookmark / link data accross the network. They did this because Sep already created a social bookmark like client called Pinja when fiatjaf raised this idea.
With these developments to me it was very obvious to integrate the feature that new created CCNS links are now also published as kind 39700 events to the Nostr network. This means that links are now also distributed on multiple relays as kind 39700 events and are accessible in multiple clients (Yumyume and Pinja).
Here you can see the same data, from left to right:
Structure
The current data structure for the 39700 kind looks as follow:
- “id”: “event_id”
- “pubkey”: “pubkey author”
- “created_at”: unix_timestamp
- “kind”: 39700
- “tags”:
- “description”, “description text here”
- “d”, “unique-slug-value”
- “t”, “hashtag”
- “content”: “https://book_mark_url”
- “sig”: “signature”
As there is no NIP (yet) for this event kind, I see some possible improvements:
- Use the bookmark URL as
dtag so it can be used as a unique identifier for every client- Use the content field for the description
- Use the
atag for an addressable event following NIP-01:["a", "39700:pubkey_of_author:", recommended_relay_url_optional]On short-term I don’t have any plans to developer CCNS further, as most of my attention goes to the development of the Nostr-PHP library and Drupal related contribs using that library. That said, CCNS is a Drupal project but all the Nostr stuff is done client-side (Javascript) with NDK and Nostr-PHP is not used (maybe this will change in the future).
