Yup, it's run by one of the  Monero developers. I also heard (but can't verify) that only you can access your funds when you use them.

I may have stumbled across that guys reddit post. When I made my first transaction this morning and my balance went to zero and almost broke something beautiful. Couple that with taking FOR-fucking-ever to confirm...30 confirmations are a drag. I'm synching my own wallet now, also taking forever.

A bit over 7k xmr, worth about ninety three thousand dollars at the time of theft.
Your humble correspondent is bloodied but unbowed, as the expression goes.
Been using command line daemon and wallet on linux ever since.
At least one other person lost a significant amount, but I don't remember how much.
Fluffy would have done well to require 2FA on that site, instead he had a laser focus on being user friendly to promote monero use and make it easy for newbs to get in... well, newbs make mistakes.  Mistakes like using Fluffy's web wallet.

XMR had huge volume over 100000 BTC in last ATH, but Dash has less, maybe more small investors have Dash, so they can pump so high, if whales have many Dash, they will dump crazily to cash out.

Nah, I warned all the cloak holders what he was going to do to them and they followed him to the slaughter anyway. I watched it all and that community was just too low brow for my taste, but thx. Toss the link to your new thread and I'll lurk it but I can't conceive of any way I'd get involved.

Edit: I see the links in your sig, subbed.

You must have many small chunks of XMR if you want to send small amounts.
Else, if you have, say, chunks of 50 or 100 the mixin will select them and then you must wait for the balance to mature (become spendable) again.
It's not a bug.

It isn't working properly and will be adjusted to address this. A quick fix will come with the upcoming hardfork (April 15 most likely) where the minimum blocksize limit will be raised to 300 kB as far as I know. In addition, see:

https://github.com/JollyMort/monero-research/blob/master/Monero%20Dynamic%20Block%20Size%20and%20Dynamic%20Minimum%20Fee/Monero%20Dynamic%20Block%20Size%20and%20Dynamic%20Minimum%20Fee%20-%20DRAFT.md

https://www.reddit.com/r/Monero/comments/5zoadt/new_fork_around_april_15th_fixes_high_fees_and/

This issue is the ratio of the min RingCT tx size ~13000 bytes to the min effective blocksize 60000 bytes. This forces a very high penalty for an additional tx and causes the backlog. The hardfork addresses this  by increasing the min blocksize to 300000 bytes which will allow a RingCT tx ~13000 bytes to pay its penalty if the tx is added at just over the new 300000 byte min effective blocksize  provided this tx uses the new 4x default fee or a higher fee. The new default fee at 4x when the median blocksize is below 300000 bytes is 80% of the old default fee at 1x when the median blocksize was below 60000 bytes. This should allow for smooth blocksize scaling for txs that pay the default or higher fee.

The result is that a tx paying the default fee (4x) should under normal circumstances have no problems getting mined. There is a now a cheaper option (1x) where in exchange for the lower fee the sender accepts the risk of delay and under certain rare circumstances the possibility it may not get mined at all.

I should point out that if there is a very sudden sharp increase in tx demand and a fast confirmation is important then paying the higher 20x fee or even 166x fee may be appropriate. That is after all the purpose of the higher fee levels.