Skip to content

Priorization

Valerian Saliou edited this page Jun 17, 2022 · 11 revisions

This page details all tasks that should be priorized in order to reach a state of MVP.

Steps

The steps that should be taken are described in order below:

Work on the app

Those steps are common to app Prose app platforms, therefore they are defined there, in the common client library.

πŸ‘‰ Note that those steps are tracked as individual issues in the Prose App MVP project.


1. Authentication

1.1. Session lifecycle

  • Improve login (to its final state)

    • Description: The login form could not be implemented to 100% state due to missing server feature.
    • ⚠️ Concerns:
      1. We need to implement a way for tokens to be generated by the server (pretty much like most modern REST APIs work). A token should be revocable from any connected application, eg. if the user lost their device. Not sure a XEP exists for that, in any case we may need to create a Prosody module as well;
      2. Find a clean way to protect account credentials (JID + password) w/ an additional TOTP token (there should be a XEP for that, we also need to look for a Prosody module);
  • Connect using session tokens

    • Description: Re-using the session tokens generated by the server (not possible ATM, see concerns above).
  • Ability to logout and destroy session tokens

    • Description: Ability for the user to remove an account from the Prose app, which would need to destroy the session tokens from the server (not possible ATM, see concerns above).

2. Sidebar

2.1. Contacts management

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

  • 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:
  • 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.

2.2. Current user states

  • Show logged-in user avatar

    • Description: Use User Avatar over PubSub/PEP (the server might not be compatible), do not use vcard-temp with avatars over vcard at all since it's been deprecated for 10+ years even if still widely used by XMPP clients.
    • XEPs:
  • Show logged-in user presence

2.3. Lock some features

  • Grey out the top-left call button

    • Description: Calls will be implemented later.
  • Grey out groups in the roster

    • Description: MUCs will be implemented soon.
  • Grey out the spotlight section

    • Description: Will be implemented soon.
    • Timeline: whenever we implement this, here's the order:
      1. People and groups (backed by the server)
      2. Unread stack (backed from local store after receiving pending messages from the server)
      3. DMs (filtered from local store after fetching all recent MAM)
      4. Replies (filtered from local store after fetching all recent MAM)
  • Grey out account switcher

    • Description: Multi-workspace capabilities TBD, as they may require some extra work on the core-client library.

3. Messaging

3.1. Base messaging

  • 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

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

3.2. Error handling

  • Account offline error banner

    • Description: Whenever the connection broke or is reconnecting (eg. re-opening laptop, waiting for WiFi, server down), show the offline banner (see Sketch designs, will need to be implemented). Still, we should show the offline reason (especially eg. if the server is down and thus we cannot connect at the TCP level).
  • Account error popup

    • Description: Whenever the account cannot be connected-to (eg. invalid password, revoked session token), with a way to recover from this state (eg. try to login again).

3.3. Lock some features

  • Grey out messaging edition features

    • Description: The messaging edition features will be implemented later (right after the first MVP is done).
    • Features:
      • Message formatting controls
      • Attach a file
      • Send a smiley
  • Grey out messaging top bar controls

    • Description: Some messaging top bar controls will be implemented later (right after the first MVP is done).
    • Features:
      • Search field
      • Call button
      • Verified icon next to JID (needs to implement OMEMO et al for that; later)
      • Navigation shortcut buttons (backwards, forwards, history)
  • Grey out user information

    • Description: The user information right sidebar will be implemented later (right after the first MVP is done).
    • Features:
      • (prevent the whole user information bar from being shown, or show it but w/ placeholder data)

4. Preferences

4.1. Account management

  • Implement account management

4.2. Lock some features

  • Grey out all preferences except account management
    • Description: Those preferences will come later, as we need them, and as we figure out whether we should store Prose app preferences somewhere on the server (which is possible), or locally only (eg. dark mode switcher, etc.).

5. Misc.

5.1. Protocol requirements