Messaging: Base messaging

[valeriansaliou]

• Integrate the messaging Web view from the prose-core-views

  • Description: The messaging Web view is ready, include it w/ static data

• Pass store data to the messaging Web view

  • Description: Pass store data from Swift to the JS runtime. We should find a way to spawn a single WebKit background process and re-use the same view again and again when the user switches conversation, by simply updating the VueJS store in the view (this avoids re-parsing the JS everytime).

• Ability to send simple text messages and receive them from the network

  • Description: Send messages w/ the chat type over XMPP, and receive chat messages back.
  • XEPs:
    • RFC3921: Exchanging Messages — https://xmpp.org/rfcs/rfc3921.html#messaging
    • XEP-0308: Last Message Correction — https://xmpp.org/extensions/xep-0308.html
    • XEP-0085: Chat State Notifications — https://xmpp.org/extensions/xep-0085.html
    • XEP-0280: Message Carbons — https://xmpp.org/extensions/xep-0280.html

• Fetch messaging history from the server using MAM (if the server supports MAM) and populate the store

  • Description: Do this upon opening the conversation for the first time since connection broke.
  • XEPs:
    • XEP-0313: Message Archive Management — https://xmpp.org/extensions/xep-0313.html
    • XEP-0441: Message Archive Management Preferences — https://xmpp.org/extensions/xep-0441.html

• Support message reactions

  • Description: The WebView should contain a button (on hover?) to add a reaction. Clicking the button would show a native menu. We'd start with UTF emojis only (no user-customized). Maybe a set of 10-20 something emojis would suffice as a start before with go all in with an emoji picker that has multiple pages and a search bar.
  • XEPs:
    • XEP-0444: Message reactions — https://xmpp.org/extensions/xep-0444.html

[RemiBardon]

Ability to send simple text messages and receive them from the network

is done, but I don't know if all XEPs are implemented

[nesium]

I haven't done anything about Message Carbons yet. My understanding is that the client can just enable/disable this and the server manages the distribution. But I'll read that XEP once again and add a method for toggling the functionality.

[valeriansaliou]

From what I recall from the times I implemented it (my memory might be spotty), it addresses the issue where:

1. You'd have two XMPP clients running at the same time, and you'd actively use one;
2. The other parties you're chatting with are sending messages directly to your JID user@server.tld/used-client-resource; which means that the other client you're not using (but which is connected), would not get the messages (it would be available in MAM, but the message history would not appear in realtime if it had the same chat open).

It needs to be opted-in by the client interested in receiving carbons, because not all clients support that and it's resource intensive for the server.

The XEP says:

At the time of original writing of this XEP, many XMPP servers handle message stanzas sent to a user@host (or "bare") JID with no resource by delivering that message only to the resource with the highest priority for the target user. Some server implementations, however, have chosen to send these messages to all of the online resources for the target user. If the target user is online with multiple resources when the original message is sent, a conversation ensues on one of the user's devices; if the user subsequently switches devices, parts of the conversation may end up on the alternate device, causing the user to be confused, misled, or annoyed.

Therefore carbons allow those resource-addressed messages to be forward to other connected apps.

This is from what I recall.