I think all those options sound good. We could support coins via a plugin API; we'd define a plugin that communicates with *coind's raw transactions API via RPC. A user who doesn't want the disadvantages of option 2 can switch to option 1 for one or more coins by running their own local *coinds.
Besides extensibility in supported coins (which is important since new coins can arise quickly), a plugin architecture allows for multiple backends for a particular coin, i.e. local bitcoind/SPV/electrum depending on the user's security/resource usage tradeoff.
Besides extensibility in supported coins (which is important since new coins can arise quickly), a plugin architecture allows for multiple backends for a particular coin, i.e. local bitcoind/SPV/electrum depending on the user's security/resource usage tradeoff.
Yes, this is a great idea. Plugins would be made by me/us/Uniwallet devs at first, but preferably by the *coins distributors/creators after Uniwallet gains popularity. Making plugins should be simple enough that anybody with a little knowledge can do it.
I'll be back January 2,
Happy new year!
