the clients do not read from relays. it reads from a single relay in a proprietary format. The clients don’t even verify the notes. Why call it a nostr client when it doesn’t even use nip01 for reading? The relay can censor notes, auto-follow and boost investor influencers, hide troublesome people (soon me im sure), something they have done in the past: (ralf, onyx, etc). It is completely against the ethos of a protocol where users are in control.
Discussion
Reading this shitty take from Primal
for now!
If we get to the point where nostr:nprofile1qqsdv8emcke7k3qqaldwv956tstu40ejg663gdsaayuuujs6pknw7jspp4mhxue69uhkummn9ekx7mqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduyhj993 is purposefully censoring you then we’ve won
are you evil or retarded?
Just tired of the incessant whining about Primal not being a Nostr client. It’s an open protocol. People are going to build shit you don’t agree with. Out of all the clients, Primal is doing the best job of bringing new users here. If we ever do move beyond the bitcoin circle jerk that this place is, then Primal’s algorithms, auto-follows, and caching relay strategy are just the start of many design choices that Will and other purists disagree with.
+1
Because let’s grow 🌱
But doc misrepresenting Nostr isn’t cool. That’s like a shitcoin saying it’s bitcoin.
I don’t think Miljan is misrepresenting his client or Nostr. He made a design choice to improve user experience and every decision has tradeoffs. He’s discussed it, and the source code is freely available. Your analogy between primal and shitcoins doesn’t work. I can’t use solana on the bitcoin network. But I can still interact with the Nostr protocol via primal.
you can use bitcoin on solana through a trusted intermediary
the analogy is sound
but it would be even more accurate to say primal is coinbase
I can’t have bitcoin on Coinbase and then open my sparrow wallet to see my coins.
If we’re comparing it to bitcoin I think it’s more analogous to running your own node or using someone else’s. Or using Breez vs WoS.
of course no analogy will match exactly otherwise it wouldn't be an analogy
but I'm fine with yours too
just tell me what will happen when primal get a court order from turkey to censor someone
They comply. And you use another client that has better censorship resistance and worse Ux. Or fork their client and run it yourself with your own caching server.
does primal relay primal user notes to other relays? so you can drop your nsec in another app?
Yes. The relays listed in your settings on Primal are the ones where your notes will be written to and accessible from other apps.
thank you! so even if ISPs block primal.net and brick the app temporarily, we just pick up our keys and move the party somewhere else
Sure. If your ISP blocks Primal, if their caching relay goes down, if they start censoring users... You can just use a Nostr client that isn't affected.
You can have wrapped bitcoin on ethereum and other chains.
In the source code Semisol and others have pointed out how their cache relay works and how they reconstruct notes in which they are replacing users media links with their own primal links. By altering the note they remove authenticity. Even if it’s the same media they have altered the note by removing the users media link and added their own link in which the user never signed or agreed to. What’s stoping them from altering an image now that they control the media file. This alone is enough reason to consider primal not a Nostr client.
I haven’t heard that and I’m very much against that if true. Do you have a note you can share that references this?
nostr:npub1m4ny6hjqzepn4rxknuq94c2gpqzr29ufkkw7ttcxyak7v43n6vvsajc2jl nostr:note1aqztmcwv5nc2d9sv78emw289f7ykv32kyzj3xfmvwkmz05trv7aqt28ja9
Can confirm. If you go to Primal's web app and look at any image, it is assigned a Primal proxy URL. For example, look at this note from nostr:
On primal, the image URL begins with `r2.primal.net/cache/b/c0/6b/`, but Jumble.social correctly shows that the image is actually hosted on nostr.build.
*...note from nostr:npub10wv37amdqnv8edw5yktgsxr62g8k4lqkk2u66fk6c6uwuakzssxsf4v22x."
Hmm… don’t love that. Just checked on iOS though and I’m able to copy the raw json event as well as the img url which points to Nostr.build. I’ll try on my pixel and on the web app later on. Thanks for sharing that
There's still something funky happening with the mobile app, too. For instance, this note shows tje image has been removed from nostr.build on most clients, but it is still visible on Primal's app, until you tap to view it full screen.
Primal screenshot:
Expanded:
This suggests that primal is showing their cached version until you open the image, rather than just showing the original.
I deleted the image from nostr.build
Now, bear in mind, Primal is not the only Nostr app that does this. Coracle I would definitely classify as a Nostr client, yet it also uses an image proxy, which I assume is why media sometimes takes so long to load on Coracle.
For instance, the same note from nostr:npub10wv37amdqnv8edw5yktgsxr62g8k4lqkk2u66fk6c6uwuakzssxsf4v22x on Coracle loads the image URL starting with `imgproxy.coracle.social/x/s:640:1024/"
Build something properly and the users will eventually come. Until then who cares. It’s about building the car not winning the race. Gaining users without building the car right is meaningless IMO. Play the long-term.
Building something 'properly' means building, learning, and refining based on real usage (with actual users) rather than waiting for theoretical perfection. I’m grateful for devs who value user feedback. IMO.
A million cooks in the kitchen will just lead to a mess. Luckily with nostr I can test my app without releasing because it has a ton of users already! All nostr accounts and posts appear.
Compromising on basic functionality in exchange for scale is exactly what all the shitcoiners do. There are basic principles that you just don’t violate. Building an app isn’t the same as building something that’s supposed to be embedded with cypherpunk values. If you don’t get it, you aren’t a cypherpunk.
Ah now the ad hominems come out. Please educate me on how to be more cypherpunk. I just find it disingenuous that other devs call Primal (an open sourced client with an open sourced caching relay) “proprietary”.
Anyway, I’m genuinely curious, what exactly do you have a problem with regarding Primal? I learned today about Primal supposedly caching images and then pointing towards their own server instead of the original url in the imeta tag. I was surprised and really don’t like that choice, but I haven’t confirmed it myself yet and want to learn more about why they do that. As a dev yourself, what are your major issues with how they do things?
Lmao — it literally reads from one server and I can’t change it. How is that decentralized? Decentralization entails a distribution of computers I can switch between freely. You understand nothing. 🤦♂️ like I said if you don’t get it, you’ve got some learning to do.
You don’t understand. They built a server that only their app connects to isn’t a nostr relay — it’s a primal relay. Literally no other nostr apps can connect to it.
We built a relay too, but any app can connect to it… Damus and beyond.. it supports custom features our Nestr app has, but we made sure to ensure backwards-compatibility. That’s how you build on a protocol.
you can be tired as much as you want but you dont get to change the meaning of things sorry
I am definitely with you on the issue with the client not verifying the signature on the notes locally, and you are absolutely correct that reading only from a single caching relay is a massive issue for censorship resistance, as has been seen in the past.
What's it take to run the caching service? I imagine that it's more resource intensive than a standard public relay by an order of magnitude, but is it feasible to be done? Are the resources needed to do so the barrier for why we haven't seen any others in the wild, or is it just that Primal tends to attract non-technical users that aren't interested in running their own infrastructure?
When it comes to NIP-01, surely the caching service must use NIP-01 to REQ from the relays it aggregates notes from, right? And the client is using NIP-01 to write events directly to the user's relays, unless they have the "enhanced privacy" feature turned on, so that the client writes to the caching relay, and the caching relay then uses NIP-01 to send EVENT write requests to the user's relays.
Now, I absolutely agree that this SHOULD be happening directly from the client, rather than going through the caching relay, but I also don't consider it so egregious a deviation from how I think Nostr clients ought to operate so as to classify Primal as not a Nostr client. That said, due to the censorship opportunities and past real examples we have, I would never suggest anyone use Primal as their only client. At minimum use at least one other client, and preferably one that has fully implemented outbox.
If they can kill nostr doing this, then it was not censorship resistant on the first place.
I think as usual, people are the weaklinks. We have to call these out of course. But the real winning would be if all users would call them out. Then it wouldnt even worth to develop such clients.
But if normal users dont call them out, only devs. It could seem from a user perspective, that one client dev is attacking another. And it feels fishy. Is he trying to get more users?
Also if they dont call these out, they will be fine using such clients, and will be controlled similarly by an algo as anywhere else.
Problem is, the users have no idea how Primal works. Heck, I spend a fair chunk of my time trying to wrap my head around how all this stuff works and still didn't know Primal wasn't verifying note signatures locally, only on their caching relay.
Users need devs to help them understand how their clients work, and why it is important that they work that way as opposed to the way it has been implemented in other clients. Otherwise, users only understand what they experience, and Primal delivers a pretty good experience.
Damn, I have so much opinion about this.
1. I am not sure knowing about why clients do what they do will speak louder than good experience. I mean, hack, google photos and drive still working quite decent together, compared to a nextcloud. Mine works also, but it is constant tuning, and effort. Aint nobody got time for that. But Google makes a lot of money on the data people feed it. Many people know it, but few act against it. It has a good experience, shitty on morals, but people use it.
2. I am not sure what percentage care about how the program/service works that they use. Either it works decently, so they use it, or it is too shitty, and dont bother.
3. I think people either are the victim of censorship, so they care, or they dont care at all about nostr uniqueness on this manner. And who cares about that will know their client. For these people, we definitely need to share these things. But a dev posting about this might not be enough.
4. Maybe we need to create an easily available table of features of clients. This would include note verification, usage of only a caching relay, storing search results connected to pubkey. Hmm, I will do this if it is not available already.
Couldn't have said it better.
Users care about their experience with an app, not about how it works under the hood. That is, until how it works under the hood encroaches on their experience.
Unfortunately, users don't often find out about this until they get burned. They choose the short-term, convenient experience, and find out later why choosing something that was a bit less convenient would have saved them a lot of pain.
For instance, just pasting in your nsec to log into a client is the most convenient way to use it. You only find out why you should have gone the less convenient route of using a browser extension or remote signer when your private key is leaked, either unintentionally or maliciously, by one of those clients and someone else starts posting as you. Never have that experience? Well, then you might never understand the importance of protecting your nsec unless you hear from someone else who tells you what can happen if you don't.
So, maybe the devs aren't the best folks for that job, but there need to be people who understand the protocol well enough to help other users understand why they should follow best practices. Otherwise, everyone is just going to gravitate toward the apps and services that are most convenient in the short term, without considering the tradeoffs that they aren't aware even exist.
all i am saying is we should use words to mean the things they mean. If anything is a nostr client then nostr client becomes a meaningless phrase.
I think as a dev I find this frustrating because they try to compare their “nostr client” against others to show how amazing they are, but it’s a lie. Compare amethyst, nostur, gossip, etc against each other sure, because all those are on the same playing field. Comparing primal to real nostr clients doesn’t make sense, because primal is more like bluesky or twitter, where they control all the infra and what everyone sees, censoring people from their algos, and monitoring user searches.
Do you see me bickering about this about other clients? No, i just want people to understand what is actually going on so they can make informed decisions instead of just pretending they are not a bad actor at this point.
Primal displays nostr content, but isn't a nostr protocol client
Yeah nostr frontend? I dunno what you would call it. If people want to use a frontend then fine.
clients themselves have variations within them: relay pool client, outbox client. Different ways to pull notes. I think this would be good to distinguish as well, then users could make an informed decision about that. fiatjaf is more interested in the latter for instance, which damus iOS currently doesn’t satisfy.
"Viewer"? "Proxy"? "Client-as-a-service"? 😂
maybe nostr gateway would be good. If the gateway goes down then you know you would have to switch to a client to get the raw data directly.
This is still probably going to be over the heads of normies unfortunately. but having words for it will be helpful at least.
I see .
I think gateway is probably a fair term. Then the caching service is acting as the gatekeeper for what is viewable via the gateway, which is an accurate assessment of how it works. You can, theoretically, use a different gatekeeper... if one existed.
Opera calls their analogous browser "Mini", and the backend a "compression proxy server"
They should be called out if they say something that is untrue.
But what is a nostr client? What makes a client a nostr client? Does it make sense to enforce what one can call a nostr client?
I agree that you shall not compare apples to oranges.
But also nostr was built for a reason. Other clients that does not fully support that idea shall miss something, otherwise the original idea of benefit of nostr does not hold. If they have a benefit, they shall outcompete others with that benefit, or? (Not this easy I know)
Also it does not help, that it is not that general, that people use social media with spending X amount per month. Social media is free in the eyes of many.
A nostr client connects directly to relays via websockets and pulls down notes via the nip01 specification. This is the bare minimum. If you don’t do this you’re not a nostr client.
Imagine creating a web browser that doesn’t connect to web server directly. Instead you connect to a central server that makes the request for you and completely MITMs you, losing all verification.
This server can tell you what sites you’re allowed to visit, and will randomly stop working when the server goes down.
You wouldn’t call this a web browser (aka web client). It’s just not the same thing. People who build real web browsers would be frustrated that they are marketing themselves as the best new web browser for the http protocol.
People trying the web for the first time get spied on, censored, and generally have a slow and unreliable expeirence. Now they think: wow the world wide web sucks and leaves.
This is why it’s important to use words properly and not let people affinity attack well defined terms.
This is probably the best explanation of the issue with calling Primal a "client" that I have seen. Thank you!
If the app you are running on your device isn't reading directly from Nostr relays, it's probably fair to call it something else, rather than a Nostr client. Otherwise, it would be akin to calling something a Bitcoin node when it isn't downloading and validating blocks locally, but merely trusting the information sent to it from some outside source.
I think I like your idea of calling Primal's apps "Nostr gateways" instead of clients.
Yeah, we discussed our architecture internally, at length, and decided to stick with NIP-01.
Both for transparency and simplicity, and so that anyone can host or fork our client, and add his own community relay, and have all core functionality immediately work and all the events from that relay immediately present. It also means that a user can log in and easily switch to using their own relay list for reads and writes, with a big toggle on the landing page. That way, even the person running the community relay can't stop them from reading and writing whatever they want, using our client.
And all communication is instantaneous, with no weird lag because of filtering, blacklisting, or the funnel effect of everything being pulled through one server. You aren't stuck using effectively one relay to read, and if one of the relays goes down, you won't even notice.
I feel like that's the Nostr "secret sauce", so abandoning this principle detracts from the usefulness of the protocol and undermines the censorship resistance of the original deisgn. I'm hopeful that Primal might actually implement that as an option, tho. We'll see.
The most recent update was definitely a step in the right direction. Time will tell.