RE: Today I learned that it's possible to resteem a comment/reply (sort-of)
My guess is that the original implementers were concerned about spamminess. There was sort of a militant attitude about "quality content". I guess this would have been fine if we had enough "quality content" to attract lots of readers. But that has almost never been the case.
My own opinion is that velocity trumps quality for drawing attention. I'd rather have a feed that feels like vibrant bazaar than one resembling a pristine chapel that nobody visits. Therefore, I like Twitter's current approach of welcoming both long and short-form posting.
For Steem, if someone doesn't want to see the resteemed replies, I think it's a good idea to have a filtering option in the front end, but I don't see a reason to filter it at the blockchain. If a feed is spammy, then people can just "unfollow" or turn off visibility or resteemed replies.
If we wanted to include them now, the entire database would have to be re-synchronised.
Ugh. I hadn't thought of that. So you almost need to find a way to double-up the infrastructure and do a hot cutover once the resynch finishes.
A title would actually be missing (with the current condenser). However, it could be replaced by the title of the root post if the comment was not given a title.
This is what I was thinking, too.
Yes, this is an alternative. When requested by the frontend, it could be specified whether comments should be retrieved in the feed or not. Or they are retrieved in any case and only not displayed in the frontend. There are various approaches.
It happens only on Hivemind.
I can't remember why I assumed a re-sync. No comments have been resteemed yet. So, nothing would have to be replayed... I'll have to take a closer look again... my list is getting longer and longer... :-)
Sorry, yeah, if I'm not careful, I think of everything behind the API endpoint as "blockchain". Lazy way of thinking about it.
Well, at least 1 comment has been resteemed, but none that anyone cares about. 😉