I suspected this could be the case.

I would expect that their cache ingests from a fairly large number or relays so hopefully in most cases there would be an overlap between the set of relays that the note is written to. It could be a problem if you are trying to use some special purpose relays. I don’t know how they handle things like the Fediverse bridge relays for example.

It looks like I can see Fediverse accounts in Primal so that does seem to work.

Is damus' nostrdb a better alternative to primal caching? Seems so, since, as I understand, it's running on the client, no?

nostrdb support filter queries, full text search, note stats, multithreaded ingester with efficient note de-dupe by a quick exit json parser, flatbuffer-like binary note format for zero serialization (queries return pointers to virtual memory) . It’s like an embedded strfry. IndexedDB isn’t really comparable. So yeah its like a caching relay in your phone

GitHub

GitHub - damus-io/nostrdb: The unfairly fast embedded nostr database backed by lmdb

The unfairly fast embedded nostr database backed by lmdb - damus-io/nostrdb

nostrdb - Rust

API documentation for the Rust `nostrdb` crate.

docs aren’t the best, still need to improve that

notedeck is completely powered by this, which is why its crazy fast. Still in the process of moving Damus iOS to it, but it is in damus iOS in a limited capacity (profile search, tagging, fulltext search, walking threads). Damus iOS just lacks using it for all queries atm. Another cool thing that notedeck will do is host many different nostr apps at once. Like a nostr OS/browser. This means all your nostr apps can interact with each other while you’re offline.

tangent but I would actually like a lightning app with this primal architecture im not convinced running a node on my phone is always the best all the load/syncing times, failed payments etc

Thanks, I was trying to keep it fairly balanced and avoid the drama.

Is there a way for #primal to make the caching server opt-in, or possibly a premium feature? Or does that completely break their app?

Anything is possible but I suspect the Primal team made the design decision to use a cache for their app so probably won’t change it. I think it could make sense to implement a fail back to local processing of notes directly from the relays in the case that the cache is unreadable. At least that way the app would keep functioning if there was a cache outage, although that would likely be with a more limited set of features than with the cache.

I could see it being a design decision since that probably simplifies a lot of client code and they're building several clients. But given that they're trying to make a profit somehow that seems like exactly the kind of thing you'd try to charge for.

Any notes that are visible ONLY on relays Primal doesn't cache from would not be visible on Primal, regardless of what relays you select. In Primal, you only WRITE to the relays you select, and you only READ from their caching relay. That said, the likelihood of any notes only being on a relay that Primal isn't caching from is relatively small. Most people are posting their notes to multiple relays with at least one that Primal is pulling notes in from.

The "it's no different from Twitter" is a gross overstatement, though I do sympathize with Will's view. I certainly prefer to select the relays I read from and have the client I am using pull notes from those relays directly. That said, I also understand Primal's choice to use a caching relay for the sake of optimizing for new users who barely understand what a relay is, let alone how to select ones that will achieve their goals. New users don't yet HAVE goals they want to accomplish in their selection of relays. On Twitter, you don't own your identity. On Nostr, you absolutely do, even on Primal. Yes, Primal COULD put fake notes that appear to be from your npub, but the fact that they weren't actually signed by your nsec would be immediately apparent when they cannot be accessed from any other client, and cannot be rebroadcast out to any other relays. On Twitter, you cannot post your tweets to any server other than Twitter's centralized server. On Primal, you absolutely still can maintain your censorship resistance by posting to multiple relays, because relays reject notes that aren't signed by the correct private key. On Twitter, you can only read tweets that were posted to their centralized server. On Primal, you may only be able to read from their caching relay, BUT those aren't just posts that were written TO their relay. You are still seeing posts that were originally written to a wide variety of relays. On Twitter, you are a slave to their proprietary algorithm. On Primal, you get to choose your algorithm, or create one that suits your own needs. Now, do I think this is ideal to only read from a caching relay? Absolutely not. Do I think Will has a lot of good points about why this is a compromise of Nostr's values? Yes, I do. But it's not "no different from Twitter" by a long shot.

Probably the best explanation of how #Primal 's cache relay works. View quoted note →

