Sort:  

No real idea, but I would assume its because the UI for deeper threads starts to get unwieldy. On the data side threads are likely recursive and could ostensibly support N levels, but having hacked together a few comment systems before the UI is always the tricky part ;)

Someone remind me to adjust my vote here (or down vote the parent for me). I didn't realize I was logged in as @dan. Above comment deserves some funds, but not $1000!

Just implement ASAP this ...

"As we know after 4 July the payouts will happen about 24 hours after voting… What make sense to me is that the vote should be time % weighted… If I vote now and I take my vote back after 1 minute 100% of my vote power should be taken back(it could be even be a miss-click)…If I do it after 12 hours then 50% should be taken back, if I take it back 1 hour before cashout only about 4% voting power should taken back (1/24)… What do you think?"

Darn, so close ;)

The blockchain must recursively calculate rewards and must do so within a bounded amount of time. It becomes a security issue if we allow it to be unlimited. As soon as we decide to make it limited, the depth is some what arbitrary and mostly limited by what makes sense in a user interface. Also, by the time discussion gets that deep it is likely sequential back and forth data rather than something that truly needs to be nested.

can we implement a chat option like on bitshares? Make it sense?

It does not make sense to limit replies at such a low level.
100 or 1000 is reasonable but only 5 does just cut the communication string and results in unhappiness! You will see that this will become a big usability issue.

I read somewhere on Reddit about their limit being made 1000 deep because the users managed to crash their server by making the threads deeper than 1000. I wonder if it's the same with Steem?

It's probably a layout decision. Otherwise you need 16K super mega ultra HD screens :)

Coin Marketplace

STEEM 0.18
TRX 0.14
JST 0.030
BTC 58833.91
ETH 3155.94
USDT 1.00
SBD 2.44