(Sorry, didn't realize you had replied a week ago. Email notifications seem a little spotty on the forums, eh?)
Okay, I'm looking into this a little deeper with your comments in mind.
Using hooks to handle is_private: great idea.
Adding a parent_id column: Yes, great. Would allow for comments to be multi-threaded (a la slashdot) and to be marked private themselves -- at least in the data structure; whether the UI wants to handle that is another question, depending on the situation.
How would you feel about us contributing some of this, so that the basic structure is there and is used in some cases, and then leave the other cases for future development? This would mean we start off with:
- Modify table structure and DAO to include is_private and parent_id columns
- Add method to Notes BAO to fetch note tree.
- Add features to Contact Notes to support creation of comments attached to notes, and marking notes as private. (Comments not multi-threaded, and comments not markable as private).
- Create hook_civicrm_notePrivacy
- Default to limiting is_private notes only to creator_id, but invoke hook_civicrm_notePrivacy to allow change of that.
Later, based on user demand and/or available resources, we or someone else could expand this to include UI for note comments on other entity types, API access for note comments, note comments in reports, etc.
Would this, or something very close to it, be a useful contribution?