Current proposal:

Two Comment Patterns

1. Content Comments (comments are appended to card content, our current pattern)
2. Card Comments (comments are independent cards, much more conventional)

The core idea here is that both patterns make use of a +*comment trait (and we get rid of the +*comment permission). 

[Aside: "Traits" are, arguably, not fully baked ideas, but the core of it is that they are plus cards that get some special interface, especially around permission.  +*account is  trait, for example.  There is some discussion that +*name and +*type could some day be traits to affect permissions for editing names and editing types (which could then be separated from general update permissions).]

The two patterns will share lots of configuration / behavior. In both patterns:

• comment boxes are handled as a view (true now) and only show up when the view is explicitly wagneered (not true now)
• permission to comment are determined by the same permission (perhaps the *create permission of the +*comment trait? That rule should default to inheriting.  ie, *comment+*right+*create should == _left.  So, if you can create/update a card, then you can comment on it.)
• when you go to create a comment, you are making the same kind of request (probably a  PUT request to the +*comment card), but event handling directs what is actually done with the comment data

However, they differ in these ways:

• In content comments (appended), the comment will be formatted at "action time" and then saved to the card.  No future template changes will affect the structure of the comment (though as now, each comment can be edited directly).
• In card comments, simple comment (unformatted) will be stored in its own card; the formatting will happen at render time, and future template changes will affect old comments
• Many of the concerns listed in +needs will only be addressable in the "card content" variant.  With comments in separate cards, you can sort, you can query, you can count, you can change up item views...  This solution does not address any of those for the content variant.

How do you configure which kind of commenting you want?  My first idea is that this determined by the *autoname setting on the +*comment card.   If the *autoname rule is blank or "_self", then you have a content card.  How exactly we handle the configuration for card comments depends on the data representation, which is perhaps the biggest question mark in the proposal.

Data Representation

 This is deeply related to Managable Patterned Contextual Lists idea, and for now most of our discussion about this representation (especially the comments themselves) should probably happen there.

My first inclination is to say that +*comments is actually a Pointer and that, for card comments, each comment is added to the pointer.  This has some cool benefits over using search, including performance, potential support for threading, being able to remove comments from a conversation without renaming or deleting them, being able to move comments to an entirely different discussion...

Near Term: improvements to content comments

Straightforward pre-Decko-1.0 steps:

1. stop making it so that comment boxes show up automatically when permitted in open cards - migrate nests so that open cards with comment permissions have "show: comment_box".
2. move the permission checking to the trait, migrate current permissions, and get rid of the +*comment permission!

once we have our action API it should also be relatively straightforward to:

1. switch over to the PUT request to +*comment and move comment code to the set mod.
2. make signatures wagneerable.

Note that this is all within the "append" model.  The "own card" model would still be after Decko 1.0