what you do is send from that user's address to the receiver's address the value ether.
You can't do that for the same reason I can't instruct my bank to take the payment from your account.
Your questions imply server-centric thinking. I'm not 100% sure what you really need to accomplish with Ethereum, but I'm reasonably confident there's an elegant solution, but first, you need to reconsider some assumptions about the process, flows and the roles of client, server and contract.
If I understand correctly, you want:
- Alice chooses "a Bob" and sends funds from Alice's own account.
- There are thousands of Alice's i.e. many users.
Fair enough. There is nothing for the server to do to help this transaction along.
- Alice must sign all transactions from Alice, which should be fine because Alice needs to choose Bob.
- The funds will flow from Alice's account to Bob's account via the blockchain. There is no role for a centralized server in this arrangement.
How does Alice piece the transaction together? A user interface can help with that. Perhaps Alice chooses Bob once and then this is a default for future transactions? Perhaps Alice has a contact list? Those are UI concerns and a server can provide the browser with a fully formed transaction ready for her signature.
Wait. What if the server needs to run everything in a batch process? Given that the server cannot spend Alice's money, the solution is for Alice to send her money to the server, or to a contract under the server's control.
For example, suppose Alice wants the server to handle weekly payments of something for the next three months. She'll have to transfer funds to an account the server can use for this purpose. The payments will always be from the server, signed by the server.
Commonly, one would want the blockchain to record that the payment was on behalf of Alice. That sort of thing is an "argument" in the context of a transaction signed by the server. A contract can immortalize exactly what arguments are needed, exactly who/what is allowed to disburse funds. exactly what records are to be kept and can even serve as the trusted escrow account where Alice deposits and withdraws her funds.
a) do you make users type their private key in an input field so that you can sign the transaction?
b) if you let them type the private key in an input field, then it's no safe right? how is the user sure you're not gonna save his private key somewhere?
c) if you don't ask him the private key, how are you going to sign the transaction programatically?
Either the browser sends a transaction signed by the user, or the server sends a transaction signed by the server.
d) if you're using the metamask, it's easy, but let's say we don't use metamask. what are the options?
The Web3 API works with nodeJS. APIs are available for other environments. Deep down, one can use jsonRPC but it's "close to the metal" so not recommended unless you're making a wallet or something and need to get in that close.
Truffle is a favorite tool for high-level abstraction at the smart contract level.
Hope it helps.