Some thoughts about Nostr & Custom Feeds

A bunch of nostr apps have custom feeds, but they’re oddly one of the few things which aren’t reusable across apps. Over on bluesky, they’ve got 40k custom feed algorithms and it’s a really popular thing.

For example, here’s a feed of just pictures of moss: https://bsky.app/profile/did:plc:x3cya3wkt4n6u4ihmvpsc5if/feed/aaacynbxwimok

In particular though, there’s feeds for different takes on what should be for you, trending, top, etc…

We don’t have that in Nostr, and i wish we did. I’m going to outline a way in which i might be possible for us to get there.

First off, we’ve got to understand how the third party feeds work in bluesky. The way it works is that each user has a single PDS (think relay) where they post their content. That relay is then indexed, by a global index server (there can be multiple), which may or may not keep a cache of a users content.

An index is a third party service which clients can connect to and say, i’m bob and i want the feed “only posts by bobs”. That feed service does not keep a copy of the content, nor does it provide it to the clients. Instead when user Bob requests the “only posts by bobs” feed, it checks the user requesting, then it’s indexes of content, and returns an array of message id’s (hashes) for what it thinks is a good bobs feed. The clients then request that actual content from the relay (PDS) servers, or their caches. There’s even a service for no-code creation of custom feeds, skyfeed.app.

This would be pretty easy to make. A nostr relay service that instead of serving the full content, just lets you request a feed, and it would return message event id’s for the events in that feed. You’d then go request that content from relays that are hosting content. We could do it with dynamic lists too, but then we wouldn’t be able to customize it per user.

I’d like an easy way for developers to make and deploy custom feeds without having to have the whole own nostr app the way they need to do it now. As an app developer, i’d love people to be able to build their own feeds without me doing the work of tight integration.

I know that Damus has nostrscript which does some of this in the client, but it only works on one nostr client, and hasn’t really taken off yet. A server based solution might be a lot better. Something we can support that works with nostr, but lets people make many feeds.

Thoughts?

Reply to this note

Please Login to reply.

Discussion

Isn't this just like lists with extra steps? If a user fails to tag a picture as Moss on blue sky, would it show up on the Moss only feed still?

A habit that I've carried over from Twitter is having different lists that are all different feeds essentially.

I thought DVMs addressed this use case already. Maybe not though.

I would rather the relays stay simple and not get added complexity regarding that.

yes

i like this a lot, been thinking about composability in general and specifically about discoverability and relay logic

lists are the closest, but as you say, they're generic, and making per-user lists would be unwieldy

complicating relays in this is a big departure from being 'dumb'

so i wonder if optional 'indexers' are the way, i think many clients are already doing it (certainly primal), and everyone keeps doing it their own way, we'll eventually see the clients become walled gardens

ofcourse the downside is that indexers become de-facto sources for most, but as long as they're easy to implement/stand up (i'm even thinking in-browser personal indexers), the same argument used for relays is used for indexers - and there's always the option of just querying relays directly

the upside of shareable feed logic and the reduction of loads on relays due to indexers aggregating (most of) the querying feels worth it

I've written a tool to train ml models against the nostr feed as well as custom labels with multiple rss feed sources. I don't know anyone who wants it, but I've always hoped someone use models trained on cafe-society.news to filter messages on the relay. It would likely require installing winknlp on the server. Or start with a simple whitelist and blocklist (words) expected to be run on the server. (assuming there's not already NIP for content filters)

We have user-creatable feeds. What we don't have is a just this tiny piece: clients letting their user see the feed that was defined by a different person. It is a good idea and should be easy to do.

Can't you login with someone's npub?

Yes, but you'd only see it while logged in.

There's no technological reason why you should have to do that, as lists are public data you can display.

That is how you can do it today. But logging out and in again is a pain and shouldn't be necessary.

People keep asking me how to do this.

At the moment, you can duplicate someone else's list, but if they change the list, you wouldn't get an update.

Being able to subscribe to someone else's list would be awesome.

I know at least Primal and Nostur clients have this feature.

DVM's and Lists already provide this and ate way simpler.

Some people look at DVMs as a way of creating a « market » for portable custom feeds. If I understood it right…

To all the people saying DVMs do this, don’t those require paying in order to use?

I’m all for financially sustainable tools, but if the only way to make custom feeds is paid, that’s not going to get mass appeal and is niche at best.

You can always make it free. Or one time payment only. You would have to compete with other dvms.

I agree that being tightly coupled to bitcoin isn’t ideal. But I am not sure that it is in the spec. Ideally it would just require a generic “authorization” that could or could not be provided by bitcoin or some other financial platform

My projects are very much interested in this.

It seems to me that if a user is trusting a third party to create a filter, then they can trust the third party to be the author of the nostr events needed.

So if a client can look up an event authored by the feed service, that is indexed with a tag of the pubkey of the user requesting the feed, that event itself could contain list of events in the feed

And it could be indexed by any old relay.

So,

1. User indicates to client the feed service it wants to use by pubkey

2. Client requests event created by the feed service that has the users pubkey in a tag

3. The event contains the list if ids for the feed. If the event isn't there (the first request) I guess a DVM is needed to generate the initial file

4. Client requests those ids and displays to user

Anyway, it's a way to utilize existing relays