Channel Naming Conventions

PubNub doesn't have a means of defining the type of particular channel, but many use cases dictate their purpose and the types of messages being sent over those channels:

• Message broadcasting, such as speaker to audience announcements.
• Private/direct chat: typical 2 person chat sessions.
• Group chat: 3 or more participant chat sessions.
• Live audience engagement chat: hundreds to tens of thousands of users chatting concurrently.
• Control signals: controlling devices or client apps.
• Signal protocol, for example, getting clients connected over audio/video.
• Inbox messages, such as invitation for the user to chat or notification to the user of new messages/activity.

Descriptive Naming with Prefixes

While it's possible to use a User ID generator to name channels, the randomness of a User ID format prevents the developer from taking advantage of many PubNub features.

We recommend that you provide a prefix that identifies the purpose of the channel or the types of messages that are sent over those types of channels.

Following that prefix with a . character further enhances the usefulness of the channel name concerning the wildcard features with several PubNub features, including:

• Wildcard Subscribe
• Wildcard Channel Function Binding
• Presence ACL configuration (an advanced means for configuration presence based on channel naming patterns)

Wildcard subscribe

For more information, refer to Channel Subscriptions.

You can check if your channel name is valid using our channel name validator.

Channel name

Recommended Naming Convention

A good default channel naming convention would be [channelType].[channelID], where channelID could be the name of the chat room, a user ID, device ID, an event ID, region, department, customer ID, or whatever is appropriate for the use case. For example:

• group.room123
• inbox.user123
• command.device123

You might even use multiple entities to construct the channelID portion of the full channel name. For example, a combination of event ID and room ID or event ID and customer ID:

• group.event123.room123
• inbox.customer123.user123
• broadcast.customer123.event123.room123

Channel name depth

If your channel name is more than 3 levels deep (for example name(lvl1).user(lvl2).event(lvl3).room(lvl4)), you must disable the Wildcard Subscribe feature in the Admin Portal to be able to publish to this channel. Otherwise, you will only be able to subscribe to it.

Naming Consistency

Consistent naming convention is particularly useful when managing access to multiple channels. When granting permissions, you can specify them as a regular expression rather than a list of channels.

Using RegEx limits the size of the token that will be sent in the grant request. This way you keep your grants simple and within the size limit (32 KiB). For more information about granting permissions, refer to Manage Access.

Delimiter Variations

You should consider the delimiters that you use because the . is a special character and is only useful for PubNub features at the second level: foo.bar vs foo.bar.baz.

In other words, you can only leverage foo.* but not foo.bar.* for function channel binding.

For most use cases, however, using a . after the channel type prefix is the best option since you most likely want to have a specific Function that handles all messages over that type of channel or possibly no Function at all.

There are occasions when you want to have a different Function implementation per customer or event, so that would factor into where that. is positioned.

For more detailed channel naming convention recommendations tailored to your specific requirements, feel free to contact your PubNub account manager and solution architect.