search

prose-im / prose-app-web

Prose Web application. XMPP client for team messaging.
https://prose.org/downloads
Mozilla Public License 2.0
20 stars 2 forks source link

Last self presence is not restored upon refreshing app #4

Closed valeriansaliou closed 10 months ago

nesium commented 10 months ago

The basic idea is that when I set myself to "Do not disturb" and restart the app, that the app should remember my decision and set me to "Do not disturb" again upon initialization.

Since I can be online with multiple clients at the same time however another idea was that all of my clients observe my status that might be set in a different client and save this locally. So imagine the following sequence:

The more I think about this, the more I lean towards status being something that is tied to a client locally. Because there is also a scenario where a client is not online and does not observe changes in the status of another client. After starting again, it would set its last known local status.

If on the other hand each client can have its distinct status we'd need a FullJID for that again. That would mean that I should roll back my change in the core client and instead of treating the "self contact/profile" as a regular contact it should be its own thing.

Thoughts?

nesium commented 10 months ago

The self-presence could also be a completely local thing so that we don't need a round-trip to the server to reflect the status.

valeriansaliou commented 10 months ago

I came to the same conclusion as yours while implementing Web app self presence management. Each app has its own "last-selected status". We could come up to some server storage (PEP-based?) backed last presence later, which is something I actually did for app settings in the past w/ Jappix. Totally doable but for now let's skip it.

On the full JID thing, if we are to handle presence priorization for display across multiple resources, it will indeed be required to store all full JIDs in a temporary storage instanciated at runtime. I'd recommend re-implementing my TS code from $presence as-is, because I had already taken great care of doing things right & clean w/ this implementation. I've not noticed any bug while testing cross-clients/cross-resources.

Overall, regarding the management of presence priorities, I'd say that mobile apps should always announce a higher priority than desktop apps, such that whenever you open the Prose app on your iPhone it would take over presence context, as that would be the device you're currently active on. Meaning that all C2C IQs eg. Software Information would get routed to the phone instead of the desktop. Mobile should always take over context as if you're online there, it's most certain that you're actively watching at your screen, whereas the same cannot be said about desktop.

nesium commented 10 months ago

So the solution is to revert https://github.com/prose-im/prose-core-client/commit/e86bb10ef0e5d0c3674b89ac8d6f77a94ebf3af7 and 2f04e0c13a8d61a99dd4412fbd61cebeb4553c43 and the web app would take care itself of the selected presence for now?

The Wasm binding already allows for passing in an Availability on connect.

valeriansaliou commented 10 months ago

Exactly, the Web app would store the latest selected presence and restore it upon sending the initial presence (how can I do that, since its show value is abstracted in the core-client library?)

nesium commented 10 months ago

I think we could this two ways, either the web app optimistically saves the Availability (which is an Int enum) that it needs when calling setAvailability on the Client. Or we could also push that functionality into the core, say create a Settings struct and add a method to the DataCache to save it.

We'd need to distinguish between global settings and account settings though. E.g. the selected account is a global setting, while the availability (or presence in XMPP speak) is an account setting.

Speaking of which, the IndexedDBDataCache currently is not set up to handle multiple accounts. The simplest way would probably be to create one IndexedDB per account, so that would be an easy change.