Subnostr

problem exists between wall and keyboard

Replying to

````

$ nak req -k 30040 -a fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1 nfdb.noswhere.com -auth

$ connecting to nfdb.noswhere.com... ok.

$ nak req -k 30040 -a fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1 nfdb.noswhere.com -auth

$ connecting to nfdb.noswhere.com... failed to connect: error opening websocket to 'wss://nfdb.noswhere.com': failed to dial: dial tcp: lookup nfdb.noswhere.com on 192.168.2.1:53: no such host

failed to connect to any of the given relays.

````

There should be some 30040s on there, someplace. 🤔

DNS failure?!

Replying to

Oh, wait, that's NFDB, not realy.

The current server had a misconfiguration and it ran out of open files for sockets

🙃

wss://nfdb.noswhere.com has been moved to a better server

test

Replying to

kidwarp

Unfortunately it definitely does

and arguably it is the simplest and best form of async communication there is

e-mail just works nostr:note1mnkulpla59ggg6k7fgnvkd6mkachw6jz4sfpd2qkzg0xty74p9zqrgu7dk

Replying to

i can see how that would be a plus... i have pondered a lot the idea of making relays able to use othre relays as second level stores, i already wrote the code so that whatever comes back from the layer2 is cached and is found faster from the relay event store

I will check out realy, at least for replacing parts of go-nostr and khatru as I don’t really like it

NFDB is just an event store, the extensibility part is for modifying the query pipeline and indexing

the indexes use a fully pluggable provider, and it is really easy to change things, such as to add search indexes

Replying to

so, you are aiming for low latency and availability

these are not metrics that have a big factor of the relay's code quality in them, more about the quality of servers you are running on

as for extensibility

lol, you will extend realy in a matter of days and even less if you already have Go experience

i don't shit on the popular languages for nothing, they are all hard to learn, complicated, cost a lot in development and are slow in the test cycle

the underlying DB matters too, in this case, it uses an external K/V DB that handles scaling, and can distribute load to multiple servers instead of one disk

which allows scaling way higher than 1 server’s disk or CPU

the amount of latency added is negligible compared to a local DB

Replying to

have you actually used realy yet?

it seems to be running flawlessly on 1 core 1gb memory no swap, though my deployment has 2gb and 2 cores now, the times i have looked at what it actually uses it's really doing well considering i have several other services on the machine

no.

the type of deployment I’m intending needs geographical distribution, a lot of extensibility, and fault tolerance

Replying to

my relay runs on a 2 vCPU, 2gb ram VPS in bulgaria with 4gb of swap configured just to stop it blowing up and having to restart, although i've never seen it blow out the memory so far (not been monitoring it that close either tho)

i think you should definitely compare the resources in the deployments, if they are using a lot more memory and storage then of course they are going to have lower latency

it is tradeoffs all the way down.

it uses more resources as a baseline, yes, but it becomes more efficient than other relay implementations at scale.

Replying to

NabismoPrime

What's scalable about it? Is there a public repo to explore?

For relay scaling, spin up more servers, done.

The DB handles scaling: and it is effortless (you just install the DB + set the config)

Replying to

No stress.

You can also do local benchmarks to compare software performance.

Replying to

ben

what’s NFDB?

custom relay database for use in my own relays.

it:

- has a significantly improved query planner and executor

- has better indexes (with composite index support)

- is very extensible (adding search took a few minutes)

- supports creating relay partitions easily

- uses a proven DB to handle scaling + mirrors

written in Go

currently closed source due to commercial reasons

Replying to

I'm going to write a paper comparing the various relays (speed, stability, etc.) and trying to setup similar conditions from different geographic locations and so on.

That won't be for a month or more, tho. Just wanted to get you some quick feedback and a reference.

Well, then wait for the deployment of this with geographical distribution :)

Replying to

I published in series, not in parallel.

that and your CLI client being slow means that this benchmark will have a lot of variance, and is primarily impacted by network latency (NFDB is a test relay running in a shitty computer in my homelab)

Replying to

nostr:nprofile1qqs99d9qw67th0wr5xh05de4s9k0wjvnkxudkgptq8yg83vtulad30gpp4mhxue69uhkummn9ekx7mqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq32amnwvaz7tmgd9ehgtnwdaehgu3wd3skueqyluj3x wss://nfdb.noswhere.com was 4:11. Effectively the same as nostr1.com.

That does not seem right

Did you try sending multiple EVENTs in parallel?

Replying to

Xavier Damman

Lightweight? It’s quite heavy when you compare filesize. We need a proper GIFmp4 format to marry the two. Autoplay in loop with easy way to add a text layer.

there is no need to add text

only signaling loopable videos

Replying to

semisol

It is way better than whatever fucked up strfry mess existing paid relays, including ones that have geographical mirrors, use

Yes that applies to nostr.land as well

So much for paid relays, when they are running hacked together meh performance stacks

That is the entire reason this exists

Replying to

Shots fired. 😂