Feature: Separate daemon + rocksdb from electrs interface

[caniko]

Is your feature request related to a problem? Please describe.
I am considering forking the repository, but I only need the backend: The bitcoind daemon and rocksdb schema + configuration. electrs is monolithic, it shouldn't be.

Describe the solution you'd like
A package focused entirely on the bitcoind daemon, and its storage. Currently, the only storage option is rocksdb; however, there could be other ones. The new package could be electrs-daemon.

Describe alternatives you've considered
Just forking, and removing the components that I don't need.

Additional context
None.

[antonilol]

+1
related to #765 but that pr in inactive (sent a message a year ago but no development since then there)

rust trait are really good for this, would be cool if you could choose your own storage backend (like started on in the linked pr) and choose the interface (electrum rpc, or something else?)

[caniko]

@antonilol, you could even have no interface, and have your workers open rocksdb directly. RocksDB supports concurrent reads, most on disk KVs do.

This is related in the way that it is a nice way to decouple the two entities/apps. One that deals with keeping an updated database, and the other as the electrum interface.

[romanz]

Concept ACK :)

I'll be happy to help with the design and review of this idea.

[romanz]

(and sorry for the delayed response...)

[Kixunil]

This is somewhat related to my idea of having an alternative chain-storing backend. The backend could maybe store some indices on its own and provide a stable interface to retrieve the data locally and remotely.

electrs itself doesn't do that much on top of storing data so I'm not convinced it's worth splitting up into individual daemons if one of them would be just translating json RPC to something else. It'd make more sense to have it as a crate that people could develop new stuff on top of.