Events caching Spec?

[securitybrahh]

I have seen relays going on their own making caches and relay aggregators, but no mention of these things in the NIP's?

Prob for the best cause, as keeping the spec simple is best.

But I think, as a starter we should have a field that says cache/priority in NIP-1 itself. {veryLow, low, medium, high, veryHigh - some numbers idk}

Because when the network grows, the relays have to decide which events to let go, now it just decides on timestamp, i suppose.

But what about pinned content?

Also in this way, clients will have some order in which they fetch from a profile/identity.

In the enire spec atleast I haven't found any mention of persistence of events, which maybe out of design but idk.

[luigi1256]

The Pinned notes are in NIP-51 for note kind 1.

Because when the network grows, relays have to decide which events to let through; now, I guess, they decide only based on the timestamp.

A relay network is not necessarily growing, new people bring new relays
one idea could be this
you can timestamp the note, NIP-3 and you can download a backup of your notes, and you can have a mechanism to tell if your note is still online fine and if it doesn't find it republish

[melvincarvalho]

new people bring new relays

Side note: Not totally sure this holds up. From what I’ve seen, as more people join, the relay network actually shrinks—not expands. More users mean more load, and then relays quietly disappear. So if anything, more users bring harder times for relays.

[staab]

Caches/aggregators are inherently centralizing. It's fine if people want to build them for bootstrapping or for efficiency, but they're not part of the spec because nostr has to work without them. The best version of such a thing would be an indexer that explicitly doesn't provide any content, but is basically a key/value map of pubkey to kind 10002 so that clients can then find relay selections. But that already exists — it's just a relay. The main problem with this currently is that everyone just hard-codes purplepag.es or relay.nostr.band when looking for relay selections. A user preference stored in the signer or nip 05 provider for bootstrapping indexers would be a slight improvement, but hardcoding multiple indexer relays is more robust and pretty much just as good (as long as all the indexers aren't lying, and the user doesn't need some special indexer that has access to non-public profiles or something).

[luigi1256]

Not totally sure this holds up. From what I’ve seen, as more people join, the relay network actually shrinks—not expands.

thank goodness users are not increasing, when did you register this fact? Because in six months there has been no increase.

[melvincarvalho]

Caches/aggregators are inherently centralizing

Not wishing to be contrary, but I think this assumption needs to be examined more closely. The inverse might actually be true. Without caching, we don’t get decentralization—we get concentration.

Right now, the alternative to caching is everyone querying the same handful of big relays, which is exactly what we see happening today. Caching reduces the burden on relays, spreads requests across the network, and allows smaller relays to be more viable—which is what decentralization actually looks like.

If anything, resisting caching may lead to more centralization, not less.

[staab]

It depends on what you mean by caching, I agree with what you're saying. Replicating based on social graph or the role of a relay in supporting a community, topic, feed, whatever, is a type of caching. I'm specifically referring to aggregators/indexers which attempt to provide a "global view" of the entire network.

[securitybrahh]

https://github.com/nostr-protocol/nips/blob/master/11.md#event-retention

eg NIP-51,33 - example of kinds retained