PapaTutuWawa/papatutuwawa.pages.polynom.me
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

blog: Minor changes and fixes

Browse Source 
Signed-off-by: Ikjot Singh Dhody <ikjotsd@gmail.com>
This commit is contained in:
Ikjot Singh Dhody 2023-06-18 14:52:07 +05:30
parent 5ef69c62af
commit d5abf35eae
1 changed files with 42 additions and 63 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
_posts/2023-06-17-XEP-0045-In-Moxxmpp.md
View File

@ -1,6 +1,6 @@
--- ---
layout: post layout: post
title: XEP 0045 implementation in Moxxmpp title: XEP-0045 implementation in Moxxmpp
author: Ikjot Singh Dhody 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. 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: 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. 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. 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}.` 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<Result<bool, MUCError>> leaveRoom(String roomJID)` #### `Future<Result<bool, MUCError>> leaveRoom(JID roomJID)`
Similarly this is a routine to allow for leaving the room with a presence stanza. Similarly this is a routine to allow for leaving the room with a presence stanza.
@ -94,7 +93,7 @@ The `sendMessage` routine will transform from
Future<void> sendMessage( Future<void> sendMessage(
JID to, JID to,
TypedMap<StanzaHandlerExtension> extensions, TypedMap<StanzaHandlerExtension> extensions,
) async { ) async {
await getAttributes().sendStanza( await getAttributes().sendStanza(
StanzaDetails( StanzaDetails(
Stanza.message( Stanza.message(
@ -119,7 +118,7 @@ Future<void> sendMessage(
JID to, JID to,
TypedMap<StanzaHandlerExtension> extensions, TypedMap<StanzaHandlerExtension> extensions,
String type, String type,
) async { ) async {
await getAttributes().sendStanza( await getAttributes().sendStanza(
StanzaDetails( StanzaDetails(
Stanza.message( Stanza.message(
@ -157,28 +156,7 @@ extensions.get<ConversationTypeData>()?.conversationType ==
Here, `ConversationTypeData` is a simple wrapper over `ConversationType` so that it can be recognized as a subclass of the `StanzaHandlerExtensions` class. 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: 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.
### 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<StanzaHandlerExtension>.fromList([
...
(ConversationType.groupchat)
])
```
* `For private MUC messages:`
```Dart
TypedMap<StanzaHandlerExtension>.fromList([
...
(ConversationType.groupchatprivate)
])
```
--- ---
@ -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: 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. 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. 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: 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 ## 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. 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.
---