Nostr Web Client

nostr:nprofile1qqspw5udc2nzw6wsj3plrrphe0343744h0ucz9e4g248chl3w8kh03qj3du26 you might be interested, this is an interoperability issue at the boundary of clients and relays

elsat 7mo ago

https://github.com/nostrability/nostrability/issues/204

I don’t even know where to start this one 😅

Luxas 7mo ago

You can use the free “blaster” relay from Nosflare with wss://sendit.nosflare.com and it’ll try as many relays as possible within 30sec

franzap 7mo ago

Thanks! Yes, one piece of the puzzle. I wish we could have smarter ways of broadcasting.

Luxas 7mo ago

This is probably one of the best ways, at least for broadcasting. And easiest for a relay operator. The inverse would be more difficult, for the singular relay, at least when it comes to storage space and costs and resources if they’re constantly mirroring events in near real-time from as many other relays as possible. But it is something that I’ve been working on for over a year. The current public Unostr project is sort of broken, but have a new project “black hole” iteration I’ve been tinkering on for Nosflare.

https://github.com/Spl0itable/unostr/

Walt Munny 7mo ago

Interested. I am looking for exactly the same thing.

Derek Ross 7mo ago

The problem with Nostr in a nutshell. No one is going to do this unless they're already here because they love the tech, are an early adopter, or love the revolution.

franzap 7mo ago

I love the tech, am an early adopter and love the revolution *and* still find this whole thing a pain in the ass.

kidwarp 7mo ago

Agreed

کیهان 7mo ago

Jellyfish 🪼 and a couple of public relays.

franzap 7mo ago

I don't understand Jellyfish - how does it compare to nostr.wine? Including filter.nostr.wine and inbox.nostr.wine

I don't care about nip05

کیهان 7mo ago

It's a paid relay service focused on reliability, maximum NIPs support, management and control (users must be able to own their data and operator must take care of reports and etc), which is fully respect NIP-09, 62 and 70.

Beside being paid its WoT protected which means everyone can't join and they need some minimum of WoT rank.

In the future weighed rate limit based on WoT rank will be applied as well.

Rest of features and updates will be done over time based on our plans and users feedback.

We don't broadcast or aggregate since it takes the control away from user. What they want to see or where they want to publish their event.

We have a lot of features WIP, but it's a little delayed since we have other projects coming soon as well. Also we still didn't gained that much user so we don't have enough support and feedback.

franzap 7mo ago

Got it, thanks. It's not for me then - I'm looking for an aggregator. See my original post.

کیهان 7mo ago

Got it, so yes you need to use aggregating services specifically. 🫡

Filou 7mo ago

I’m using nostr.land from nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj

franzap 7mo ago

Thank you. nostr:nprofile1qyghwumn8ghj7mn0wd68ytnvv9hxgtcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszxthwden5te0wfjkccte9ehx7umhdpjhyefwvdhk6tcpzemhxue69uhkzem8wghxummnw3ezumrpdejz7qgwwaehxw309ahx7uewd3hkctcqypftfgrkhjammsap4marwdvpdnm5nya3hrdjq2cpezputzl8ltvt63qxz26 is your service a good alternative to nostr.wine? What clients are known to work with it?

Silberengel 7mo ago

Anything from nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj nostr:npub18kzz4lkdtc5n729kvfunxuz287uvu9f64ywhjz43ra482t2y5sks0mx5sz or nostr:npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h will work. I use all three and those are, hands-down, the best relay admins Nostr has.

franzap 7mo ago

I have no doubt nostr:nprofile1qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzamhxue69uhkjmnzdauzumn0wd68ytnhd9hx2tcprpmhxue69uhkxetvd3shytnwdaehgu3wwa5kuef0qyv8wumn8ghj7cmjv4shgu3wdehhxarj9emkjmn99uq3samnwvaz7tmxd9k8getj9ehx7um5wgh8w6twv5hsqgpass40an279ylj3dnz0yehqj3lhr8p2w4fr4us4vgldf6j639y95ydrqn8 is a fantastic admin but his stuff does not work with my clients

