What do you see? #logodesign 
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?
DVM's and Lists already provide this and ate way simpler.
Yup, the npub is key for:
- signing every version
- existing in a WoT so users know it's the right noun who signs
Using that same npub as a marketing tool is a byproduct of that
Awesome! F*ck therapy 🚀
Your thoughts on capping the influence of the amount of followers etc at 100% can probably also help a great deal with surfacing more niche thinkers.
Exactly 💯
WoT + Zaps seems like the perfect combo fir this.
Haha same here, but Nostr is driving me back to wanting to understand things like Life and the Universe. In order to build things right and coherent with it.
It's the best kind if feedback loop:
Better freedom tech ➡️ Better understaing of the universe 🔄
1. Time period can be quite long (days or even Infinite). Not sure what Twitter had but you could make threads longer days after the first post.
2. The thread creation tool is everytjing. 
This is one example I made way back. Typefully and Threads (meta app) also nail this.
I know, designed it 😉
Timestamp fixes all of this.
Clients can choose to display all replies from the same author within a certain timeframe as the main thread.
And I would even prioritise later replies from the same author too.
Mmm, weird indeed. I thought nostr:npub10000003zmk89narqpczy4ff6rnuht2wu05na7kpnh3mak7z2tqzsv8vwqk had a similar proposal for docusaurus-like implementations at some point. Will check.
Definitely seems a simple one and is for sure in my top 10 of "need this asap".
Coracle doesn't have threads at all.
It shows my comments on my own post last (in chronological order), has huge indentation (preventing going more than like 6 layers down) and is one of the least info-dense apps out there with all the whitespace. Which is great for many other use cases, but not for threads.
And you can go as granular as you want with a tree like that I guess.
Aaaah, I see!
That's exactly how books should/will work on Nostr btw. Forgot if there was s NIP for that yet.
No need for a NIP for this.
It's up to each client to pick how and in what order they show kind1's.
Thread = an npub commenting on his own kind1's, basta.
Aha, that was that issue. Good to know.
Fedora has most of what I really need/use in MacOS, so u should be fine 😉
💯
Take away those limits and you remove the high signal great threads typically have.
Displaying them as a actual threads also offers the most efficient ways of interacting and sharing.
However you choose read them, if that's your main goal, is up to you (especially on an open protocol).