Subscribing to publications

[franzaps]

E-mail marketing is an established strategy to reach people with subjects of their interest.

Many blogs on centralized platforms such as Medium or Substack (and self-hosted with integrated "automated marketing platforms") have tools to build and broadcast notifications to their audience for different reasons:

• alerts not to miss newly published articles
• weekly/monthly digests
• exclusive/custom content

On nostr, long-form notes are difficult to discover because most clients don't support them. Specific regular notes can also be easy to miss. And there is currently no way to build a subscriber list to send (private) exclusive content to.

The goal is to enable sites like Habla.news to have feature parity with Substack and alternatives, and more in general, for any blog to manage subscriptions and/or deliver notifications and exclusive content over nostr.

Subscription management

This basically means adding/removing oneself from a publication's subscribers list (subscription status).

Implementation options:

• DMs with keywords (e.g. subscribe weekly), equivalent to existing some e-mail mailing list systems (brittle and archaic)
• Use a Parameterized Replaceable List Event (NIP-51) for user subscriptions

{
 "kind": 30000,
 "tags": [
   ["d", "nostreport-weekly"],
   ["p", "3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d"],
 ],
 ...other fields
}

where p is the author's/publication's pubkey and d the specific content/newsletter.

However, some additional data appears to be necessary:

• Subscription status (subscribed/unsubscribed)
• Preferred subscription delivery methods (see Broadcasting below)
• Recurring payments (probably via NWC) could be linked to a subscription

Privacy:

• Can privacy be improved by including some of this data in the content field encrypted?
• Could subscription update events be sent to a dedicated publisher relay to improve privacy?

Broadcasting

Notifications could be delivered via a kind 1 (which would appear in clients under Notifications); this would require publishing a note p-tagging all subscribers. The downsides are privacy (though subscriptions might be public already) and lack of flexibility (no way of sending custom content)

Probably the best delivery methods are:

• Nostr DMs
• E-mail, SimpleX, carrier pigeons? Delivery does not necessarily require nostr

Why notifications over kind 1 or 4? Why not just use a separate app that receives these updates from a regular followed pubkey? UX. Notifications or special content should meet people where they already are, and for nostr these are social (kind 1) clients.

A dedicated kind for subscription notifications is a possibility, too, but it's one more thing for clients to implement. They could perhaps show these next to DMs.

Would this warrant a specific kind of list? Can we implement this with conventions on top of existing primitives? Any feedback is appreciated!

[fiatjaf]

I think "push subscriptions" are a fetish. You can't really reach people if they don't have a client they voluntarily run that fetches your stuff. That is true for email: people have to open their email inbox and read your stuff. That is true for Nostr DMs and anything else (perhaps not carrier pigeons). I never check my Nostr DMs and I don't recommend people to use them, I think it would be a huge mistake to make a new ecosystem of stuff that relies on Nostr DMs.

Nostr DMs are clunky and very bad in comparison to stuff like Telegram or email clients, and to make them better while also creating the expectation that they will be supported on all Nostr apps will involve huge amounts of work on all clients, it's a big waste.

If instead that effort could be spent on creating 2 or 3 very lightweight simple apps that just did the subscription management part and fetched your NIP-23 articles directly (based on some list like you suggested, for example) and displayed them to you that would be much better and much more healthy to the network.

If someone wants to make other kinds of subscriptions then that would be another list with another kind, and these same apps would probably support these too.

Yes, users would have to open these apps -- but this is no different than opening their email apps.

[vitorpamplona]

There are a few different concepts mixed into this issue.

1. E-mail marketing is almost always public. It doesn't need to be protected by encryption. Then you just need a solution to get public posts into people's feeds or DMs.

2. Alerts/Status updates/Notification stuff is almost always a super small summary with a link to the actual thing. Like a product just came in stock. These types of "subscriptions" are semi-public and they don't need to carry the full content.

3. Paid content (i.e. Substack) requires a block on re-broadcasting by the paid user. This was the use-case for GiftWrapped Rumors in NIP-24 DMs.

The implementation for each of these 3 types of UXs will be vastly different IMO. It makes sense to break the discussion and solve each one individually.

[alejandro-runner]

Here are my very long two cents:

Free marketing communications

I don’t think that we need a separate list for free marketing communications.

If somebody follows a business or a content creator on Nostr, it’s reasonable to receive marketing communications as regular kind 1 or kind 30023 notes in whatever client you use to read them.

The one thing that I would like to see, as the publisher of a newsletter, is for Habla.news to automatically send a kind 1 note when I publish a kind 30023. This kind 1 note should contain the summary and a link to the long form note on Habla.news.

This extra kind 1 note achieves two things:

1. Discoverability: it reaches my followers through an additional channel (their kind 1 client) giving them a heads up that a new long form article is available for them to check at their regular 30023 client
2. It gives Habla.news a differentiation and skews my readers to their site as opposed to competing long form sites. If the author is splitting zaps with Habla.news then this is an important item for Habla.news as an additional source of revenue

Paid marketing communications (subscriptions)

