Custom feeds have seen no adoption for some reason. I don't know if it's because I'm a poor marketer or what
FWIW I did this by using #coracle to create a list of users and feed filtered for that list. Haven't seen a way to do this all in #amethyst so thanks, nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszrnhwden5te0dehhxtnvdakz7qgewaehxw309a5xyu3wvdhhyctrd3jjuum0vd5kzmp0er5gcs. #zap that man
Discussion
That seems insane to me
I will admit it is a pain to implement
Well thank you for being chad enough to implement it
i started once but implementing the full DSL is not trivial, i love the idea tho
Sometimes I wonder if the set operations were too much. There is a complete implementation in welshman, including validation and display. The hard part is the form which allows for editing a feed in an intuitive way.
We have too few users and barely any content, so there is nothing to filter and no users to do the filtering. Many good ideas will only show their true potential at a bigger scale.
I use several custom feeds regularly, it's not hard to build useful ones. My UX is horrible though
different scales require different solutions. outbox will shine at scale as well. you could argue its pointless complexity with the current number of users.
id say that not adopting outbox is preventing growth .. thats why everyone is gravitating to primal (one big relay), cause if you don't you're just noting to mostly the void.
how many real messages get stuck in damus throttling? i suppose yes you can queue and retry, but damus is the only client that does this.
anyway!
just my daily future trip.
what does this mean that damus client is the only one that does this? this is not true. the client doesn't do any throttling.
damus is the only client that retries
this can't be true, retrying is the only way to have reliable delivery. email does the same thing.
pretty sure its true, ive used a TON of nostr clients, none retry. many dont even surface the error to the end user either.
thats insane
it prevents growth,.. when you started to throttle, couldnt really use damus relay anymore.. pay to unthrottle would be nice.
yeah just need a noteguard module that bumps the reputation to those who zap the relay
public relays need to rate limit, spammers filled like 200gb into the relay without me noticing, thats what prompted me to do that
commies don't like money, ya know
the irony is, they paid a fortune for their iphone
and wen android damus? been waiting a year for that
turns out your rust is a bag of shit apparently
sounds like the clients should just fix that
almost no clients ever show NOTICE messages either, which is kinda lame
If we get big without widespread outbox support and a lot of relay decentralization capture by one big company becomes super easy and an obvious move.
I mean primal literally can't implement outbox since their clients aren't nostr clients, so that is pretty much guaranteed at this point.
If you are right then Nostr is the biggest waste of time in the universe and we should just give up, no?
How else do you reconcile the certainty of failure with keeping actively working on a thing?
maybe because I don't have a negative and black and white view on everything? I see it as a progression. outbox is inevitable at scale unless you want to silo yourself.
I thought you said capture is inevitable.
I can see them capturing the most users and not being able to implement outbox, but that doesn't mean nostr is pointless or dead. it just means its being used in a specific way that will become more isolated over time.
I believe the Primal people are as idealistic as you or I, and they want implement outbox, but of course laziness and business demands will probably take precedence over those ideals in a normal day. Now if they get really big and do an IPO or something like than we're screwed.
But the sooner more clients implements outbox and more people start using Nostr in weirder ways (like the simple act of publishing to small relays, which is basically impossible today if you want anyone to read your note) the sooner Primal will be forced to cooperate.
I think we are further along outbox implementation than we are being given credit for:
1. When onboarding new users, Primal ensures that the default set of relays includes a combination of larger relays and “long tail” smaller relays. We are already contributing to the spread of content over the entire public relay infrastructure. In contrast, Damus uses the same 4 relays for all new users.
2. We leave relay hints in all user and event mentions, as well as “copy id” actions, so that outbox clients can find things.
3. By default, all Primal clients write directly to the outbox relays the user has specified.
Therefore, when it comes generating content on the network, Primal already does all the right things. Please correct me if I’m missing something.
What remains to be done is the ability to diversify ways of reading/discovering content. We can’t solely rely on the caching service; our clients need to be functional without it. We are working on it.
As for the “Primal isn’t a real Nostr client” claim, that's a bad look nostr:nprofile1qyfhwue69uhhyetvv9uju6nzx56jucm0d5qs6amnwvaz7tmwdaejumr0dsqzqvhpsfmr23gwhv795lgjc8uw0v44z3pe4sg2vlh08k0an3wx3cj96l2ln2. Let’s focus on building. Damus still needs proper outbox and blossom support. Maybe that’s where energy is better spent instead of fudding another project.
how come ross@primal.net doesnt have a outbox list kind 10002? just a kind3.
I don’t think ross used primal to create his nostr account. if he did he would have had proper NIP65 relays set.
gotcha. i read your message here a few times, it made me realize, your version of outbox is not what I had hoped an outbox model would do.
i had hoped that if a client supported outbox, that people who follow me would see my notes. but ive heard from friends, they never see me in their timeline, only if they go to my profile page or to a 'feed' that im included in..
from reading your note here it sounded like that's because of the reading from outbox on primal is 'long tail?'.. 🤔
im just tryin to understand. installed it today for moar testing, and using amber 🎊
Interesting and that does make sense. 🫂
It's nice to see the turnaround in Primal's approach. Has potential to become a real nostr client after all.
I hope it’s true. The app is good. I just want it to be real NOSTR on the backend. No shenanigans.
You're doing great and I appreciate the transparency with your path towards Outbox/Inbox. Primal is as much of a Nostr client as any other that exists today. Primal's approach may be different in some areas, but that's still fine in my eyes. It's just different and that difference can be used to market to and appeal to different types of people since not all users fit inside the same box. Just like Damus or Amethyst has their own use cases, marketing, and target users. We're building for 8 billion people and we're not going to all use the same app.
Just implement outbox and blacklist the mega-relays.
the user experience suffers when there are multiple large modes without outbox support. I immediately noticed it on damus when primal started getting popular. You are going to have to implement it for user experience or become a silo.
I feel that. But even at this scale I feel the need for custom feeds to filter the noise. I'm probably not nostring efficiently enough
Your custom feeds tool is incredibly powerful, but I think we need better UX for it and more implementations across more clients. I'd love to be able to import feeds or have them just show up in Amethyst if I created them in Coracle and vice versa.
I'm hoping we get more of this when Damus #notedeck has their column spec complete.
Anyways, I would love to help you market your feature as I truly believe it's powerful. But I'm not an avid Coracle user. Let's chat.
The UX for sure needs improvement. Unfortunately notedeck is working on a different standard (cool, but not lightweight). I am releasing something next week which will increase their utility some. I'll DM you soon
There are a few clients now with columns or feeds. It would be nice to make at least some of them interoperable when it makes sense.
what do you mean by not lightweight? I didn't know we had a proposal ready
My understanding is that you run queries over a local database, right? Which means you already need to have all the stuff downloaded that you want to filter. That's fine for power users or apps with access to plenty of storage, but I want something more on-demand and with less storage required.
we use an optimized binary format. 148,000 notes is about 94MB, which is smaller than a handful of cached profile pictures.
even then we can just compact the db and prune it if storage was ever a concern. the image cache uses way more data.
Nostr has millions (and someday billions) of notes you might want to query based on arbitrary criteria. Feeds over a local database have the same problem any "global" feed has on nostr. If you don't know where to look, you have no guarantee you have everything you need. At some point, requests have to be built to fetch data from relays. Otherwise, you have to either sync with the entire network, or arbitrarily limit your feed to data at hand.
you don't need everything, you only need stuff that you're interested in or things in your WoT neighborhood.
for everything else there's nip50 search.
That's the kind of arbitrary limitation I'm talking about. Why not include nip 50 search in feeds? What about feeds powered by third party services that index the whole network for content outside your wot? I don't see why that stuff should a priori be excluded from feeds. It's fine to implement fast local feeds, but it should be an implementation detail behind a more generic interface, not the interface itself.
Just watched this, it illustrates what I'm talking about well. They even have feeds across protocols (RSS/bsky/activitypub)
I mean we support nip50 search feeds, i don’t know what point you’re making and why this is orthogonal to fast local feeds
I'm not sure what point you're trying to make either. All I said was that notedeck and coracle feeds aren't interoperable. Unless you're using my spec? https://github.com/nostr-protocol/nips/pull/1554
Placeholder for interop discussion here:
I was just replying to the claim that its not lightweight, i don’t know what the feed discussion is about. We just try to make sure the local relay has an api that is compatible with relays with extra functionality on top so you can do more advanced feeds locally and privately.
Any filter divergence just means we have to sync more data than we might need to sometimes yes. Extreme example is negentropy sync all data from your feeds in last 24h to not leak any query information to relays (privacy mode)
Sure, I guess we'd have to define what lightweight means. Having a syncing/cache component has its costs. But so does implementing set operations, so
looking at this, we have no concept of union/intersection/difference/dvm/wot(yet)/label so almost everything here is not useful to us
I would love to have custom feeds on Jumble.
cc nostr:npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl
You linked the spec to me the other day, but I still don't understand exactly why it would be helpful to implement something like notifications. Might just be a lack of effort on my part but I've got a lot of things I'm already juggling
Now that I have harnessed the full power of RxJS id like to try and implement them again. I think I got stuck on some of the recursive stuff last time
Welshman has an implementation you can use or adapt. The recursion is not too bad, but making an editing UI is really hard.
I like them as it's the closest thing to advanced search