Sidebar: Contacts management

[valeriansaliou]

• Implement fetching of roster (and refresh the local store w/ added, updated, removed contacts)

  • Description: Roster groups need to be supported, for which we can reserve group name "team" + "others" for "Team members" and "Other contacts". Other group names should be displayed as-is as sections.
  • XEPs:
    • RFC3921: Roster Management — https://xmpp.org/rfcs/rfc3921.html#roster
    • XEP-0237: Roster Versioning — https://xmpp.org/extensions/xep-0237.html
    • XEP-0162: Best Practices for Roster and Subscription Management — https://xmpp.org/extensions/xep-0162.html

• Handle live roster updates from the server when connected (roster pushes)

  • Description: The server may push roster changes whenever the server-side roster gets updated (eg. by another connected Prose app). The local roster store should be updated.
  • XEPs:
    • RFC3921: Roster Management — https://xmpp.org/rfcs/rfc3921.html#roster

• Implement a simple popup to start a new conversation with a target JID (a single JID for now)

  • Description: This comes handy to test messaging w/ different contacts and later test user-info fetching for same-server and federated contacts.

[nesium]

How are we going to handle presence subscriptions?

Since we're working in a team/company environment it would be cumbersome if you'd have to send subscription requests to each of your teammates.

But that's a deviation from the standard XMPP and could only be handled on the server since presence subscriptions are one-way (e.g. both parties have to allow subscription).

[valeriansaliou]

You're right, Prose will come w/ a Prosody server already configured to auto-manage the roster + subscriptions for all @Domain that are the same as yours. So in this regard, we will only have to deal w/ incoming 'subscribe' presence types, which if the user is using a Prose-backed XMPP server configuration would only come from external domains, if the server administrator enabled server to server federation, that is if they opted for the server not to be isolated for security reasons (eg. prevent phishing and scams).

The contact accept/reject interface was designed in this view (in the "invites" tab):