High level architecture

prose_core_lib

• Provides structs for basic stanzas.
• Supports XMPP concepts like PubSub, IQ request/result.
• Basically provides a meaning for the very few stanza types by looking into their payloads (i. e. distinguishes between Message, ReceivedCarbonMessage and SentCarbonMessage. Also provides a vCard type, etc.).
• Does not enforce correctness of sent or received stanzas, fields of received stanzas are usually optional - this might change over time but seemed easier with my limited XMPP knowledge at this point.
• Although it does parse fields into typed enums where appropriate. E.g. a message kind (chat, error, groupchat, headline, etc.) or chat state (active, composing, …). If the conversion fails the field is currently treated as not being presented.
• Functionality is split up into "modules" for better organization. I. E. connection (sending and receiving pings, initial presence), mam (message handling), caps (sending and receiving Capabilities), roster and so on. The modules are chosen somewhat
• arbitrarily by grouping XEPs with similar functionality.
• Gathering data from the server via prose_core_lib is done in two ways:
  • Either via pull, e.g. loading roster items which translates into a Rust async call (Future)
  • or via push. Aforementioned modules support delegates which are called when an event happens. I.e. the delegate of the profile module supports these callbacks:
    • vcard_did_change
    • avatar_metadata_did_change
    • presence_did_change

prose_core_client

• Uses prose_core_lib internally to send and receive stanzas via push and pull.
• Caches data - regardless whether it was received by push or pull - locally in a SQLite database
  • Some of the data is stored in temporary tables like the presence information of contacts
  • The data is cached in the shape as received by XMPP to make updating easier. A timestamp is added for cache invalidation.
• Mostly hides the XMPP dependency from the outside (with the exception of exposing JIDs) and instead provides Prose domain models. I.e. a roster item that usually only contains a JID, subscription info and groups becomes a "Contact" domain model which is augmented by some vCard data, presence status and an URL to a locally cached avatar image. To form a domain model, data can be loaded from XMPP or be pulled together by joining multiple SQLite tables. Another benefit of providing domain models is that these can be "thinner" or "thicker" (more or less lightweight) depending on the use-case. E.g. a contact in the contact list needs less/different fields than a contact in a user detail view.
• Acts autonomously from its consuming (Swift) client. E.g. it automatically downloads, resizes and caches avatar images when it receives PubSub events. Therefore manages a limited amount of threads itself.
• It provides a (currently) very simple delegate mechanism itself which just sends events when something has changed. Some of these events include ConnectionStatusChanged, UserProfileChanged, AvatarChanged. These events are currently subject to change. The basic idea however is that prose_core_client sends these events over FFI and gives the (Swift) client a chance to fetch the appropriate data from prose_core_client depending on its interface state. E.g. when a user detail view is currently visible it could re-request the user profile data.
• Since it acts autonomously and combines data into domain models, it should allow for the clients (Swift or Android) to be relatively dumb in terms of domain logic and have them focus on UI tasks instead.

prose_core_ffi

• Provides a thin FFI layer over prose_core_client. Hardly anything special going on here.