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.

Reply to this note

Please Login to reply.

Discussion

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.