Silberengel 7mo ago

Why in the world do you assume it's the relays?

Niel Liesmons 7mo ago

:110percent:

franzap 7mo ago

I did not say that

Mazin 7mo ago

Thank you for this. Much appreciated.

Anthony Accioly 7mo ago

My two cents here as user looking for a good relay combo in the past (not going to repeat what others have already said or mention Haven as this isn't about self-promotion, but I'm very happy that folks are enjoying and recommending it above).

Credit where it's due: theforest.nostr1.com has served (and is still serving) me very well. For a relay with a symbolic join fee, it's brilliant. I unfortunately have to deal with enthusiastic script kiddies spamming me on a regular basis for... reasons... 🤷‍♂️🤣... Anyway, TheForest1 has never sent any spam my way, and its reliability has been pretty solid.

Thanks for providing this service to the community. I don't know how much active moderation you folks are doing, and I assume it’s costing you both time and money to keep it running so smoothly, but it’s been working well for me.

While I’ve recently signed up to nostr.land (already regretting it a bit, not because of any technical issues, but given the lead dev’s attitude above), IMO theforest.nostr1.com is a great place for new users to experiment with their first “paid” relay (shout out to nostr:nprofile1qqs8eseg5zxak2hal8umuaa7laxgxjyll9uhyxp86c522shn9gj8crspzemhxue69uhkyetkduhxummnw3erztnrdakj7qg6waehxw309akx7cmtvfhhstnxd9shg6npvchxxmmd9uq3zamnwvaz7tmwdaehgu3wwa5kuef0rd95a7 for relay.tools).

0xchat relays + auth1 are also both amazing for NIP-17. They are booth good choices for folks who are DMing on Nostr (hey... there are... Dozens of us!) and aren't running a personal relay or paid relays with AUTH support. Of course, those are free public relays, so you can expect some unavailability and occasional spikes in latency, but they’re working quite well.

Silberengel 7mo ago

It does cost us money, but we cover that with the Geyser donations we receive for Alexandria.

I just always look straight at global, and Cloudfodder is extremely attentive, so that works out well. Especially, as we're in opposite time zones.

semisol 7mo ago

Yes.

All clients should work with it. Just remember to enable NIP-42 auth.

semisol 7mo ago

Try it out. If you don’t like it within 14 days then I’ll give you a full refund.

il_lost_ 7mo ago

I don't understand what your problem is?

Silberengel 7mo ago

It's usually the clients, not the relays.

I've tried sending this note from Jumble, Nostrudel, and Coracle. I'm now in Nostter. Next attempt.

Silberengel 7mo ago

Yes! Nostter worked. 😂

Anywho, like I was saying, it's usually not the relays that are messed up.

The majority of the clients can't figure out how to send and receive notes. They can do everything EXCEPT that.

franzap 7mo ago

In my particular case I'm finding the opposite. It's the relay not the clients.

I only changed nostr.wine to nostr.land and everything is working again (in Coracle web, Amethyst Android). So far.

Silberengel 7mo ago

The filter.nostr.wine is not the same thing as nostr.wine.

franzap 7mo ago

I know. I am referring to the service, not the specific URL

idsera 7mo ago

cc nostr:npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl

Silberengel 7mo ago

Coracle should be falling back to compatible read/inbox relays on Kind 10002, if there is no explicit DM inbox available in a kind 10005. I know the NIP says otherwise, but the NIP is retarded.

hodlbod 7mo ago

