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