The "no different from twitter" is a bit of an exaggeration perhaps, at least on some aspects of Nostr, I agree. I am personally a big user of primal as well despite it having centralised tendency. But we must be open about it and clear and voice our concerns so that the devs steer development in the correct direction. And by the way the "use other clients" is not a good argument, if primal becomes the biggest client no one will build other clients. What we should do is use the decentralised clients and improve the protocol for better experience instead of going centralised.

Wait... "Use other clients is not a good argument," but "what we should do is use the decentralized (other) clients"? I don't share your concern that "if Primal becomes the biggest client no one will build other clients." Primal simply does not and will not ever do all the things that users want. They are absolutely optimizing for the newbie. Thing about that is newbies don't remain newbies for long. Eventually they want to try other things, or they see a note quoting some event kind that Primal doesn't display and they ask how they can see that note. There will be other clients that do some things better. Primal doesn't have live-streams, but Amethyst and noStrudel do, and zap.stream is specialized to ONLY that kind of content. Same thing goes for other types of content, such as photos. Olas is optimizing for an image feed, so is slidestr.net in a different way. Different users are going to prefer each approach. Amethyst has integrated the same event kind as Olas, but I happen to prefer Olas' UI for browsing images over that of Amethyst. The point is, different clients will ALWAYS have their strengths and weaknesses, so there will almost certainly be a few major clients on each platform (iOS, Android, Desktop, Web) and then a MASSIVE number of specialty clients that focus on a particular type of content or use-case. Even if Primal gains (or maybe has gained?) the largest user-base by simply being the easiest to use, other clients will still have a decent market-share because they provide other things users value that Primal has opted not to include.

Suggestion: slight modification to the packet leaving the primal server compared to other clients. Maybe a slightly different color?

Couldn't they easily get around this by having the option for relays to replicate amongst one another?

#realy already does this for user profile data and follow and mute lists and deletes and whatnot i already built a "layer 2" interface for it and have some example implementations that use shitcoins and second databases for testing the space limiting garbage collecting feature i built into the event store, it would be simple to add a layer2 that forwards queries out to other relays and caches the answer for other users as well as returning the results to the client

also, the question/problem of consistency on the nostr network is one that many minds are working on one really important thing to note about this is that the lack of a prescription for a consensus to create consistency is intentional, because every type of replication strategy has tradeoffs that are only suited to some use cases and not others

There are relays that already aggregate notes from other relays which provides similar benefits to the cache. I’ve previously used the nostr.wine paid relay which does this and works well.

Filter Relay Readme | nostr.wine

Last Updated: June 24, 2025

I did think about colour coding it but it was just a pretty quickly made up diagram!

I am not sure it is true that people will move away when they are not newbies anymore, people tend to stick to the first app they use. Now imagine if primal has a big chunk of the network and it is taken down by gov, what will this do to Nostrs reputation? I am not sure myself maybe the damage won't be big because people will just download a more decentralised client, but then why not use a decentralised client from the start? Why not just focus on the decentralised direction and improve that? If we can't create a good user experience that way we might as well just give up.

Great work though! Happy New Years!

Thanks! Happy New Year

Primal intends on building a fallback where the client will read directly from the relays in the case of a caching server outage. note1kdqwf24qu3cur6gsmynmqy2tzu9z4mnl8ymnwgrrgequssurl85sj9y498

Yes @miljan confirmed they intend on adding a fallback note1kdqwf24qu3cur6gsmynmqy2tzu9z4mnl8ymnwgrrgequssurl85sj9y498

Breez has been working pretty well for me

Interesting

I wonder if it’s possible to make it so that primal will read directly from a relay if it isn’t cached by the caching relay.

Thanks, I missed seeing that comment but good to know!

Yeah I got the idea from ChatGPT so I figured I would just ask him. I’d like to see Primal reading directly from a relay if the relay isn’t cached by the caching service

Why was he censored? What proof is there that he was censored?

ok cool will check it out

Apple is a walled garden that doesn't let you modify your OS (you can with jailbreaking but it's a complex workaround), whereas on Android customization is enabled by default, you can access folders, and make changes to basically anything. Primal uses a centralized Cache Service which is why primal stuff usually only shows up on Primal but won't show to other clients usually. They're both unideal if you want a freer experience.

As much as I want to understand the diff, 100 i do not 😅Goodnight Nostur 🐯#goodnight #GN