nostr:nprofile1qyghwumn8ghj7mn0wd68ytnhd9hx2tcprpmhxue69uhkxetvd3shytnwdaehgu3wwa5kuef0qyv8wumn8ghj7cmjv4shgu3wdehhxarj9emkjmn99uq3wamnwvaz7tmfde3x77pwdehhxarj9emkjmn99uq3samnwvaz7tmxd9k8getj9ehx7um5wgh8w6twv5hsqgpass40an279ylj3dnz0yehqj3lhr8p2w4fr4us4vgldf6j639y95kglx9x have you tested coracle and filter.nostr.wine together? From what I can tell it should work fine, but I don't have a subscription. If you want to give me some free time I can look into it.

Mazin 7mo ago

No I haven’t - not in a long time at least. The truth is any client that forces automated outbox relay crawling breaks the value proposition of filter (reading from one high performance relay with spam control).

I’ve added 3 months for you. Let me know if I can help in any way.

Mazin 7mo ago

Also added time for inbox.nostr.wine if needed.

hodlbod 7mo ago

Thanks, just tested the integration. It seems to be working basically correctly, except that inbox is misusing the `auth-required:` prefix to block non-DM filters, even when auth is already successful. Coracle handles it fine, but it may confuse other implementations, `blocked:` is the correct prefix. nostr:nprofile1qyghwumn8ghj7mn0wd68ytnvv9hxgtcqypex583xrnryw3n5aq59uw23kwa38xlf5aeart85nhyx3kuxrgwpzjh056v the reason you might not be seeing inbox connect is coracle requires the user to enable messages to avoid a million signature requests. Try visiting the messages page and see if it connects. nostr:nprofile1qyv8wumn8ghj7cmjv4shgu3wdehhxarj9emkjmn99uq3zamnwvaz7tmwdaehgu3wwa5kuef0qyv8wumn8ghj7enfd36x2u3wdehhxarj9emkjmn99uq3samnwvaz7tmrv4kxcctj9ehx7um5wgh8w6twv5hsz9mhwden5te0d9hxymmc9ehx7um5wgh8w6twv5hsqgpass40an279ylj3dnz0yehqj3lhr8p2w4fr4us4vgldf6j639y954mdm05, I'm also seeing none of my recent messages coming from inbox. I'm not sure if this is intentional adherence to outbox (in which case it's correct), or if your scraper/multiplexer isn't working as intended.

Mazin 7mo ago

I'll update that response prefix for inbox.

I’m not sure I understand the second part. What do you mean your recent messages coming from inbox? filter.nostr.wine is the aggregator/broadcaster, not inbox.

Mazin 7mo ago

Ahhh I see whats happening here. This was updated recently to support multi-auth per connection. If you try to make a REQ that another user could be authorized to make, it will tell you auth-required instead of restricted to give you the opportunity to AUTH again with an additional pubkey.

Does that make sense with what you saw?

hodlbod 7mo ago

Interesting. It does explain what I saw, but I'm not sure it's accurate in this case (because filter will never serve kind 1s). It's also not very helpful, since how can the user know which user they should auth as? It seems like it would be entirely up to the client to choose which keys to use. See this recent PR for how multi-user auth has been proposed: https://github.com/nostr-protocol/nips/pull/1881/files

> I’m not sure I understand the second part. What do you mean your recent messages coming from inbox? filter.nostr.wine is the aggregator/broadcaster, not inbox.

I assumed since I had access to filter I would have access to inbox and it would aggregate DMs? But only old messages are being returned from inbox. That seems potentially correct, I just wasn't sure.

Mazin 7mo ago

Filter does return kind 1s. I assume you mean inbox in which case I’ll take another look at that response.

Inbox does not communicate with the aggregator in any way so it will only have messages from when you previously used it (I think I gave you access back in 2023).

I added multi user auth exclusively as a result of that PR. I don’t understand what is wrong though. The client always chooses which key to auth from, no?

Mazin 7mo ago

Inbox doesn’t explicitly prohibit REQs for kind 1, but they have to supply a relevant tag. It blocks them on write though so they will always return empty.

I will fix this so those return blocked instead.

hodlbod 7mo ago

Yes, I meant inbox, I confused myself. Your explanation makes sense too. On multi-user auth, I guess returning auth-required could makes sense if the alternative would be restricted. I'm just not sure what action the client would take in that case without being very coupled to an interpretation of the relay's policy.

Mazin 7mo ago

I added a new message now for when you try to REQ a kind we do not store on inbox. It should used the “blocked” prefix. Thank you for pointing this out to me.

And yes - I think that is a challenge for sure. I think the main proposal is based on Vitor wanting to have 1 socket connection for multiple logged in accounts on Amethyst. He can AUTH with all of the logged in accounts when they prompt so that he can access privileged events for all those pubkeys. It’s a bit messy on the client side but it was easy to implement on our end so we went ahead and did it. I assume the proposal will change 10 more times in the next year and our implementation will break soon.

hodlbod 7mo ago

I think this stuff is pretty stable. It's the reply stuff that's a disaster area

franzap 7mo ago

Earlier today, filter was not connecting either.

I am trying out nostr.land for a bit. Maybe that sheds some light on all this? I'll report back.

nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgwwaehxw309ahx7uewd3hkctcpr9mhxue69uhkscnj9e3k7unpvdkx2tnnda3kjctv9uqzp978pfzrv6n9xhq5tvenl9e74pklmskh4xw6vxxyp3j8qkke3cezyx6uqg given I *only* have wss://nostr.land (and just checked my 10002 on purplepag.es) why is Coracle broadcasting my latest post to 5 relays (nostr.land, nostr.wine, inbox.nostr.wine, creator.nostr.wine, etc)?

franzap 7mo ago

Appreciate the level of information you put in Details!

However, more puzzling results:

Dikaios1517 7mo ago

Coracle will write replies to the inbox relays of those you have tagged in the reply. nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn is using relay.damus.io, nos.lol, and hbr.coracle.social as inbox relays. nostr:npub18kzz4lkdtc5n729kvfunxuz287uvu9f64ywhjz43ra482t2y5sks0mx5sz is using creatr.nostr.wine, among others.

Silberengel 7mo ago

Yes, this is what is redundant with filter.nostr.wine, as it also does that. It is its own mailbox implementation.

Dikaios1517 7mo ago

Interesting. I knew about its blastr relays, but did not know it also uses NIP-65 for replies to post to the inbox relays of those mentioned.

Is this something we should be expecting relays to handle for us, rather than clients?

franzap 7mo ago

I think our collective paranoia is negatively affecting UX.

As long as these all-in-one relays do not censor it's a superior solution with less waste.

Censorship incentives are low, they can be swapped immediately for a different provider and affect their brand reputation.

Silberengel 7mo ago

Yeah, we have a set of powerful community relays, and clients mostly just mess them up.

And every client is different...

hodlbod 7mo ago

Our collective paranoia is all we really have

atyh 7mo ago

who sent you?

franzap 7mo ago

Some paranoia is helpful, it is also possible to go too far!

hodlbod 7mo ago

Check your "max relays per request" setting. If you are sending/requesting from fewer than than number of relays, coracle will fall back to that number. Coracle wasn't really designed for relay selection tuning, but to "just work" no matter how bad people's configurations were. That could be changed, but it's unclear to me how much it would only work for power users.

sudocarlos 7mo ago

nostr.land and aggr.nostr.land could accomplish what you want. its two relays, not one but yea...

nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj - any plans to integrate aggr into the single relay?

semisol 7mo ago

Yes, I mentioned that last week.

This is only a temporary limitation because this is a beta service.

semisol 7mo ago

Currently trying to fully get the spam filtering down. The benefit over filter.nostr.wine is that it reads from hundreds of free and paid relays, compared to the less than 10 free relays they read from.

Mazin 7mo ago

Reading from relays is the easy part. We’ve experimented with adding 100s of relays to our ingress and all it adds is duplicates.

franzap 7mo ago

Only 10? I forgot this part. Maybe that's why I was often missing events? I don't think you can assert that the other 90+ relays *only* add duplicates

Mazin 7mo ago

It’s over 30, actually, but doesn’t really matter. Of course it is not going to be perfect coverage, even if you add every known online relay because some will rate limit your REQs or reject your filters, some will require AUTH, etc. Our goal is to have very good coverage, not perfect - and we have achieved that for multiple years.

Event propagation on nostr is way more broad than people realize. Most events end up on the top 10 relays within a few minutes of being delivered, even if they are not sent to one of them directly.

franzap 7mo ago

That's fair, I don't have the numbers so I trust you on that.

Since I'm AUTHed and you have my contact list, if people I follow have outbox set up (i.e. their 10002 points to where they write) - do you go fetch notes there? Or not at all?

semisol 7mo ago

AUTH is not transitive and is tied to only one relay, you would need signer connect for that.

franzap 7mo ago

I don't think you understood what I said. Forget AUTH, you know who your customers are. If so, you can fetch their contact lists, so you are able to look at all their contacts' 10002 events and pull from those relays

semisol 7mo ago

Ah. In my case I’m considering directly indexing those relays fully, as it would be more efficient + faster than forwarding REQs based on AUTH

sudocarlos 7mo ago

signer connect is a thing? like ssh-agent forwarding?

semisol 7mo ago

Standard nsecBunker stuff.

Mazin 7mo ago

No - filter only respects NIP-65 for broadcasting, not for reading.

"Your events are automatically broadcasted to your first 4 "write" relays and the first 4 "read" relays from the first 5 tagged users.”

franzap 7mo ago

Got it, that's how it works today. But do you plan to support what I suggest? or why not?

Mazin 7mo ago

We can just ingress from all the online relays if it makes everyone happy - it’s a simple change on our side.

Easier than trying to be precise for no real gain I think.

semisol 7mo ago

Looks like your infrastructure is not built to scale then 🤷

semisol 7mo ago

The Noswhere indexer is currently handling hundreds of open connections with zero issues.

It can very efficiently handle duplicates while still being able to import a lot of events.

semisol 7mo ago

It goes through a custom event processing pipeline and within 1-2 seconds you’ll see it on aggr.nostr.land.

Seconds, not minutes.

With NFDB the query performance is significantly better as well, and allows faster queries on large datasets.

franzap 7mo ago

Is aggr.nostr.land going to be merged into nostr.land or it needs to be configured separately?

semisol 7mo ago

Currently separately. Later on you’ll be able to choose if you want it as 1 relay or 2 relays.

One has the benefit that you have a clear distinction between paid and free content, and the other saves data.

Dikaios1517 7mo ago

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!

Derek Ross 7mo ago

Solid advice.

Dikaios1517 7mo ago

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?

Dikaios1517 7mo ago

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

hodlbod 7mo ago

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

Dikaios1517 7mo ago

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.

hodlbod 7mo ago

Yeah, I agree. Too much to do!

Dikaios1517 7mo ago

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

hodlbod 7mo ago

I prefer to thrash wildly about from one project to another

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

Dikaios1517 7mo ago

😂

franzap 7mo ago

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

Dikaios1517 7mo ago

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.

franzap 7mo ago

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.

semisol 7mo ago

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.

کیهان 7mo ago

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.

Mazin 7mo ago

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.

semisol 7mo ago

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.

franzap 7mo ago

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.

semisol 7mo ago

Did you try the import/export feature btw?

semisol 7mo ago

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

franzap 7mo ago

1 connection for all is the way.

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

semisol 7mo ago

Yes

franzap 7mo ago

No, what is it?

semisol 7mo ago

go to the manage tab on nostr.land

it imports and exports events from the relay

semisol 7mo ago

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

کیهان 7mo ago

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

semisol 7mo ago

“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.

semisol 7mo ago

> 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.

Reply to this note

Discussion