Recently David King had me on his NostrTalks podcast, and one of the things we talked about was how custom feeds might work. I was reeling from David challenging my assumptions about relay centralization, so I didn't do a good job of enumerating what our different options for custom feeds are, and how they differ.
Data Vending Machines
Pablo followed up here, asking my opinion on custom feeds in general, and his Data Vending Machines proposal in particular. I thought I'd write up my response in long form for posterity.
I like DVMs, although I ignored it for a while because I figured that Pablo was bouncing off the walls as usual (congrats on placing in the AI competition!) and I'd wait till he settled down. I read a bit of his nip this morning and the custom feeds use case caught my eye as an interesting application of the DVM idea.
Algorithm options
I don't know if vending machines are a good solution to custom feeds, but I'm open to being convinced. Below are a few different approaches we could take to the problem:
- Built into clients — closed or open source, not swappable except maybe using NIP 89
- Built into relays — swappable, composable, monetizable, allows for moderation/publishing models, can support "private" algorithms. Also highly consistent, you're not going to get partial data because events weren't where you were looking.
- Published by pubkeys — not parameterizable. We saw how this went with @Sherry's recommendations bot. Great idea, but lots of limitations.
- List- or label-based curations — lightweight, not parameterizable, but very clean, could support private use case via wrapping
- DVMs — parameterizable, monetizable, but very heavy, probably not suitable for general purpose custom feeds due to latency
- Custom algorithms published as NostrScript events — swappable, pluggable, very flexible, content-addressable.
I think all those options have their own benefits and trade offs for different use cases. Relay-based feeds are going to be good for low-latency, dynamically-built feeds. Pubkeys are good for publishing-type use cases. NostrScript is good for shareable user-defined feeds (and other things).
I don't think DVMs make sense for "feeds" as we think of them, but could be good for generating more bespoke artifacts, like a "top highlights for this week" email/feed, or something that interleaves nostr events with some external data source.
My favorite of the bunch is lists and/or labels, which can be arbitrarily nested and used by clients/scripts/relays to build more sophisticated feeds (for example, by incorporating distributed moderation or web-of-trust-based recommendations subjective to the target user).
This has actually always been a core part of my vision for nostr and coracle since even before I found nostr. Unlike Amethyst's kind-1984 based content moderation approach, lists and labels can be interpreted using user-defined terminology.
In other words, the definition of "good music" depends on who you ask. Allowing the answer to be generated not by a single pubkey or relay, but by your entire network seems to best embrace the emergent behavior nostr enables. These content recommendations can be weighted as much as desired based on other social data including reactions, replies, mutual follows, how many lists someone appears on, etc.
Of course, this more analysis-heavy approach means that feeds are not defined only by lists and labels, but by an opinionated interpretation layered on top of those, which might best be provided by a relay, DVM, or client.
Do we even want feeds?
While we're on the topic, it's also worth asking if "feeds" are really what we want. The idea is very closely tied to the infinite-scroll pattern common on legacy social media, and the name evokes the process of fattening livestock for the kill. In some ways, I think infinite scroll is with us for better or for worse - pagination buttons at the bottom of a page is no solution, that would just be an inferior version of the same thing.
Perhaps, taking a leaf out of Twitter's book, brevity is the answer. Being forced to fit our thoughts into 280 characters helps us write more clearly and with more interest, what if "feeds" had the same constraints? Having no page bottom incentivises a never-ending list of diffuse non-information.
This is one reason I love email newsletters - at best they are carefully researched, edited, scheduled, and sent to your inbox. The email inbox is a hostile place, missives that land there are likely to suffer a swift demise. If an email is to survive, it must be something the recipient wants to read.
In a way, The Nostr Report is itself a custom feed in this sense, published via a shared pubkey. It would also be possible to write a "client" that links your pubkey and email, and sends you a daily/weekly digest, tailored to your interests and social graph.
Taking this idea a step further and combining it with list and label based feeds, instead of creating lists based on content, you might create a list based on timeframe. Then, in order to generate a digest for that day or week, you would pull all time-based curations from your network, analyze them for common threads, and re-publish as an email, note, or list.
At any rate, I think this is an exciting area of research, and that we've only scratched the surface of what's possible with an open social graph. I'm glad to see Pablo creating an entirely new category of solution with his proposal.
