lightningd: removing comment insisting plugin hooks are an array of objects, not names.

diff --git a/doc/developers-guide/plugin-development/a-day-in-the-life-of-a-plugin.md b/doc/developers-guide/plugin-development/a-day-in-the-life-of-a-plugin.md
index 5d9c14f4..8aea0df6 100644
--- a/doc/developers-guide/plugin-development/a-day-in-the-life-of-a-plugin.md
+++ b/doc/developers-guide/plugin-development/a-day-in-the-life-of-a-plugin.md
@@ -111,6 +111,8 @@ If you can handle the `check` command on your commands, you should set `cancheck
   
 If a `disable` member exists, the plugin will be disabled and the contents of this member is the reason why.  This allows plugins to disable themselves if they are not supported in this configuration.
 
+The `hooks` array is either an array of hook names, or an array of objects with `name`, and optional `before` and `after` arrays specifying what the calling order is with respect to any other plugins (there's no problem if these plugins don't exist, but if they do we'll insist on obeying everyone's ordering constraints).  You can also specify a `filters` array to some hooks to avoid being called on every occurrence.
+
 The `featurebits` object allows the plugin to register featurebits that should be announced in a number of places in [the protocol](https://github.com/lightning/bolts/blob/master/09-features). They can be used to signal support for custom protocol extensions to direct peers, remote nodes and in invoices. Custom protocol extensions can be implemented for example using the `sendcustommsg` method and the `custommsg` hook, or the `sendonion` method and the `htlc_accepted` hook. The keys in the `featurebits` object are `node` for features that should be announced via the `node_announcement` to all nodes in the network, `init` for features that should be announced to direct peers during the connection setup, `channel` for features which should apply to `channel_announcement`, and `invoice` for features that should be announced to a potential sender of a payment in the invoice. The low range of featurebits is reserved for standardize features, so please pick random, high position bits for experiments. If you'd like to standardize your extension please reach out to the [specification repository][spec] to get a featurebit assigned.
 
 The `notifications` array allows plugins to announce which custom notifications they intend to send to `lightningd`. These custom notifications can then be subscribed to by other plugins, allowing them to communicate with each other via the existing publish-subscribe mechanism and react to events that happen in other plugins, or collect information based on the notification topics.
diff --git a/lightningd/plugin.c b/lightningd/plugin.c
index f4a2f1a6..7c1f7316 100644
--- a/lightningd/plugin.c
+++ b/lightningd/plugin.c
@@ -1504,7 +1504,7 @@ static const char *plugin_hooks_add(struct plugin *plugin, const char *buffer,
 			aftertok = json_get_member(buffer, t, "after");
 			filterstok = json_get_member(buffer, t, "filters");
 		} else {
-			/* FIXME: deprecate in 3 releases after v0.9.2! */
+			/* Simple names also work */
 			name = json_strdup(tmpctx, buffer, t);
 			beforetok = aftertok = filterstok = NULL;
 		}