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.
GM
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).
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.
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).
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
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?
GM from wintery Bogotá.
"True freedom isn’t just about living for oneself. It’s about building a future where individual sovereignty is enriched by collective purpose"
https://globalnatives.substack.com/p/what-freedom-really-means-from-sovereign
This resonates a lot with me. Probably because I've been living as a sovereign individual for well over a decade now, but have also been helping to build both a co-living space and a co-op over the last few years.
GM
Scrooged, Die Hard, Bad Santa. (In no particular order.)
Opening a lightning channel is just a normal bitcoin transaction. So the fee goes to the miner who mines the block, same as with every other on-chain transaction.
If you buy an incoming channel from an LSP, then they charge a fee that is usually a bit higher than the pure tx fee. But if you spend through your own channels first, you can create incoming liquidity for free (i.e. the overall amount you spend).
Pro's use the new Nutstash wallet by nostr:npub1cj6ndx5akfazux7f0vjl4fyx9k0ulf682p437fe03a9ndwqjm0tqj886t6
Cool idea for rendering the balance as both BTC and sats at the same time!
All just so their upcoming CBDC is able to compete at all. Without this, many of the younger Europeans would just laugh them out of the room, given the abysmal performance of their shitcoin.
Yes! Also, RSS will live forever, because it's still orders of magnitude simpler than Nostr and already deployed across the Web. So we will have to use both for the foreseeable future.
Please tell me those 17 TB of data are actually still encrypted and the prosecution is just playing for both time and maximal lawfare pain:
https://www.therage.co/samourai-wallet-trial-set-for-november-3-2025/
