Model Group Chat XEP-0045

Pada tahun 1999, komunitas jabber telah membuat sebuah basis sistem text conferencing yaitu groupchat 1.0 (GC). Basis sistem ini merupakan minimal fitur untuk implementasi chat room. Groupchat 1.0 ini merupakan protokol yang memiliki kemiripan dengan protokol Internet Relay Chat (IRC). Sedangkan spesifikasi Multi-User Chat (XEP-0045) merupakan spesifikasi advanced features sebagai pengembangan dari groupchat 1.0. Terdapat banyak sekali fitur yang ditambahkan pada spesifikasi ini, seperti invitation, room moderation, pembagian tipe room, dan room discovery.

Secara umum spesifikasi tidak merubah basis sistem groupchat 1.0 (backwards-compatible), sehingga baseline functionality dari groupchat 1.0 ini masih dipakai oleh spesifikasi ini. Fungsionalitas groupchat 1.0 yang dimaksud adalah:

1. Setiap room memiliki identitas unik sebagai "room JID" yang memiliki format penulisan room@service, contohnya thewolfpack@conference.hangover.com. "thewolfpack" adalah nama room sedangkan conference.hangover.com adalah alamat service dari Multi-User Chat.
2. Setiap partisipator didalam room teridentitas sebagai "occupant JID" dengan format penulisan room@service/nickname, contoh thewolfpack@conference.hangover.com/alex. "alex" adalah room nickname dari user yang tergabung pada room.
3. User dapat masuk kedalam chat room (menjadi partisipator) dengan mengirim secara langsung sebuah presence kepada alamat room@service/nickname.
4. Partisipator dapat mengubah nicknamenya dengan mengirim informasi presence ke room@service/newnickname.
5. Sebuah message dalam multi-user chat memiliki tipe "groupchat" dan memiliki alamat room@service. Service kemudian akan mengirimkannya kepada seluruh partisipator.
6. Partisipator keluar dari room dengan mengirimkan presence tipe "unavailable" ke alamat room@service/nickname.

Sedangkan fitur tambahan yang ada pada spesifikasi XEP-0045 ini adalah sebagai berikut:

1. Native conversation logging.
2. Membolehkan user untuk request menjadi member pada private room.
3. Membolehkan partisipator untuk melihat occupant JID pada non-anonymous room.
4. Membolehkan moderator untuk melihat occupant JID pada semi-anonymous room.
5. Dapat mengatur hanya moderator saja yang dapat mengganti topik/subjek sebuah room.
6. Membolehkan moderator untuk mengeluarkan (kick) partisipator dan visitor pada room.
7. Membolehkan moderator untuk mengeluarkan dan mencabut ijin bicara pada moderated room.
8. Membolehkan administrator untuk memberi dan mencabut ijin sebagai moderator room.
9. Membolehkan administrator untuk mengeluarkan user dari room (ban) dan juga mengatur daftar ban user.
10. Membolehkan administrator untuk memberikan dan menolak membership privileges dan juga mengatur daftar member pada membe-only room.
11. Membolehkan owner untuk mengatur konfigurasi sebuah room sebagai contoh memberikan limit member.
12. Membolehkan owner untuk menunjuk owner lain.
13. Membolehkan owner untuk memberikan dan mencabut ijin sebagai administrator dan juga mengatur daftar administrator.
14. Membolehkan owner untuk menutup room.

Pada dokumen spesifikasi ini, disebutkan juga beberapa room type yang didefinisikan seperti:

1. public vs. hidden
2. persistent vs. temporary
3. password-protected vs. unsecured
4. members-only vs. open
5. moderated vs. unmoderated
6. non-anonymous vs. semi-anonymous

Beberapa spesifikasi ini saya ambil dari dokumen manual XEP-0045 yang dikeluarkan IETF. Rekan-rekan akan lebih baik membaca dokumen tersebut untuk mengetahui lebih detailnya. Spesifikasi ini begitu komplek bahkan untuk pembuatan aplikasi group chat, tapi memang pada dasarnya spesifikasi ini tidak dibuat hanya untuk pembuatan aplikasi itu. Kita bisa membandingkan model yang ditawarkan spesifikasi ini dengan model yang ada pada spesifikasi publish-subscribe yang ada pada XEP-0060. Dari kedua model yang ditawarkan ini, model mana yang lebih cocok dengan aplikasi yang hendak kita buat.

Tidak hanya pembuatan group chat saja, saya pernah menemukan sebuah aplikasi chess (catur) yang juga memanfaatkan spesifikasi MUC untuk urusan bisnis aplikasinya. Yang saya maksud ini seperti invite lawan untuk bermain, lawan menyetujui undangan untuk bermain, melihat semua daftar permainan yang sedang berlangsung (room) dan juga sampai pada mekanisme user viewer (bukan pemain) yang hanya masuk untuk menonton jalannya permainan. Game-game model seperti ini tentunya kita sudah banyak melihat, bahkan kita pernah juga memainkannya sekarang ini, seperti game poker dari zynga, poin blank (PB). Dan pada akhirnya kita bisa dengan mudah membuat aplikasi game yang serupa karena modelnya sudah ada dan terbentuk yaitu dengan model Multi-User Chat XEP-0045 ini.

Sebelum menyetujui untuk memilih spesifikasi ini, penting juga untuk mengetahui bahwa setiap pesan masuk pada room tidak-lah bersifat durable. Artinya adalah pesan masuk akan disampaikan, hanya pada user-user yang sedang join room sekarang. Penting juga mengetahui maksud kata “join” pada kalimat ini. Entitas/user harus memiliki status network available dan telah bergabung kedalam room, baru kemudian pesan masuk akan dapat dia terima, tapi jika kemudian koneksi terputus maka dia tidak akan mendapatkan lagi pesan sedang masuk sekarang ini. Baik tipe room publik maupun member-only memiliki mekanisme pesan seperti ini. Tidak ada mekanisme queue untuk pesan masuk agar pesan tersampaikan semua pada entitas yang sudah langganan ke group seperti yang ada pada protokol AMQP dan MQTT. Untuk beberapa permasalahan yang ada ini, MUC mendefinisikan Discussion History yang akan sangat membantu, tapi tentu saja cara ini merupakan trik untuk mengatasi permasalahan yang ada. Untuk alasan seperti ini jugalah, kita harus hati-hati dalam memilih protokol dengan spesifikasi Multi-User Chat ataukah protokol dengan model publish-subscribe seperti XEP-0060, AMQP, MQTT, Apache Kafka, dll.