jadedctrl / chat-o-matic

A multi-protocol chat program for Haiku

Chat-O-Matic

Chat-O-Matic is a multi-protocol chat program based on Caya.

It can use protocols through native add-ons as well as through libpurple, the library used by Pidgin.

Protocols natively supported include IRC and XMPP.

Protocols generally supported through libpurple include GroupWise, Zephyr, and others through plugins.

You can find the user documentation here.

Building

You can make Chat-O-Matic and its protocols with:

$ make

Or one-by-one:

$ make libs; make app; make protocols

Chat-O-Matic itself requires the expat_devel package, the XMPP protocol requires gloox_devel, and the libpurple add-on requires libpurple_devel and glib2_devel.

Installation

Protocol add-ons can be installed in any add-ons directory under chat-o-matic (i.e., ~/config/non-packaged/add-ons/chat-o-matic/) or in the binary's CWD (./chat-o-matic/).

libpurple plugins can be installed to any lib directory under purple-2 (i.e., ~/config/non-packaged/lib/purple-2/).

License

Chat-O-Matic is under the MIT license, but licenses vary for the included libraries and add-ons.

The xmpp and purple add-ons are under the GPLv2+, and irc the MIT license.

libsupport is under the MIT license, though containing some PD code. librunview contains code from Vision, and is under the MPL. libinterface is under the MIT license.

chat-o-matic's Issues

Transferring of files/pictures

Sending and receiving files should be supported, be it by a drag-and-drop or a file dialogue.

Should be togglable by protocol, maybe based on a new permissions in Role.h― maybe PERM_UPLOAD and PERM_DOWNLOAD. Though specifying an allowed mimetype somehow would be useful.

Compact room-view

A "compact" version of the room header (containing title, icons, and subject) might be useful to have as an option. It might have the subject and title side-by-side, with icons not included. This would make the header use only a bit more than one "text-line" of space.

Build failure on 32bit

g++ -c application/views/ConversationListView.cpp -iquote./  -iquote./  -iquoteapplication/  -iquoteapplication/preferences/  -iquoteapplication/views/  -iquoteapplication/windows/  -iquotedata/icons/misc/  -iquotedata/icons/replicant/  -iquotedata/icons/status/  -iquotedata/misc/  -iquoteobjects.x86-cc8-release/  -isystemlibs/  -O3   -DVERSION="\"0.0.2\""  -DBUILD_DATE="\"2021-08-22  -D15:27\""  -DDEBUG_ENABLED=false  -o "objects.x86-cc8-release/ConversationListView.o"
g++ -c application/views/ConversationView.cpp -iquote./  -iquote./  -iquoteapplication/  -iquoteapplication/preferences/  -iquoteapplication/views/  -iquoteapplication/windows/  -iquotedata/icons/misc/  -iquotedata/icons/replicant/  -iquotedata/icons/status/  -iquotedata/misc/  -iquoteobjects.x86-cc8-release/  -isystemlibs/  -O3   -DVERSION="\"0.0.2\""  -DBUILD_DATE="\"2021-08-22  -D15:27\""  -DDEBUG_ENABLED=false  -o "objects.x86-cc8-release/ConversationView.o"
application/views/ConversationView.cpp: In member function 'void ConversationView::GetWeights(float*, float*, float*, float*)':
application/views/ConversationView.cpp:312:40: error: call of overloaded 'ItemWeight(int)' is ambiguous
  *horizChat = fHorizSplit->ItemWeight(0);
                                        ^
In file included from /boot/system/develop/headers/os/interface/LayoutBuilder.h:21,
                 from application/views/ConversationView.cpp:14:
/boot/system/develop/headers/os/interface/SplitView.h:38:13: note: candidate: 'float BSplitView::ItemWeight(int32) const'
    float    ItemWeight(int32 index) const;
             ^~~~~~~~~~
/boot/system/develop/headers/os/interface/SplitView.h:39:13: note: candidate: 'float BSplitView::ItemWeight(BLayoutItem*) const'
    float    ItemWeight(BLayoutItem* item) const;
             ^~~~~~~~~~
application/views/ConversationView.cpp:314:38: error: call of overloaded 'ItemWeight(int)' is ambiguous
  *vertChat = fVertSplit->ItemWeight(0);
                                      ^
In file included from /boot/system/develop/headers/os/interface/LayoutBuilder.h:21,
                 from application/views/ConversationView.cpp:14:
/boot/system/develop/headers/os/interface/SplitView.h:38:13: note: candidate: 'float BSplitView::ItemWeight(int32) const'
    float    ItemWeight(int32 index) const;
             ^~~~~~~~~~
/boot/system/develop/headers/os/interface/SplitView.h:39:13: note: candidate: 'float BSplitView::ItemWeight(BLayoutItem*) const'
    float    ItemWeight(BLayoutItem* item) const;
             ^~~~~~~~~~
/boot/system/develop//etc/makefile-engine:300: recipe for target 'objects.x86-cc8-release/ConversationView.o' failed
make[1]: *** [objects.x86-cc8-release/ConversationView.o] Error 1
make[1]: Leaving directory '/Opslag/haikuports/haiku-apps/chat_o_matic/work-x86-0.0.2/sources/Chat-O-Matic-0.0.2'
Makefile:4: recipe for target 'app' failed
make: *** [app] Error 2

(irc) DCC/SDCC support

List user's role in info popup

(purple) Implement PurpleNotifyUiOps

Used for info dialogues, and pretty important ones at that.

(irc) CTCP support

Relevant doc: https://datatracker.ietf.org/doc/html/draft-oakley-irc-ctcp-02

People files as contacts

People files could be linked to roster members, though the link might not be as strong as with IM Kit.

