Oddbean new post about | logout
  @verbiricha @Tony @Gzuuus #nostrdesign @fiatjaf thoughts on the above?

  
 I want to build it into Habla but without requiring the publisher to do anything, thought about using a public list for user subscriptions (could be pubkey or hashtag) and send them a DM whenever someone from the list publishes a new poast. Weekly digests sound great too, usually long form are low frequency so probably good to send one DM per publication, perhaps make it configurable? 
 Interesting so users have lists with "subscribed" publications, you'd need to query for all lists that contain publisher X, is this possible?

DMs leak metadata but are still more private than public lists 
 Yup we can filter by kind and #p to get lists that contain a publisher. 
 This seems like a good approach, although it still presents some challenges, users create a list, kind30000, this list can have a special title, or a specific 'l' tag for example to make it easy to find. Then when someone wants to publish and send notification, it fetches all the lists where its pubkey is included and sends a dm to these users. Of course, for example, another approach could be client side, without the author who publishes having to do anything. It could be a client where users create these lists of people they follow and don't want to miss anything, this client could be designed for this purpose and focus on this.
Another idea could be to create an npub for an application that creates lists of subscribers, and people can sign up to that list, the flow would be that users access this app to subscribe to some lists, these lists are published by the npub of the application (so that it is possible to sign up individually to a common list) and then the user who publishes can choose to send a message to everyone on the list.

Just throwing out some ideas, however they could be further developed and polished.
In any case, I think it's a great use case!🔥🔥
 
 I don't understand why involve DMs at all in this. If the entire flow involves a client asking relays for events, why not just ask directly for the articles? 
 Just check your DMz, that's all 
 So you can be on any client and get notified without having to remember to go to that one client where you read your subscribed stuff. 

You could just do both. Get DMs but also check out your favorite subscribed content client. This is essentially substack. 
 Because "any client" supports DMs? That's not true at all. 
 You know what I mean. 
 DMs are needed for special notifications, unless we come up with some other mechanism.

In addition, publishers could send exclusive content to (paid?) subscribers 
 The main thing is that some clients don't support long form notes.

I like what @Fabian does with Nostur: a tab for long form notes, so you can go there and see what's new from the people you follow. 

That is a good user experience because it happens inherently as part of the established habit of reading notes in your everyday client.  
 The entire point is that you are supposed to use different clients for different use cases. 
 I see using different clients as a user preference and client choice.

In any case, creating a kind 1 sidekick event would let users of “kind 1 only" clients know that they can go to their long form client to check the new content 
 Yes— in my own way— this rings true 
 This would be cool! I would like a weekly summary instead of individual updates, though configurable is probably best. 
 Here are my 2 cents (long post, sorry):

Current status:
 - Long form posts today on Nostr are difficult to discover because most clients don't support it and instead you need to go to a Nostr enabled web site like Habla.news to see who has posted something lately. This is very suboptimal

 - Outside of Nostr, subscribers to newsletters receive them via email. They don't need a new client. They discover the new issue of the newsletter as part of their existing habit of checking their email

 - The key here is that it's an existing habit on an existing client. No need to do anything new to discover new issues of the newsletter you subscribed yourself to.

Possible solutions:
 - When a publisher posts a new issue on their newsletter, Habla.news could simultaneously create a kind 1 event with the summary and the URL to the issue. This will allow the publisher's followers to discover the new issue through their existing habit and client, even if the client doesn't support long form notes

 - DM to all followers of the publisher. Could be considered obtrusive but let's face it, you're following that person for a reason. 

- Using a public list for user subscriptions like @verbiricha suggests above will work. But, doesn't this defeat the purpose of Nostr? I have always thought of Nostr as a way to follow a person and all the content this person produces. Would the public list require me to take a second step of subscribing to the publisher on top of already following him/her?  
 Great feedback, as you suggest there is no one size fits all solution. Perhaps the DM approach (with ability to opt out if you don't want it) is the way so you don't miss long form posts by people you follow. The idea behind subscriptions is to not only follow but also set up a recurring payment to the authors you want to support, I'm looking at NWC subscriptions and lists as a possible way to implement this but is still early and need to think about it more. I think we'll dedicate the next Habla design meeting to this topic, is the next big milestone for Habla. 
 Thank you! These are all great options and I hadn’t thought about the subscription being a paid one. That’s a very good point and would justify signing up to it on top of following 
 Can’t say anything in regards of technical implementation, but I love the idea! Especially the fact that it’s not limited to Nostr clients/apps.

What will the process be for regular websites to “realize” that someone is subscribed? Can readers manually send a DM to a specified Nostr address to receive notifications? 
 Let's follow what ends up getting built in Habla

nostr:note1v4mwlwldpyd9y5xxwxffhegytupn0mgczp9f77jsvngr3zf75vxq4sn604 
 🙏