gm builders!

I am in the process of deploying an instance of the brand new relay implementation I am working on…

As we speak, it dosn’t store anything… it just relays events and forgets about them instantly. It should evolve quickly and catch up with missing functionalities as time goes by as I am working full time on it.

I will soon need some traffic to stress test it a little. Let’s keep in touch if you’re interested in giving a hand by adding it to your relays list.

Reply to this note

Please Login to reply.

Discussion

Count me in! What language did you write it in?

Elixir, which translates to Erlang…

fuck yeah, low-latency high volume relays seems like the perfect elixir usecase. i’ve seen a few people mentioning relays which broadcast to other relays.. seems like this would be perfect for that?

For now, just following the NIPS and trying to make a normal relay… it’s readonly for now because I simply haven’t focused on storage just yet.

We’ll see what nostr needs, I’m here to help it get up to speed with the crazy adoption happening.

By the way, it’s FOSS, so anybody will eventually be able to spin one up if wanted.

Take risks and make it public for testing.

It is live now, but still need to be minimally tested… and it still doesn’t have a domain name.

By the way guys, looking for a relay implementation name, so suggestions are welcome!

I bought domains at namecheap, there are offers domains less than $2 first year....

blixtr , cause it’s blisteringly fast 😂

very cool, i might take a look. been wanting to dust off my elixir hat 😁

Contributions would be welcome!

It’s teleco level stuff, so I am pretty stoked about it.

*telco

I’ll add the relay.

What’s the idea behind ephemeral events? Just to relay “live” events?

Because I am developing the relay software in two steps…

IMO the most important part is being able to accept events and send them to subscribed clients. Storage can be a completely separate process, and will be developed in a second phase.

But in a nutshell, for now, you’re right. Still could be useful when relays are overloaded… a readonly one could stand up to the pressure as it has way less work to do.

great way to chunk up the work. i think there will also be a use case for blazing fast proxy relays which help sync across slower, beefier relays with more storage

Yeah will most probably make sure storage is optional and can be switched on or off.

or even modular. seems like a good design is to separate storage from relay so operators can choose their own backend

You got it!

Clearly we should queue all events to be inscribed into an ordinal. 😂

(I’m here for the reactions)

lol, you can only see new events on your feed every 10 mins , after a block is mined

Call the setting “low time preference experience”. All fees mandatory 1sat/byte

“bruh, did you see my reply”

“nah fam, fees be crazy, it probably got evicted”

😆

And with the modular approach you can layer in your own mempool mined only by one S9 to ensure the lowest of time preferences.

Makes sense!

Leave the storage abstracted for the relay operator to figure out. Maybe you have an ITL event for a day and just want to stand up a blazing fast Redis relay for the event.