Presently a channel feature is distinguished from an identity feature by the presence of an identity key-value pair in its metadata. Something more explicit would be beneficial for a few reasons:
Channel and identity features will likely depend on largely different sets of events (with some overlap). Providing this distinction will allow us to story-tell-teach the identity and channel feature use cases (and relevant events/methods) more succinctly.
The usage of an identity will likely not be sufficient (for very much longer) as a means of distinguishing between feature types (identity vs channel) or runtime environment (client-userAgent vs combinator)
Some ideas for enabling the distinction:
Providing concrete IdentityFeature and ChannelFeature subclasses of Feature
Adding an type key-value pair to the feature metadata, e.g. {..., "type": "channel", "identityRole": "member", "environment": "userAgent"} would specify a feature that should be installed on a channel, run on the client, and given an identity with membership level permissions, i.e. what I think we'd need for comments
Presently a channel feature is distinguished from an identity feature by the presence of an identity key-value pair in its metadata. Something more explicit would be beneficial for a few reasons:
Some ideas for enabling the distinction:
IdentityFeatureandChannelFeaturesubclasses ofFeaturetypekey-value pair to the feature metadata, e.g.{..., "type": "channel", "identityRole": "member", "environment": "userAgent"}would specify a feature that should be installed on a channel, run on the client, and given an identity with membership level permissions, i.e. what I think we'd need for commentscc @tonygentilcore @html5cat