Igor Khomenko

REST API, Chat API and dashboard updates

Posted by Igor Khomenko on July 31, 2015

After the release of Chat 2.0 API we had a time to collect your feedback on this and now QuickBlox team releases some cool REST API and dashboard updates based on your feedback.

Let’s see what we have:

  • Force dialog deletion. Now an owner can completely delete a chat dialog he created.
  • Force message deletion. Now an owner can completely delete a chat message he created.
  • Better management of delivered/read status:
    • Chat message model now has read_ids and delivered_ids fields so you can easily track who received and read a message you sent.
    • Now you don’t need to call a REST API method to mark messages as delivered or read. Now you can just call an appropriate Chat/XMPP method and Chat backend will do other job by itself!
  • GET /Messages API now provides an optional mark_as_read parameter to not to mark retrieved messages as read.
  • Ability to delete multiple dialogs in a single query.
  • API to retrieve unread messages count

And we also have one cool feature on Dashboard called History actions. Now you can track all actions you do in the QuickBlox admin panel. This is to protect you from accidental actions. You can find this log on page.

Have a fun with new features!

Igor Khomenko

JavaScript SDK 1.9.3 with updated Content and CustomObjects code samples

Posted by Igor Khomenko on July 14, 2015

Today QuickBlox team releases a new version JavaScript SDK 1.9.3. This is a small but useful updated for our web developers:

  • added an ability to use user_id as the first parameter in
  • added an ability to use user_id in
  • added an ability to provide the page & per_page parameters in QB.content.list

Also we are excited to show you new web Content and CustomObjects code samples – completely new rewritten code samples that help you to build your amazing web apps with QuickBlox! Check them in our JavaScript dev section.



Demo also are available:

And more Web updates coming soon!


Igor Khomenko

QuickBlox releases iOS SDK 2.3: lots of Chat updates

Posted by Igor Khomenko on June 18, 2015

Awesome news for iOS team today – QuickBlox releases iOS SDK 2.3 with a lot of Chat API updates, that mainly simplify integration and speed up apps development!

Also new iOS samples with latest Apple technologies are developed

Download iOS SDK 2.3

Main updates:

  • General:
    • Removed API 1.x
  • Chat:
    • Models QBAbstractMessage, QBChatMessage, QBChatHistoryMessage are merged into one model QBChatMessage
    • Now you must use QBChatDialog for all chat related operations. Previous methods are deprecated.
    • Added API to send and receive system messages: A method [[QBChat instance] sendSystemMessage:] and delegatechatDidReceiveSystemMessage:
    • Updated XMPPFramework
    • Ability to mark all chat messages as read: [QBRequest markMessagesAsRead:null dialogID:dialogID successBlock:errorBlock:]
    • Added readIds and dialogId properties to QBChatMessage model
    • TLS connection set by default now
    • Added methods to QBChatDelegate to track chat reconnection states
    • Added method to get a number on chat dialogs and messages: [QBRequest countOfDialogsWithExtendedRequest:successBlock:errorBlock:], [QBRequest countOfMessagesForDialogID:extendedRequest:successBlock:errorBlock:]
    • Added 2 delegate methods for Contact List API: chatDidReceiveAcceptContactRequestFromUser:,chatDidReceiveRejectContactRequestFromUser:
  • Content:
    • Simplified API to download files from Content module. Now QBCBlob model has next methods to get an url to file: publicUrl, publicUrlForID:,privateUrl, privateUrlForID:
  • Custom Objects:
    • Added aggregation API
  • Users:
    • New API to update user
    • Now SDK hosts current logged in user: [QBSession currentSession].currentUser
  • Messages:
    • New methods to register and unregister push notifications that take an additional argument to set device udid.
    • Now you can subscribe to push notifications just with single request: [QBRequest createSubscription:successBlock:errorBlock:]

For any support queries, please create a ticket in our helpdesk.

Good luck with your apps development!

Taras Filatov

HIPPA compliant mobile chat / video calling and messaging infrastructure

Posted by Taras Filatov on June 12, 2015

Most of QuickBlox clients coming from Healthcare sector require HIPPA compliance.

