Nostr Web Client

nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 Have you thought about NIP-23 feeds for publications instead of pubkeys?

I.e. one could subscribe to a feed of a specific blog that multiple authors write using their own pubkeys. Most blogs in my RSS reader work like this, and I think it's crucial for NIP-23 to be as useful as it can be. The cool thing about Nostr feeds vs normal RSS feeds is that the content would be properly attributed to each author and can be gathered and rendered outside of a centralized blog/feed as well.

I was thinking about creating a new kind for announcing a "publication" (i.e. blog, magazine, etc.), which holds metadata similar to a kind 0 profile (display name, avatar/icon, description, ...). The pubkey "founding" the "publication" would then add tags for authorized author pubkeys, so clients could verify that when a kind 30024 article is tagged with one or more publication IDs, it's not spam or impersonation.

One problem with this (and with a system without time in general) is that when a founder would remove authors later on, it would appear as if they never wrote for a certain publication. But I'm not sure it's actually a problem in practice.

What do you think? Maybe I'm thinking about this all wrong? Or maybe someone has solved this already?

fiatjaf 1y ago

One easy solution would be https://nips.nostr.com/18#generic-reposts: a publication pubkey would repost specific events from other people. In fact that reminds me I should support that on narr and noflux, should be easy.

But I've seen that question come up many times and in my mind the ideal solution that composes better is specific publication relays. A publication would have its own custom relay (well, just its website would act as a relay too underneath, like fiatjaf.com does) and everything you could found inside that relay would be part of that publication feed. The events could have a NIP-70 "-" tag to tell all other relays to not rehost them so articles written by someone for a specific publication wouldn't be found in that person's normal feed (or they could choose otherwise, of course).

Reply to this note

Please Login to reply.

Discussion

Râu Cao ⚡ 1y ago

Hmm. I always thought the basic idea of Nostr is that events are not tied to domain names or URLs or anything of the sort. Off the top of my head, I see 3 issues with this special-relay approach:

1. It diminishes censorship resistance

2. Seeing publications tagged (and linked) in articles before having subscribed to a special relay is good for discovery. I would definitely want people to be able to subscribe to all my articles by just subscribing to the pubkey itself.

3. It adds a burden on publishers to run special infrastructure

fiatjaf 1y ago

Well, what is a publication anyway if not centered around a brand and a special infrastructure? And censorship concerns are diminished in this case as you're already running your own server -- moreover a publication already "censors" by its own nature, since it doesn't accept articles from anyone.

The special relay approach doesn't prevent anyone from linking, tagging or replying to the publications themselves from other relays, that's the beauty of Nostr indeed and it wouldn't be lost.

Râu Cao ⚡ 1y ago

A publication is a collection of content from various authors/creators, usually with the permission of the author for their content to appear in it. Personally, I would not call user-curated collections like e.g. on Flipboard a "publication", since the idea of a publication is for content to be first published, not merely shared, listed, or linked.

The potential censorship risks of DNS have absolutely nothing to do with publications not publishing everyone's articles. Not sure what you meant to say there. I meant that when events are spread across multiple relays to begin with, it's much harder for people to lose access to content, when a single relay goes down for whatever reason (can also just be infrastructure issues).

fiatjaf 1y ago

I honestly don't get what a publication is, in essence. If it's not curation then it is what? Is it like a movement by which various people are gathered and they all agree to write articles specifically to be published on that place? That would make sense.

If I am right about this then the relay specific for the publication is what makes more sense to me:

Considering an example on the internet of 20 years ago, we could have Bob and his blog at bob.blog and a publication at xfiles.pub. Bob generally writes about politics on bob.blog, but on xfiles.pub he only writes about the X-Files.

Normal Bob followers will naturally connect to bob.blog and read his politics stuff and never see his X-Files articles and X-Files fans will read Bob's articles on xfiles.pub and may or may not be inclined to look for other Bob articles on bob.blog.

Of course, anyone is free to copy-paste Bob's articles from xfiles.pub or from bob.blog and rehost them elsewhere without mentioning where they were taken from, but that is of little relevance to most users.

Râu Cao ⚡ 1y ago

I want to implement multi-author blogs on Nostr. For example for our opensource co-op. The authors should be able to tag posts for one or more blogs, and the co-op key should publish who's allowed to post. When our relay goes down or loses DNS connectivity for whatever reason, everything can still be accessible from other relays. Clients can also cache whatever they want.

fiatjaf 1y ago

What does it mean to "just subscribe to a pubkey" anyway? It means connecting to the relay or set of relays that pubkey has chosen and downloading events from there.

In this case subscribing to a custom relay is different, but not completely different, in practice -- but I grant you we have no way to do this seamlessly currently in any client -- except perhaps Nostur.

Râu Cao ⚡ 1y ago

It means to fetch and render events created/signed by a specific key. In this case, all article events. The author has no control over who fetches and syncs their stuff. I sync your articles to our relay for example, then subscribe from there (currently via RSS, because I haven't tried out Narr yet). There are also caching relays, mobile relays, etc.. This is why tying anything to a particular relay seems like the wrong approach to me.

Also, relays are identified via DNS and don't additionally sign content, so without any kind of tag mentioning the publication (in that case the relay), the author's intention for being published there is not clear.