From d5abf35eae60bd38912736fd5e3b316829a26a8d Mon Sep 17 00:00:00 2001 From: Ikjot Singh Dhody Date: Sun, 18 Jun 2023 14:52:07 +0530 Subject: [PATCH] blog: Minor changes and fixes Signed-off-by: Ikjot Singh Dhody --- _posts/2023-06-17-XEP-0045-In-Moxxmpp.md | 105 +++++++++-------------- 1 file changed, 42 insertions(+), 63 deletions(-) diff --git a/_posts/2023-06-17-XEP-0045-In-Moxxmpp.md b/_posts/2023-06-17-XEP-0045-In-Moxxmpp.md index 2be8de7..ba03298 100644 --- a/_posts/2023-06-17-XEP-0045-In-Moxxmpp.md +++ b/_posts/2023-06-17-XEP-0045-In-Moxxmpp.md @@ -1,6 +1,6 @@ --- layout: post -title: XEP 0045 implementation in Moxxmpp +title: XEP-0045 implementation in Moxxmpp author: Ikjot Singh Dhody --- @@ -22,7 +22,6 @@ In the words of it's developer, Moxxmpp is "a pure-Dart XMPP library". Moxxmpp c Not only this, used as per it's rules - Moxxmpp could be used by any client to perform XMPP tasks that are currently supported by it. It is a re-usable and versatile XMPP library. - Listed below are some of it's core responsibilities: 1. Establishing the connection between the client and the XMPP server via the user's JID and password. 2. Allowing Moxxy/any front-end client to register managers that provide support for a particular XEP/part of the XMPP flow. For example: the messaging service is handled by a MessageManager. @@ -76,7 +75,7 @@ This routine will send a presence stanza to the MUC server asking it to join the Important to note is that the user's nickname will be used as the 'resource' in the roomJID sent by the frontend. This is because the 'to' attribute of a presence stanza to join a room looks as such - `{local/MUC}@{domain/chat server}/{nickname}.` -#### `Future> leaveRoom(String roomJID)` +#### `Future> leaveRoom(JID roomJID)` Similarly this is a routine to allow for leaving the room with a presence stanza. @@ -92,23 +91,23 @@ The `sendMessage` routine will transform from ```Dart Future sendMessage( - JID to, - TypedMap extensions, - ) async { - await getAttributes().sendStanza( - StanzaDetails( - Stanza.message( - to: to.toString(), - id: extensions.get()?.id, - type: 'chat', - children: _messageSendingCallbacks - .map((c) => c(extensions)) - .flattened - .toList(), - ), - awaitable: false, - ), - ); + JID to, + TypedMap extensions, +) async { + await getAttributes().sendStanza( + StanzaDetails( + Stanza.message( + to: to.toString(), + id: extensions.get()?.id, + type: 'chat', + children: _messageSendingCallbacks + .map((c) => c(extensions)) + .flattened + .toList(), + ), + awaitable: false, + ), + ); } ``` @@ -116,24 +115,24 @@ to ```Dart Future sendMessage( - JID to, - TypedMap extensions, - String type, - ) async { - await getAttributes().sendStanza( - StanzaDetails( - Stanza.message( - to: to.toString(), - id: extensions.get()?.id, - type: type, - children: _messageSendingCallbacks - .map((c) => c(extensions)) - .flattened - .toList(), - ), - awaitable: false, - ), - ); + JID to, + TypedMap extensions, + String type, +) async { + await getAttributes().sendStanza( + StanzaDetails( + Stanza.message( + to: to.toString(), + id: extensions.get()?.id, + type: type, + children: _messageSendingCallbacks + .map((c) => c(extensions)) + .flattened + .toList(), + ), + awaitable: false, + ), + ); } ``` @@ -157,28 +156,7 @@ extensions.get()?.conversationType == Here, `ConversationTypeData` is a simple wrapper over `ConversationType` so that it can be recognized as a subclass of the `StanzaHandlerExtensions` class. -The described change will be to allow for MUC messages, but doesn't describe how the private MUC messages will be handled. This has been elaborated below: - -### Changes/Example - -* `For normal MUC messages:` - -The call from Moxxy will send an extensions object as a parameter which will contain the following: -```Dart -TypedMap.fromList([ - ... - (ConversationType.groupchat) -]) -``` - -* `For private MUC messages:` - -```Dart -TypedMap.fromList([ - ... - (ConversationType.groupchatprivate) -]) -``` +For private MUC messages to a single participant, the `type` attribute of the message stanza should be set to `chat`. This can be handled very easily in case of either solution implementation. --- @@ -190,13 +168,13 @@ For now, I have identified the below as the most crucial requirements for the Mo Below are the use-cases and how they are planned to be handled: -1. #### `Get member list` +1. Get member list After one joins a room, the user receives a presence from all the connected users to the chat. The best way to get the member list is to capture/handle the incoming presence stanzas and send an appropriate `MUCPresenceReceived` event to the UI. This way, whenever a user joins a room, they can see the current member list, and on subsequent presence updates, also change that list. -2. #### `Handling the room subject ` +2. Handling the room subject This is a very simple usecase. When a disco info query about the MUC goes out to the XMPP server, the response contains an identity node containing the chat name. This would be the best way to extract the rom subject. As of now, the `queryRoomInformation` routine will be triggered from the UI and the response will be sent to the same. This will be encapsulated in a simple `RoomInformation` class which is now updated as follows: @@ -250,6 +228,7 @@ Some challenges/room for error were noted along the way. They are enumerated bel ## Conclusion and future work +In conclusion, this blog post discussed the implementation plan for adding Multi-User Chat (MUC) support, specifically XEP-0045, to Moxxmpp. Moxxmpp serves as the backbone for the Moxxy XMPP client, handling the communication between the client and XMPP server. The blog outlined the directory structure, design plan, and key routines for implementing the MUC support in Moxxmpp. It also addressed some challenges and considerations related to handling MUC features. + Implementation for this has begun, and a [PR](https://codeberg.org/moxxy/moxxmpp/pulls/46) is already underway. Once this PR is completed, then work will begin on the front-end and the changes will be integrated into Moxxy. ----