this is what happens in the future if the "outbox-is-broken-let's-use-smart-proxy-relays" people win:

- people start relying on "caching services" to fetch their notes. now every client must run their own caching service to remain competitive.

- as the network grows, syncing from all relays becomes more and more prohibitively and databases grow to the infinite.

- less and less caching services exist, but a "local best scenario" would be if we had like 4 different clients/caching-services to read from, but then if one of them banned alex jones that would mean 25% of users lose access to alex jones. there is nothing alex jones can do to change that.

- users could switch from app A to app B that hasn't banned alex jones, but app B had already banned donald trump, so that move is questionable and uncertain. anyway, it's too much friction for a user who doesn't know how to find this caching-service setting buried deep in their settings (because UX specialists said that's the best place to put it).

- eventually it makes no sense to switch anymore and as one of the caching services gains more market share they merge with the others, saving costs and regulatory burden (these caching servers are so big they need to do spam moderation, find and delete pornography and scam bots, comply with government takedowns, defend themselves against lawsuits, it's a huge cost), so it's much better to just have a single caching-service.

- everybody still publishes to their own relay, so nostr becomes exactly like bluesky and the central service can censor anyone. eventually people give up the stupidity of using intermediary relays and just publish directly to that central service.

- that central service now can serve you ads and blue checks, shadowban everybody who doesn't pay, modify your feed with amazing AI techniques to keep you engaged and prevent you from seeing anything they don't want you to see but keep you nourished with memes.

Reply to this note

Please Login to reply.

Discussion

I'm happy that even though Primal started this movement about caching services they are moving in the direction of implementing the outbox model at client-side. And Damus has also said they will do it, so everything should be ok.

gonna keep yelling this until i stop hearing about the "debate" about outbox vs gossip (broadcast, blaster, whatever)

PRIVATE STUFF VIA OUTBOX

PUBLIC STUFF VIA BROADCAST

deal? good.

what do you mean by "broadcast"?

what is ambiguous about broadcast? send it to everyone!

in that case you are completely wrong

so, you mean you don't want events intended to be public to be broadcast? or what?

everyone who doesn't have it? maybe first ask "do you have these id's? respond with list of NOES matching sequence plz"

we can argue all day long about broadcast mechanisms but if the origin is the original origin then definitely you want to broadcast them

group messages, maybe you want to only send them to group relays, but kind 0, 1, 10002s and all those other fun public things should be sent everywhere from the first second, second round, shouldn't be necessary if first round worked

when i say broadcast in practical terms that means epidemic transmission, meaning that you send them to several nodes, and say "plz share" and they send them to several nodes until everyone sez "stop sned plz"

also, git r done with making relays that can keep the newest stuff new and not blow up their disks by not pruning off boring and old shit

Why do everybody has to see everything? This makes no sense and is not scalable. You just put your stuff in some servers such that others who are interested in them can go and ask those servers.

The primary assumption of Nostr clients should be that relays will reject your events by default.

that is pretty ridiculous, especially if the client just authed to the relay as a paid up customer

Of course in that specific situation the default assumption doesn't apply. I mean when you know nothing about a relay and you just got it from the nostr.watch API, for example, then there is no point in even trying to send stuff to it.

so NIP-11 was just pissing in the wind then? because you can't trust it?

you should read some bitcoin code especially the section about version codes and capabilities

You definitely can't trust it, but you could still use it to orient yourself.

Versioning and capabilities are a shitcoin, manual hardcoding is the only way.

so what's your position, seems like you want to agree with whoever is posing the question

seriously, this is well established protocols on network protocols since forever

i don't think you are stupid, because i read your code and i assume you wrote it who types right now but you clearly have holes in your understanding, and a lack of courage to stand by positions

you won't get anywhere long term if you don't stand for yourself at least

This is a hot take, but I'm listening... 👀

yes!!!!

it's scalable because it only has to apply to current data, so old stuff can be reduced in its replication count, relays don't have to store everything, they just have to be ready to deliver what people ask for, and what is new

You know you're describing how Farcaster works? They have a requirement that nodes store everything, and they have it hardcoded that stuff older than whatever time can be deleted.

so because stupid people have some elements of sense throw out the sense with the stupid?

also, none of this stuff is new

cache management should be standard procedure for an unbounded level of data storage

the disk doesn't magically grow in size bro

What is "everyone"? All relays in existence? If 2000 relays exist you'll send to all of them? Why do you assume these relays will all be willing to accept your notes? If they do accept notes from everybody they will certainly blow up very easily and stop working, therefore they cannot. And if they cannot then what is the point? The outbox model fixes this.

yes, i'm quite aware of this

kind 0, 1, and several others are intended for broadcast, and that is fine, people can decide whether they want to cache them or not, but they are ostensibly public

so they can be broadcast, regardless

i've done work building gossip networks and for this reason i wrote a flatbuffers style codec that lets the gossip node quickly reject messages that are irrelevant to it, this is really the main thing that flatbuffers style binary codecs are useful for, and counter mode encryption can be useful for this also as it lets you selectively DECRYPT the message as well and extract fields by their offfset and determine whether to decode the whole message without doing a whole decryption AND decoding

i like how you just say "you are wrong" and leave out the "because" part of the sentence

bravo!

in philosophy being unwilling to engage in debate with another person is a sign of cowardice and deception and not respectable behaviour

i may be erratic at times but i'm not malicious

Primal is an attack on #Nostr

If anyone has a different idea of what will the future look like without the outbox-model (or something like it) that isn't so dark, please tell me, I'm very interested to hear but I can't for the life of me figure out what is in the minds of people who don't like it. Thank you very much.

The common theme i’ve seen of people who are anti-outbox/gossip model is one of two camps:

1. Those obsessed with performance/speed/data usage and they believe centralization is the only way to do that.

2. Those who don’t fully understand how outbox/gossip works and they think it means clients will randomly pick which relays their posts are sent to

outbox model one of a very small handful of fundamentals concept that make nostr what it is.

Just make sure that the outbox model is as essy to implement as is NIP-01 and we‘re good, I think.

At least it sounds like we'd still be have memes...

Yes.

Very insightful! It’s troubling to me that basic functions have not been fully ironed out. For example, I get different notifications depending on the client that I use. Is this something that outbox will fix?

Yes.

dont let nostr be bsky 2.0

Aggregator/broadcaster relays can also implement the mailbox model, like wine just did.

I don't know what a mailbox is, but if you mean the thing about accepting private events and only serving them to the rightful user after AUTH then yes, that's a good thing, but completely irrelevant to this discussion. inbox.nostr.wine is different than filter.nostr.wine. Completely different roles.

I meant that they have implemented NIP-65.

That is just a dumb list of relays.

It looks at their preferred relays and targets those, rather than just writing to a fixed list.

We use NIP-65 on the broadcast side now. More to come soon 😁

nostr:note18a4wfnk2e9rzuh8hj6szfr9rr6yhtt5ylx76cqeprpgzemrp5tysz7cl58

Can you exclude mutes? I'm going absolutely nuts switching clients, so often.

It could be done but it would be a bit wonky since we would need to filter out those mutes in real time (no negative nostr filters).

We are working on a more personalized solution too but still lots to do!

Okay, then I'll wait for you to wow me, instead. You're the data guy, so you're probably thinking of things I haven't thought of, yet.

nostr:note1h0un80snqg99yj35rxrpzuc6p2xq0de2589seayexhfa9nc4jkhsx09c5y

I wouldn't put it as X people v Y people, though.

these are damands that customers have. it is natural for app builders to try and deliver on those demands. social network so far has been built on top of a incentive system that rewards those enterprises through volume of engagement and ad revenue.

what makes nostr interesting is that I can be financed and can exist in a different incentives system.

I'd wager that until we see new financing, marketing and engagement solutions, people will see more value on a more populated network then in the "morally superior one", whichever you think that is.

Maybe I haven’t thought this through all the way, but how will smart caching relays drive out clients that use the outbox/gossip model? Why can’t they exist side-by-side in the long term?

The scenario you describe is essentially what has happened to email, although the driving force in email was spam. My hope has always been that on Nostr we can solve spam in a more nuanced and decentralized way. If we can’t do that, then centralization feels inevitable. But if we can model trust/reputation well enough to solve spam it feels like those same tools could lighten the burden of running a relay, keeping small relays around.

With email you knew the address of the "relay" where to send your messages, in Nostr you can have that as long as you have the outbox model or something like that, but if all you have is a static list of relays everybody reads from then you can solve the spam problem with trust and reputation, but you'll be worse in terms of decentralization of the transport medium.

banning alex jones is a right thing to do

Every relay should definitely be free to do it.

> as the network grows, syncing from all relays becomes more and more prohibitively and databases grow to the infinite.

I think the main flaw in the reasoning here is that caching services don't have to cover the entire network. A caching service that only serves a few users can stay very small. The caching service selection might be buried in settings as you say, or it might run within the client (which is compatible with outbox model purism — what is a client but a local cache?)

In any case you have to trust your service provider, whether they're a FOSS client you run on your device, or an opaque web service sitting out in the ether. The key is redundancy. We have this on the relay level, but we would need it on the indexer level, the caching level, and the client level. This can be done to some extent by asking users to use multiple services, but that's pretty unrealistic from a UX perspective. Other mechanisms could exist for reporting on clients/services, like lightning watch towers, Wallet Scrutiny, or client-side stats which can infer censorship scores for different external services.

What do people generally mean by "caching service" or "global state"? In my understanding they are meaning strictly a server that has _all_ the data in the network.

That's definitely what the only existing caching server does. But I think you can have a meaningful cache that covers only part of the network, depending on the users it serves.

Are you referring to Primal? And if so, does it/can it cover the whole network? Can't someone have their own private relay or npub that only they can see?

Yeah, of course, but they at least attempt to get full coverage. You make a good point, private indexing/search is useful and can't be accomplished by big providers

What if we specify as an open standard (in protocol) a client proxy service, such that nothing about it ever ties a client to a particular one. All they do is offload the fetching work. If you suspect they aren't serving you correctly you point your client to a different one. As long as there is no friction involved in switching away from a proxy that is censoring, I don't think there would be a drive for them to aggregate into a single service. You wouldn't be switching apps, you'd be pointing your app elsewhere.

I'm not suggesting aggregating everything, just doing the fetching on behalf of the clients and using the local cache to assist if possible.

Also of course the caching proxy would be doing the outbox model.

the caching services already have kinds so you can consider them specs, but then every app wanting to have an edge will keep creating more RPC methods to satisfy their UI, it is impossible to make a spec for this that has any chance of ossification.

search is impossible to decentralize, and that is what all popular Nostr apps will become, frontend to search engines.

switching apps is the best we can ever do and that is great, because we don't even have that now with current social media.

if you ignore social media and focus on usecases that are much less expensive to crawl on your own at edge devices, things get much brighter, so I think people should focus on small worlds if they need the absolute most censorship resistance.

good thing is, small worlds are better anyways.

I've thought about something similar, but not just for data fetching, it would be like some custom servers that would massage the data for you and just serve you a feed, in a very centralizing manner, but then what are the incentives for someone to do that for free without being evil and at the same time deviating from the protocol and implementing new things so users can't switch easily? Maybe it will work, but it's probably a slippery slope.

No. We integrate nostr relays into our home routers. It is the one, always online, device that nearly everyone has.

Like we did with Lightning nodes? No, it will not work. This has been the daydream of technologists since when NAT was invented and they realized the internet was not as decentralized as they thought. Look at the amazing number of "self-hosted" collections of software and guides that exist and have existed for decades, and yet only 12 guys do it. I think it's good that we can do it and I hope more people start doing it, but running servers is too complicated, even for me, and the goal of Nostr was to make a thing that would work without requiring people to run servers.

you need to do some work with wireguard tunnels, then you'll see that while it can't be perfectly decentralised it can still be greatly distributed

i'm using this tech on a daily basis and if you use an outbox client you will literally send your reply to this message to my relay via my reverse proxy and wireguard tunnel

it's really not complicated, i'm running a git host on my mini pc using a cheap VPS that cost me 35 euros for a whole year with a reverse proxy that i modded to do nip-05 and it routes inbound traffic to domains and subdomains to endpoints on a wireguard subnet

it only takes me about an hour to set this up manually and i can imagine writing tools that automate it and then add a shopfront and account management interface for the service provider and integrate a wireguard client into your client interfacing, with a handy simple installer that just makes it work and all you have to do is direct it to your host with your npub and voila

and yes, the point is that because the asshats at the IETF etc and all the big telcos who want to do their service as faux internet providers for the Con don't want people hosting their own services they have been marketing this snake oil for decades and never do anything about it

but wireguard+dns+reverse proxy does all of that and the centralisation is only small compared to facebook or twatter

I think once we define what we target, the controversies will be much less. Are we targeting broadband or mobile data? I think a lot of people won't like it when they see big mobile data usage, result of the design choice of no incoming cache. Nostr is primarily for censorship resistance. Censored countries are generally poor. Poor countries won't have enough mobile data.

Censored countries are generally poor? We're talking about the United States of America.

But your message is weird. You think we should target poor people with cheap phones and bad internet that are suffering censorship but you also assume the outbox model uses a lot of data (when in fact you have probably never used an outbox-powered client?) and then your (implied) proposed solution is to centralize everything and reintroduce censorship? What is the point then?

Let me know if I understood you incorrectly or what are your real disagreements with my note above.

badoom TISH

i think availability of proxy tools and services are good for poorer countries and it is not a big deal as a threat to centralization. poorer ones need to hear more about the freedom ideas is what i meant.. there are levels of censorship and USA is still doing a lot better than the rest of the world. a proxy would allow a lot more people to hear the ideas generated on nostr without ruining their data and battery.

i don't propose centralization, how do you come up with that?.

regarding censorship i may do some cleaning of my relays to remove ugly content. however i am not against free speech (of ideas). ugly content is what i think is ugly, like the worst nsfw you can imagine, meaningless spam, ... i am free to specialize in moderation and every op should specialize imo. and thats a good thing.

i think you have too much worries. you made this thing and now worried that it will fail. however i can assure you i am not a bad actor in this. you are looking at wrong places for enemy. i have been providing some relays for months. a lot of relay ops do much more than me (time wise). you should thank us. i am hurt by some of your exchanges.

i get you... proxying is a big deal, and avoiding sending messages repeatedly is a benefit...

logistically, what i see happening is where you have local caches and these let you fetch events efficiently, and when you send requests to them, they do the legwork and catch the data and then anyone else in your area using the cache also can see it without any further traffic and with one fell swoop

it's gonna take time to nut out the details of how to do these things but for sure my research on my local caching suggests so far that you can also cache the media, the media could be compressed further, if need be, where such compression is not damaging to the value of the data (eg, shrinking image sizes)

Sorry, I don't think you're an enemy, I'm very grateful for your services. I was just answering in an aggressive tone, as I often do, but shouldn't.

this is true and inevitable

nostr:note1hpug30zkz2j43eh5yvg389v4m60y4jq8nt43zytqeantp2q0rkpq790wvs

https://files.catbox.moe/gxr96x.webp

Title: "The Rise of the Great Nostr Censor"

Description: A dystopian future vision where a single central service dominates Nostr, controlling feeds and serving ads to users, with power to censor or shadowban those who don't pay. Users are left with little choice but to accept the rules set by the powerful entity.

recommended reading

nostr:note1vgjc0e7fe9x7k4nwc5kzykhl3x8mn42kf372qvlkszy80qxvnuvqcy37xc