You are viewing a single comment's thread from:
RE: Hive Communities: An Interview w/Steemit's Senior Product Engineer
I'm looking forwards to seeing Communities released. This should give some new energy to Steem.
I was wondering if Hivemind could give us the ability to enable some kind of anonymous or non-steem social commenting. Whenever someone share their Steem blog posts to other social platforms, the audience from those platform might want to interact with the author and leave a comment but they currently can't unless they sign up but they might not want to or it takes too long to on board and by the time it's successful they might forget about why they signed up. With Google/FB/Twitter authentication and allowing those to leave comments we might be able to attract some external users.
One of the nice-to-haves for hivemind is comments via
custom_json-- these would not be threaded, nor would they collect payouts. They would use far less RC than normal comments, so it makes them useful for smaller accounts, but they could also be leveraged by UIs to allow for 'guest' comments. The UI would still need to reasonably limit spam, but there would be less at stake in terms of resource abuse.Why is it hard to make them threaded? Seems pretty easy to let them specify a parent, no?
The only hard part about threading 'lite' comments is a stable parent reference, but we could use the first 8-10 bits of the tx hash for this purpose. The main reason I suggested non-threaded was for simplicity. It may or may not make sense to bundle these with votes (i.e. a comment with a up/down vote) or reactions, and nesting them makes less sense in that case.
Couldn't the commenter include their own unique permlink-like tag in the json, pretty much the same as a regular consensus comment? The only real difference is tracking it in hivemind rather than steemd. You can't enforce that people put in properly-formatted json, but if they don't you can ignore it.
Yes, the only concern is that with this approach hivemind would have to track uniqueness of permlink/id's, and create/track a valid/invalid state on each. This opens up more edge cases and would make it harder to reimplement the protocol. Trx hashes are already unique, indexed, and part of core consensus, which makes them attractive to leverage.
I don't believe you need to actually store or track invalid state, just check that each custom_json is valid when processed. If the custom_json creates an invalid state (for example, presents a non-unique tag), the custom_json is invalid and is ignored. This is the usual method for doing any sort of embedded consensus, which is effectively what this is.
In fact, now that I think about it, non-unique might be considered as valid, since referencing an existing id could be an edit, if the rules mirror those for comment ops. In that case, there would be no invalid (non-unique) ids.
That's what I thought of, but as you said the spam contents would be more and thus the account which will be guest posting can face the consequences.
What I think is that you can make a db over steen where you can keep the user info and comments. Now it will help you to do the spam filtering as well as a normal account can post it on the user's behalf.
should make it more accessible but just like SMT's were possible from the very start using condenser in whatever way you want to translate that back-end , so were communities , heh ... not that it's not a good thing that it becomes accessible to les tek-leveled heads but it has always been there, #musing #steemstem ... to name but two, they didnt have to wait , they just built one :D
more options = mo' better though, always ... if you can just get rid of downvoting and inflation completely it might yet stick around to see me grow old :p