In this transitional world we live in where some clients support the outbox model and some don't, I have come to the following setup:

Kind 10002

- Write to your own Haven outbox relay, and set it up to blast to the 10 most popular public relays.

- Write to and read from a paid relay of your choice. I'll let nostr:npub18kzz4lkdtc5n729kvfunxuz287uvu9f64ywhjz43ra482t2y5sks0mx5sz, nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj, and nostr:npub1h49w8en79xty6j2pwgnpm3znjhyf767jua6xgt3kvyn3w80ms86s2z9kay duke it out for which one you should choose.

- Read from your own WoT relay (set up to aggregate notes from your WoT) and your Haven inbox relay.

Kind 3 - For those clients that support using it to supplement your inbox/outbox setup.

- Read from a couple other WoT relays and aggregators that might fill in some gaps missing in your inbox relays.

- Write to... nothing additional should be needed. Your outbox relays should suffice.

If you don't have your own Haven relay, then some adjustments need to be made. But Haven really is helpful to have. THANK YOU nostr:npub1utx00neqgqln72j22kej3ux7803c2k986henvvha4thuwfkper4s7r50e8 and nostr:npub1a6we08n7zsv2na689whc9hykpq4q6sj3kaauk9c2dm8vj0adlajq7w0tyc!

Reply to this note

Please Login to reply.

Discussion

Solid advice.

Notice also, this means a final relay count of 4 relays in your 10002 and maybe 5 in your kind 3. All other relay lists should be even shorter. 1 or 2 in your DM inbox list (10050); 1 or 2 in your private relay list (10013); And 3 or 4 in your search relays (10007).

Blocked relays will start becoming important when more clients start using the outbox model. When you start seeing spam on certain relays consistently, you will be able to block clients from pulling notes from those relays. nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn, does Coracle already support this?

The number of kind 10002s and kind 3s I have seen recently with 20+ relays listed is just ridiculous...

No, I kind of got stuck building a relay management client

Hmmm. All said and done, it is more necessary to have a relay management/moderation tool than to be able to block particular relays at this time.

Yeah, I agree. Too much to do!

Doing the triage to decide what to work on now vs what can wait is nearly as important as the work itself.

I prefer to thrash wildly about from one project to another

Currently installing my muirgein bot on a spare computer for demo purposes

😂

Thank you. I am dizzy already. We should not expect end users to go through all this.

Agreed. Not sure what the solution is, though.

The freedom to choose which relays you use is a fundamental principle that we should not abandon, though. Moreover, the outbox model is needed to allow relay selection to remain decentralized.

That means clients are going need to have sensible defaults for new users who don't yet have any relays listed in a kind 10002 or kind 3, so that there is little pain felt immediately upon joining.

We are going to need to have better options for those who want to run their own personal relays, too. Haven is great, but it requires someone technically inclined to run it. We need something like Haven that is click to download, double click to install, and has a GUI for setup and management, and no messing around with setting up a reverse proxy if we expect average users to take advantage of it.

On top of this, we need tools for users to find relays they might want to use that spell out, in plain language, why they would add them to one relay list and not to another.

There are known patterns to be followed: convention over configuration, making the simple easy and the complex possible, etc. It's not rocket science.

For most clients at least. Then there will be more extreme approaches like Primal (can't configure) and others that require you to input everything.

Amethyst relay config is too confusing as it is. We need to be able to pull these configs from somewhere (vendors, paid relays, help sites), whether that's a nostr event or not.

The answer is obviously nostr.land. :)

While nostr:npub1hu47u55pzjw8cdg0t5f2uvh4znrcvnl3pqz3st6p0pfcctzzzqrsplc46u has their own software that’s it. It runs on MongoDB which is known to be very slow, and they have no value proposition except paid relay.

Wine is a set of duct taped relays running on strfry, and you’d need 4 relay connections to only somewhat replicate the functionality of Nostr.land.

And Nostr.land offers convenient import/export and runs NFDB.

Consider that we are open source as well.

How people can confirm your NFDB thing is really faster?

Open Source code + fully detailed benchmark is needed.

Import and export is also supported in Immortal software and will be running on next version.

Speed matters when user feels it!

You need to satisfy user, not fight with milliseconds on low level codes to show off for marketing.

Also, Manageability and Scalability is important. How much you can scale? Is your software able to scale at all? Sorry I don't know since it's closed source.

And the last thing, nostr:nprofile1qqsrmpp2lmx4u2fl9zmxy7fnwp9rlwxwz5a2j8tep2c376n494z2gtgpzamhxue69uhkxun9v968ytnwdaehgu3wwa5kuegpzpmhxue69uhkummnw3ezuamfdejsz9nhwden5te0d9hxymmc9ehx7um5wgh8w6twv5hveph4's nostr wine service is well documented and super reliable. They are also super professional with users and everyone. Which convinced me to subscribe to their relay even when I had Jellyfish up and running.

Don’t waste your time with semisol. The only way he knows how to market anything he builds is by criticizing others. It’s pretty transparent and most people know it at this point.

Keep building - the rest of us appreciate you.

I have shipped *a lot* of features over the last few months to Nostr.land, while many other paid relays are stagnant.

I am comparing relays based off of my experience operating strfry at scale, and other applications that I managed myself using MongoDB. Compared to current NFDB, it is simply not possible to get the same performance or flexibility with other solutions.

I am trying out nostr.land for a few days. Let's see if my overall nostr experience improves, that's all I care about.

Did you try the import/export feature btw?

Also, you need wss://aggr.nostr.land for the aggregator, not just wss://nostr.land. There will be an option to use just 1 connection for all, but that is for later

1 connection for all is the way.

I added aggr to General Relays in Amethyst, is that correct?

Yes

No, what is it?

go to the manage tab on nostr.land

it imports and exports events from the relay

So you can move your events from other relays easily and export them to a JSON file as well.

Oh, I thought I'm looking that realized this. Thanks a lot, and same. Onward. 🫡

“How much you can scale? Is your software able to scale at all?” Currently to about 50x of the current state of Nostr, without any changes.

> Speed matters when user feels it!

> You need to satisfy user, not fight with milliseconds on low level codes to show off for marketing.

Sure, until you realize that when your relay is used at larger scale for a few years, then it crumbles. I have ran MongoDB in several production applications and it has always underperformed by an order of magnitude or more compared to Postgres and FDB *on the same hardware*.

Request latencies reached hundreds of ms at times. So yes, the user will notice.

> How people can confirm your NFDB thing is really faster?

I will be publishing a benchmark when I have finished more important priorities.

> Also, Manageability and Scalability is important. How much you can scale? Is your software able to scale at all?

More details on this, NFDB is built on FoundationDB. It can scale to 100TB+ clusters easily, and certain parts of NFDB could be modified if higher was really needed.

The broadcast system runs on Apache Pulsar.