Huh?

nostr.land actually relays

That makes *checks list* ... One. Carry on.

Makes complete sense. Said no one ever.

You might think that relays ought to send notes among themselves, but that is not the case. Nostr relays do not form a network amongst themselves, and behave mostly as a single hop to "relay" notes between two clients. So in order to actually see the notes you want to see, you have to get notes from a lot of different relays. And you, as the client, must be responsible for making sure your recipients' relays have your notes. So with the clients handling the logic of routing notes to their correct destinations, would it not be more prudent to call them the Relays? And with relays dependent on clients to provide their content, are they not, rather, the Clients?

Vitor thought it made sense 🤭

It is the relays responsibility to relay not the clients

Wait there's no goddamn way they made the client figure out where to put notes. The Outbox relays are where you put notes. You have to be wrong. If not, what the fuck are Amethyst and nostr devs even doing?! An aggregator/proxy relay can be added to make the client more efficient as regards fetching notes. If I am not mistaken, the aggregator itself requests notes and makes copies of them. Relay to relay. I use one. The aggregators can themselves use the Outbox model to ensure it fetches all the right notes. And I thought they used published Outboxes in Outbox model, on a nostr event that describes your Outboxes, not info from the client.

What we should be doing is having blaster relays that shoot their shit to other relays according to an Inbox model in addition to this.

huhhhhhhh

Is there a diagram of how this works…because I can’t even visualize it.

It's my understanding, and I could be wrong, that you put notes in your Outbox relays. But when you reply to someone's note, it makes sense to also send those replies to the mentioned users' Inbox relays. And when you want a user's notes, you get them from that user's Outbox relays. I think that's what Amethyst does now. And now I'm all thought up in knots, and I'm going to take a break.

🤣🤣🤣🤣 it is really complex :turtlehappy:

So Outbox is basically a mobile data plan disaster?

That and inefficient media, especially with Blossom, yes.

The power comes from the fact that you can switch away from Nostr.land if we abuse your trust to an alternative provider or back to outbox. But you won't need to.

so Primal is the right one?

I don’t think that’s the lesson being taught here.

they mean as in position

🤣

The terms you’re looking for are Blasting and Importing. This isn’t a new idea, and plenty of Nostr relays already do this. Haven, which represents more than 10% of Nostr relays (if you trust nostr.watch stats), has supported Blastr and Import since the very beginning. And it wasn’t the first relay software to do so. Also, there are zero expectations that all relays should do this. Relays talking to other relays is extra functionality beyond their core role. It wouldn’t even make sense for all relays to act as aggregators and broadcasters to every other relay. Having thousands of relays syncing every note among themselves would be a huge anti-pattern in distributed systems and would ultimately make self-hosting impossible without datacentre-level infrastructure. There is no Global, and there shouldn’t be one. The Outbox model has its issues, but it’s a better way forward than relying on the handful of central relays & aggregators we had before. It makes Nostr much more resilient. So, to put it in your language: relays are relaying just fine, and they should keep relaying exactly as they are.

X There is no global. But there are local subgraphs you can find. And I do believe relays are the place to do that.

Gorillas are mammals, but not all mammals are gorillas. You can cluster local subgraphs with Import, Blaster, Negentropy, etc. You can also have large aggregators and broadcasters, like what @semisol is building, which can provide something close to a “global” without much spam and at a fair price. This doesn’t mean every relay should do this. In fact, the purpose of many relays is exactly the opposite: to accept, store, and serve only a very specific set of notes, for example from a community or even a single pubkey. Such relays can easily run on a Raspberry Pi or a cheap VPS. Nostr is flexible enough to accommodate both extremes, and it should remain that way.

Have you considered the idea of "small aggregators" though? I think that's the main problem here. No one has really done what I would consider a true personal relay. A kind of scavenger that will maintain the subgraph surrounding the user. The challenge being to calculate the bounds of that subgraph.

yes, that's how it works. relays only relay to clients that ask for it, and they can only relay what they have... if you follow someone, you cannot expect that person to write to your set of relays, right? that would be a dumb assumption, so your client is smart and so it knows where your follows post and fetches from there, otherwise you would not see posts you want. why do people expect to find other people's posts on their relays? this comes from a misunderstanding of how nostr works. Also, if you want certain people to read your notes, then you should post to the relays they read their notifications from in addition to your own write relays. This is not rocket science, it's simple logic.

It can certainly be done. Haven already does this for a specific pubkey: it imports, stores, and serves all notes written by the relay owner or in which the relay owner were tagged by someone in their web of trust. It works by subscribing to a configurable list of other relays, much like a client would. In V2, it will also gain the ability to whitelist and import notes from more than one pubkey. A relay could also try to fetch all notes from your followers. It can even use the Outbox model to figure out where to download notes from. In fact, this is a feature that has been requested for Haven itself. I’m not sure if any specific relays already implement it, but I think @Laeserin 🇻🇦 once mentioned she had a way to do this for specific npubs and therefore didn’t need client-side follow lists (was it with Citrine?). The same caveats described above still apply, though. My Haven database export plus Blossom data is several gigabytes. Even with CDNs and heavy caching in the middle, Nostr + Blossom is often enough to saturate my link. I certainly wouldn’t be able to run this from a mobile relay. So, basically, you need to “connect the edges” of the social graph through relays carefully, consciously of the tradeoffs.

For one user like you or me, and say 500 npubs they follow, how big does that event store get if you were to store just the events from all those npubs? And that's not even counting blossom server files/image caching. What do you think is the ceiling for how many users' notes can fit on a relay running on a raspberry pi? Before you need to start looking at bigger hardware.

I honestly don’t know. User activity levels vary substantially, there are different kinds of notes beyond just short and long text, and a single black swan event such as “Reply Guy” or even a misbehaving client can drastically change the outcome. Maybe folks running WoT relays, such as Utxo and @Girino Vey! can give you a better idea.

the tone of the note suggests it's a bad thing?

also I'd DHTed nostr

Just that the names for entities in the Nostr network don't seem accurate. And that I think I'd benefit from a different kind of architecture for my personal use.

oh, ok. that makes sense

So does TheForest 🌲 .

Does it properly spam-filter while having access to data from hundreds of relays and tens of thousands of npubs, while providing everything in 1 connection?

But relaying isn't always desirable, like with private relays. You don't want it broadcasting the stuff you post to it.

It's subscriber-only and bidirectional streams to aggregators. Different model. It is also just a really attractive relay to sync with, due to the high signal, so lots of relays pull from it.

So it’s a glorified list. And also most of what you are seeing is likely Primal’s 20 connections to each relay it sees.

When NFDB TheForest 🌲 ?

Good question watch the nostr.land NIP-11 document carefully

For a single user, you can store all your notes on a Raspberry Pi. For 500 users, storage needs remain modest, around 2 GB per year. The main limitation of a Raspberry Pi is disk performance. High loads often occur due to I/O wait times. To achieve reliable performance, use a Raspberry Pi 5 with a PCIe NVMe adapter and NVMe drive. With a 100 GB NVMe disk, you could realistically run a full public relay.

Thank you! That's really useful info.