How a cloud-based messaging infrastructure can be HIPPA compliant?

hippa compliant messaging infrastructure


Key factors:

1. HIPPA compliant web hosting

In order to store your patients’ and customers’ information securely first of all you need to choose an appropriate hosting provider.

Note that when you choose a well-known hosting provider such as AWS or Rackspace you still need to make sure you choose the package that corresponds specifically to HIPPA requirements.

On AWS for example, you need to choose AWS dedicated instanced vs standard AWS instances. Dedicated instances may be 1.5x times more expensive.

Read more about HIPPA compliant AWS packages and conditions here:

There are also alternative hosting options that specialise in HIPPA compliant infrastructure hosting – some of them work on top of Amazon Web Services but can still provide better pricing compared to AWS dedicated. One of the providers we worked with is Atlas Health and usually our clients choose between AWS dedicated, on-premises and specialised HIPPA hosters such as Atlas.


2. Your own hosting account + limited access for external staff

Most of QuickBlox enterprise clients choose to host the infrastructure within their own AWS account. While still fully covered by QuickBlox SLA (support agreement) and monitored by our SiteOps team, it gives our clients peace of mind they remain in control of their infrastructure including all users data. All users data stays at your servers and doesn’t go to any 3rd parties. Sometimes our clients choose to host on premises or within our cloud. Main thing here is it is paramount that you have your own application / chat / database server instances and your applications don’t share data with any other customers. To summarise, make sure your communication infrastructure is not in a shared cloud but you have your own dedicated servers and instances where your users’ data is stored.


3. Proper legal coverage

What you should look into doing is sign a Business Associate Agreement (BAA) with your hosting provider as well as NAA (Network Access Agreement) with your software/infrastructure provider (QuickBlox) specifying the names of technical support staff who have access to your instances.

This provides you with required legal protection and accountability from all sides in order to maintain HIPPA compliance at hosting, software, data and sysops level.


4. Encryption (server-side, client-side, transport)

QuickBlox infrastructure and client-side SDK libraries ensure to use latest industry encryption standards as well as secure HTTPS / TLS connection for client-server transport. Enterprise clients have the option of enabling additional SSE (server-side encryption) as well as extra layers of protection on the client such as integration with MDM whitelisting for sensitive data self-destruct in case device is stolen or build copied to unauthorised device, storing chat history cache in encrypted SQLite database etc. Contact us to find out more about encryption and security options available.


5. Minimise sensitive data exposure

Last but not least – remember you don’t actually have to pass sensitive data around every time. Some of our clients assume as we have QuickBlox Users API they have to duplicate all users profiles into QB Users entities. That is not the case – QB Users is only needed to identify users as device owners when you create chat sessions as well as for audio/video calling and push notifications. This doesn’t require however to store any personal information about users such as their names or phone numbers. You can keep it to random IDs and user external_ID property of QB Users API to link with your internal users database. Moreover, QB Users API allows operating user entities using external_ID. So you don’t have to store sensitive user profiles information within QB and you can use your own ID numbering to manipulate QB users when you interact with chat SDK.

Chat history is another question. You have choices here too, from choosing not to store any server-side history at all, to applying server-side encryption or exporting via Apache Kafka to your secure storage and removing it from your QuickBlox infrastructure. Default option however server-side chat history is enabled as it enables better experience for end users allowing seamless history sync between multiple devices. You and your technical staff have direct access to chat history storage via dashboard and database enabling you to wipe that data whenever required. All history is stored separate from user accounts and if you need to do automatic or manual moderation or search queries, for example in compliance with government body or police inquiry, you can ensure users privacy isn’t compromised unnecessarily.

To summarise, QuickBlox software and infrastructure is fully HIPPA compliant provided the required hosting, legal and configuration conditions are met as described above. We have an extensive experience in setting up HIPPA compliant communication infrastructures enabling doctor-patient, doctor-doctor and patient-patient communication with users data stored in secure and compliant way.

Get in touch to discuss your project requirement and benefit from our existing experience in this area – e-mail or call using numbers from our Contact page.