Here we need a separate list. The list should be private and managed by the content creator / business.

Habla.news could host a relay dedicated to subscriptions that only accepts queries for content from npubs that belong to the subscription list and the response should be sent encrypted with the npub of the subscriber so that only the intended subscriber can read it.

This will require a new kind and will put some processing requirements on the relay.

Additionally, on their website, Habla.news could show the summary and the first paragraph to everybody but only show the full note to users who log in and belong to the subscriber list.

Habla.news should charge for this service.

Creators would publish only on one site and not broadcast this content to other relays because i) they are paying to the publishing relay / site; and ii) they need to trust that the relay / site will manage the exposure correctly.

Subscription list management

The list should be private and managed by the content creator / business.

Option 1: by Habla.news
Habla.news offers the option to users to subscribe to unlock the full content.

• Pro: this is the most user friendly option.
• Cons: the subscriber list is hosted by Habla.news and the business / content creator needs to trust that it can export the list at anytime

Option 2: by a service that is not the publisher like nostr.build
The list should be automatically submitted to Habla.news with a DM or similar encrypted means of communication whenever there is a change. This DM format would need to be specified in a NIP as well.

• Pro: independent service from the publisher with less incentives to rug the content creator and not let him/her export the subscriber list at any time.
• Cons: users need to go to a different site from Habla.news to subscribe

Extra thoughts

The subscriber relay would allow business / content creators to run their own subscription relay to distribute their paid content and keep things in house as long as this new kind that encrypts the content with the npub of the receiver is supported by the clients.

[gzuuus]

It occurs to me that a good subscription system can be a service that the author uses, and is based on blind signatures to add interested people to a specific list. For example imagine that there is an app that is responsible for generating subscription lists, this app is able to create a small form or widget for users to leave their data, depending on the type of list or service expected this can more or less requirements to complete the subscription and add a new user, such as a paywall, etc.. Once the user subscribes the server updates the list, this list can be public or private, and the author will always have it at hand to send his new publications to his subscribers. Then, once this point is reached, the different platforms can integrate it in a simple way, simply by requiring the coordinates of that list.

Just throwing out ideas, but it could be an interesting model.

[vitorpamplona]

I believe the service could be a DVM. You simply create a request with your post and a list of individuals and the DVM ships the events in the way you want:

• Privately via Regular DMs (under your name/pubkey or not).
• Privately via GiftWrapped Text1s or Kind30023s (individually wrapped to each receiver, broadcasted to each user's personal relays)
• In some form of private group with a shared secret (just a single event to everybody in the group)
• On one or more public chats.
• In some communities that match the topic.

We can have multiple DVMs with slight differences in how to deliver this content and even multiple event kinds being used.

When we were testing NIP-24 for paid subscribers, we realized that for large groups (1000+ people), the phone wouldn't be very effective on singing and sending a new event to each receiver. So a DVM could solve this issue.

On top of that, since in many of these models the sender can be known (e.g. when it is a company), the DVM can use a non-random GiftWrapped signing key to identify itself or the sender when talking to relays. This will help everyone differentiate real marketing servers from random spam out there.

[arthurfranca]

My take on this is very simple: use #784 "unbounded lists" to list one to millions of "blog" subscribers and then send DMs to notify subscribers.

Upon Alice subscribing to an author's "blog" two things happen:

1. habla.news bot (or website api controlling a keypair) adds user (p tag) to an NIP-61 - Event Sets #784 "unbounded list" event of kind:33118 (an event with just ONE SINGLE p tag, encrypted or not - maybe don't encrypt until NIP-44 is finished). E.g.: ["p", "91cf9..4e5ca", "wss://alice.relay.com/"]. (It may have other tags like NIP-40 "expiration" tag to expire if not renewed by payment - you can keep editing the expiration tag later). Each of theses events share the same n tag (unbounded list "name") to effectively make the kind:33118 event an item of the same list, like for example: ["n", "blog_subscribers:<pubkey of blog author>"].
2. Alice adds bot/api's pubkey to her contact list so that bot/api's DMs get special treatment on clients.

Now use bot/api keypair strictly to send DMs (currently NIP-04) notifying subscribers of new articles etc. Don't spam or use this keypair to other things.

[vitorpamplona]

I agree, an unbounded list sounds like a great way to manage subscriptions.

[franzaps]

Thanks all for your input.

Agree https://github.com/arthurfranca/nips/blob/bunch-of-events/61.md#people-list appears to be exactly what we are looking for.

Upon subscription clients should:

• produce kind 33118 with user's npub NIP-44 encrypted, signed with publisher's npub
  • publisher's npub can optionally be a specific keypair used just for subs
  • signing with generic bot/api keypair could eventually cause vendor lock-in: the publisher should always be in control of their subscriber list (could leverage signups from different sites like habla, blogstack, etc)
  • notifications could be authorized/sent when publisher is online publishing an article, as they would be able to decrypt the unbounded list of recipients
• prompt user to add publisher's npub to contact list (whitelisting)

DMs are far from ideal but the privacy tradeoff for this usecase seems decent to me.