This is the slide deck for ProcessOne first live XMPP Academy. Here are the questions covered: 1. ejabberd SaaS architecture questions - What is the best way to archive user messages if we do not want to sync data from user device? - Why does ejabberd SaaS not use async mechanisms for archiving messages to customer back-end server? - Mobile XMPP support: Explain standby, push and detached modes. 2. XMPP / ejabberd questions - How does ejabberd internally store messages which are not yet delivered? - How are privacy lists managed in ejabberd? - What is on the ejabberd roadmap ? OAuth !

1. Academy #1
28th september 2015
Mickaël Rémond, @mickael
Video recording: https://youtu.be/-dqQfCpw98E

2. Questions
ejabberd SaaS architecture questions
• What is the best way to archive user messages if we do not want to sync
data from user device?
• Why does ejabberd SaaS not use async mechanisms for archiving
messages to customer back-end server?
• Mobile XMPP support: Explain standby, push and detached modes
XMPP / ejabberd questions
• How does ejabberd internally store messages which are not yet delivered?
• How are privacy lists managed in ejabberd?
• What is on the ejabberd roadmap ? OAuth !

3. ejabberd SaaS architecture
• ejabberd SaaS is designed:
• to be easy to integrate in customers architecture
• with scalability and high-availability in mind
• to be as stateless as possible
• to allow customers to keep control of their data
• ejabberd SaaS works in two modes:
1. Statefull: All or most data managed by ejabberd SaaS.
2. Stateless: All or most data on the customer back-end (recommended).

4. Main issue
data duplication =
risk of out of sync
user base
Mobile - Desktop - Web Browser
XMPP - 5222
Websocket / Bosh:
HTTP - 80
HTTPS - 443
User base
manage remotely
ejabberd Instant Messaging
ejabberd cluster
...
Load balancers
XMPP - 5222
ejabberd API - ReST or XML-RPC
ejabberd SaaS
managed by
ProcessOne
ejabberd SaaS architecture
Statefull mode
Customer backend
Contact list
manage remotely
ejabberd SaaS database
User / password
Rosters
Message archives
Offline messages
Last seen
Privacy lists
Pubsub nodes
Push tokens (APNS / GCM)
…

5. Mobile - Desktop - Web Browser
XMPP - 5222
Websocket / Bosh:
HTTP - 80
HTTPS - 443
ejabberd Instant Messaging
ejabberd cluster
...
Load balancers
XMPP - 5222
User endpoint
User calls
ejabberd ReST data access layer
select one or several backends
ejabberd SaaS
managed by
ProcessOne
ejabberd SaaS architecture
Stateless mode
ejabberd SaaS database
Offline messages
Last seen
Privacy lists
Pubsub nodes
Push tokens (APNS / GCM)
…
Roster endpoint
(contacts)
Roster calls
Message archive
endpoint
Message
Archiving calls
More to come
Data backend
managed by
customer

6. What is the best way to archive user messages if
we do not want to sync data from user device?
• It is not dependent on how whether the user device will sync data or not.
• Previously, the XEP for archiving was XEP-0136 - Message Archiving.
• This XEP is now obsoleted by XEP-0313 - Message Archiving Management.
That specification play nicely with all other newer XMPP features.
=> This is the specification to use for archiving
=> even if you do not plan to let user download messages from server archive
to client.
• Note for ejabberd SaaS: You can implement it in two ways:
• Data on ejabberd SaaS server.
• Data stored on customer backend through HTTP ReST API calls
(Preferred)

7. Why does ejabberd SaaS not use async mechanisms
for archiving messages to customer servers?
• An XMPP server is always buffering some data. It buffers offline messages
before delivery. It buffers messages send by a client to another connected
client that is receiving slowly, etc.
• However, buffering makes any a fragile component of the architecture. If you
buffer too much, you can kill your central server during peak time.
So,
1. For scalability and robustness you need to have all write processed to their
final destination as fast as possible => write as you receive the messages.
2. Receiving and writing back-end HTTP calls for messages is easy to scale
(i.e. Basho Riak).
3. Customers can implement more features when they receive the archived
messages in real-time (Like triggers email).
4. Archiving individual messages make it possible to load balance / shard the
back-end (for example based on Jabber ID).

8. Mobile XMPP support: Explain standby, push
and detached modes
• When implementing mobile support you need to cope with mobile limitations:
• XMPP sessions are originally designed for constantly connected TCP/IP
sockets.
• Smartphone applications are put to sleep to save battery life.
=> We needed a way to make XMPP friendly with smartphone operations.

9. XMPP C2S state machine
Highly simplified
default XMPP session
states
Session established
Session closed
Close stream
or TCP/IP
connection
Open TCP/IP
and stream
Stream opened Login

10. XMPP Mobile
C2S state
machine Session established
Session closed
Close stream
or TCP/IP
connection
Open TCP/IP
and stream
Stream opened Login
Standby mode
(Limit traffic, filter
presence)
/
Inactive client
(CSI)
Standby /
Inactive
Enable
push mode
Active
Session with push
mode enabled
Open TCP connection
and rebind
to session
Session
expires
Close stream
TCP close
Detached session
Session still opened
Can receive push

11. How does ejabberd internally store messages
which are not yet delivered?
Message not delivered can be generated in several state:
1. Session is established with TCP connection attached
A. If client does not support message acknowledgement
Message are directly send on TCP and deleted from memory.
B. If client support message acknowledgement
Messages are buffered in the session until acked by receiving client.
Messages are stored for offline delivery if the session timeouts without
receiving message acks.
2. Session is established in detached mode:
• Messages are buffered in the session and are send on reattach.
• Messages are stored for offline delivery if the session expires before
reattach.
3. There is no session for user:
• Message are directly stored in offline storage.

12. How are privacy lists managed in ejabberd?
• ejabberd supports:
• XEP-0016: Privacy lists
• XEP-0191: Blocking Command
• Both specifications can be used together on a single back-end.
• Data are stored in ejabberd database (various databases possible).
• No ReST backend for now for performance reasons.

13. What is on the ejabberd Roadmap ? OAuth !
• ejabberd 15.09 is about to be release.
• It will include OAuth 2.0 support for ejabberd.
• This is a huge feature that has been in development for several months.
• Features:
• Security: Set-up login in client without sharing password with client.
• User can delegate rights to others third-party applications. You can let a
third-party service send message or post in chat room on your behalf.
(Slack-like)
• Make ejabberd a central piece in a micro-services architecture.
• Internet of Things support: Your things can do stuff for you without the
need to fully speak XMPP.
• Build an ecosystem: Grant limited rights to your partners.

14. ejabberd 15.09 + OAuth
=

15. See you at next