I don't think it would be possible for normal comments to reply to custom_json, at least without something quite convoluted, but that seems okay. If you want to make a normal comment you can go back to top level (or some higher level) to do it.
I think there might also be something for just deprecating normal comments altogether (if you want to contend for rewards, make a top level comment aka post). They have a high cost in terms of RCs/blockchain which seems perhaps just not worth it for the small number that get paid out and total payouts. Getting rid of all the comments would make posts significantly cheaper I think.
I wouldn’t want to see “full” comments deprecated. I think that would be negative toward multiple use cases, such as the increased engagement and reward mechanisms SteemPress is enabling on personal websites, or how it would cripple Quora style interfaces where answers and replies should be rewarded more than the top level question post.
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.
My guess is the hard part is validating the parent in combination with corner cases where the parent has been deleted and/or reversible.
Also, there’s complexity around allowing the two types to intermix. Normal comments replying to custom_json?
I don't think it would be possible for normal comments to reply to custom_json, at least without something quite convoluted, but that seems okay. If you want to make a normal comment you can go back to top level (or some higher level) to do it.
I think there might also be something for just deprecating normal comments altogether (if you want to contend for rewards, make a top level comment aka post). They have a high cost in terms of RCs/blockchain which seems perhaps just not worth it for the small number that get paid out and total payouts. Getting rid of all the comments would make posts significantly cheaper I think.
I wouldn’t want to see “full” comments deprecated. I think that would be negative toward multiple use cases, such as the increased engagement and reward mechanisms SteemPress is enabling on personal websites, or how it would cripple Quora style interfaces where answers and replies should be rewarded more than the top level question post.
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.