I think any opportunity to leave flexibility in the system should be considered. There are a LOT of varied use cases and it seems in the spirit of ILP to keep things pretty agnostic (Don’t enforce unnecessary standards) and flexible.
Whichever has the best documentation right now? I imagine there could be a whole section of finalized documentation thats eventually developed that will show the developer various possibilities and a few snippets so they can choose which works best for them.
I think about this a lot. Today’s average user (Outside of Cryptoland) is incapable of grasping the importance of key management. Even as a knowledgeable developer, I was complacent enough to become compromised and only gave the task of key management the attention it deserves after the breach. However, some users will have the desire to both assume complete responsibility for their keys AND they want to use an intuitive and simple app to accomplish this task. We have a lot of work to do, but that is our goal with Harbor. We want to enable the average human to responsibly manage their own accounts without relying on a third party for security of funds or the transaction. There are always going to be individuals that want to “Be their own bank”. That pool of individuals will grow if we continue to have world events that cause mass distrust of financial institutions by the general public.
For receive only, this seems to be about as simple and cheap as it can get. It also seems like you could have the inverse built and added to the same so it settle bidirectionally.
Finally, this seems like it would be the obvious implementation to use if you were building for an online merchant. Since there is a declared price the merchant wants to receive for their item, the settlement amount could be dynamically set to the item total. Buyer streams money into the recipients desired currency and a single TX settles to the merchant.
Some companies may not be able to afford the licensing to operate hosted wallets.
Working on it! 