I’ll add the relay.

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

Reply to this note

Please Login to reply.

Discussion

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.