Each protocol has its presentable (and less presentable) names, e.g., "Jabber" and "jabber." If a person file is searched for a user identifier for a given protocol, the identifier would be stored in META:$protocolSignature, with the attribute's display name being $protocolName.

When a member is added to, loaded into, or edited in the roster, Caya should first check if there are any people files with the same user identifier; if there isn't, one should be created with as many slots (META:name, etc) filled out automatically as possible, and the file should marked as "created by Caya" with some attribute― let's say it's Caya:own.

If there is one already existent and has Caya:own, all attributes should be overwritten with their new values. If it doesn't have the Caya:own, it shouldn't be edited, with the only exception being the profile picture. If the file is empty (has no picture), then the avatar should be copied into the file.

New people files should be put in Caya's config directory somewhere― maybe Caya/People/― so as to not clutter the user's people folder.

Management of these files through Tracker shouldn't be supported with this basic implementation― if a person is deleted, then it'll just be recreated. That would be a little more tricky, and could be done in the future.

Search through chat

Searching through the current chat buffer should be possible (meta-f or menu item).

Since the chat buffer doesn't display all logs, a button should be available in the search dialogue that offers to start TextSearch on the room's cache file (which contains all logs). To complement this, rooms' cache files might want to set their type to text/plain or something similar.

(irc) Send command output to current room (rather than sys buffer)

When a command is sent from the app to an add-on, the sending chat_id is included in the message. This can be used to send command output to the appropriate room, instead of defaulting to the system buffer.

Here's what I'm thinking: two variables, fLastCommand and fCommandRoom, listing the command's string and output room, respectively. A helper function should be able to take fLastCommand in ProcessNumerics() and return if the command is related to the current numeric or not. If yes, print to the fCommandRoom, rather than system buffer. If it's a numeric signifying the end of a message (e.g., RPL_ENDOFWHOIS), then fLastCommand and fCommandRoom are cleared.

(purple) Implement PurpleRequestUiOps

These UI ops are used pretty extensively by protocols and libpurple itself― they're pretty vital, including for certificate validation (see certificate.h).

Permission-list dialogue for users

A more detailed Role dialogue itemizing all permissions granted to a user (as determined by their Role)― everything from PERM_READ to PERM_BAN― might be useful.

This could be accessed as another drop-down menu option, or through a button in the user info pop-up, or even as an element of that info pop-up.

(purple) Handle remote logs

Support per-room user nick

Right now, user objects (including the user itself) can only have one nickname― but for some protocols, like XMPP, where a user can have different handles in different rooms, this isn't the case. Support for per-room nicks would be useful in these cases. Maybe storing users' per-room nicks in a KeyList (while defaulting to the current simple BString) would be a way to go about this.

As for managing the setting of nick in the UI… more thinking needs to be done to that end.

Use keystore for account passwords

Right now, passwords and other "hidden" settings are stored directly in an account's settings file. Instead, "hidden" settings (as defined by the protocol, and likely includes password) should be saved and retreived through the keystore.

OMEMO encryption for XMPP

Please add support for XEP-0384.

These plugins for libpurple may be useful: lurch and libpurple-omemo-plugin (development is stalled).

See also: https://conversations.im/omemo/

Status/Role icons next to usernames

In the UserListView, an icon could be used to signify the user's role/status― the icon would represent the user's Role priority, and it's colour could represent the status. A tooltip would also be convenient to quickly display this information.

Since a role's priority (roughly, its rank in the hierarchy) is completely arbitrary and decided by the plugin, we can't just have X amount of icons and expect them to be used. So either the role icons could be permission-based, with common combinations getting a specific icon― I.E., PERM_KICK, PERM_BAN, and PERM_ROOM_SUBJECT are pretty commonly grouped together, so a specific icon could be used― or the priority could be used. That is, there are X amount of icons included in the program, so the icon used by a priority could be determined proporionately ((X * priority) / max_priority).

The latter might be easier, but definitely less pretty and interesting.

Multiple-room windows

Right now, all conversation views are concentrated in the main window― allowing conversations to be kept in seperate windows might be useful for some workflows.

The way I see it, conversations might be "dragged" from the ConversationList out of a window to create a seperate window, and dragged onto another window to add it to that one's ConversationList. This could let the user group related chats into seperate windows, etc. If a window has only one conversation, no ConversationList should be shown.

Putting new conversations into their own windows should be an option, though by default they should be added to the main window.

Run as daemon

Abstracting important features itself and into a dedicated background process (managing all protocol loopers, etc) might be useful, and allow for some interesting features― like persistant replicants and creating new chat windows when a message is received (even if "Caya" is closed). There should be the option to stop the daemon when all windows are closed, maybe enabled by default.

"Room directory" window

A dialogue containing a "room directory" (list of joinable rooms) might be useful― it could be populated with publically available rooms (like IRC and Matrix), and in the case of libpurple, it could be used to list ChatBuddies (joinable-but-not-quite-joined rooms, according to the client) associated with the current account.

It could look similar to the roster dialogues― focus is a list, bottom-left corner has an AccountsMenu, bottom-right corner has a "Join" button for the selected room. IM_GET_ROOM_DIRECTORY and IM_ROOM_DIRECTORY could be used as the im_whats. IM_ROOM_DIRECTORY might contain the chat_id, chat_name, user-count, and potentially a room-description.

Per-account menubar items

ChatProtocol::MenuBarItems() should actually be used to populate a dedicated protocol menu, named either "Protocol" or "$protocolName."

Multiple instances of protocol lead to multiple instances of accounts

If you have, e.g., a version of the IRC add-on in your non-packaged addons directory and a version in e.g. the system add-ons directory, then any IRC accounts will be loaded multiple times, for however many instances of the add-on you've loaded.

Protocol add-ons shouldn't be loaded if another with the same signature has already been loaded.