Channel Naming Conventions

PubNub doesn't define specific types for a channel. Your use case defines the purpose and the kinds of messages you send on that channel. Learn more in Channel overview.

  • 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 channel 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.

Use a prefix that identifies the purpose of the channel or the types of messages sent on that channel.

Add a dot (.) after the prefix to enable wildcard-based features, including:

  • Wildcard Subscribe
  • Wildcard channel binding for Functions
  • Presence ACL configuration (an advanced means for configuration presence based on channel naming patterns)
Wildcard subscribe

For more information, refer to Channel Subscriptions.

Validate your channel name:

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

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

You can also compose the channelID portion of the full channel name from multiple entities. For example, combine an event ID with a room ID, or an event ID with a 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.

Last updated on
On this page