XMPP Spec managing accounts, roster and presence

[LEDfan]

The XMPP protocol which is being implemented has some special cases which need to be implemented in the Chat app. In this issue I want to discuss how the XMPP protocol should be implemented. I'have made a list of questions along with some information, about how I would implement it. If you don't agree with the questions please respond, otherwise I'll implement it like that.

Accounts

A XMPP account is identified by the jid. Which stands for jabber identifier. It consists of:

• the username
• the servername
• the resource

If your username on facebook is e.g. derpie123 the jid will be:

[email protected]

It must be possible to connect to multiple XMPP servers at the same time.

Roster

On the server there is a contact or buddy list, called the roster. It must be possible to add, remove and edit contacts in this roster from the Chat client.

Should it be possible to sync the contacts in the XMPP roster with the contacts in the Contacts app?

IMO there should be a button (just like the + and attach file buttons) to add a contact from the OC contacts app to the xmpp roster, and vice versa.

When the Chat app is loaded with the XMPP backend enable, which users/conversations should be shown:

1. the users in the OC contacts app
2. the users in the XMPP roster

IMO both users should be shown.

Should it be possible to start new conversation with a random XMPP user which isn't in the XMPP roster?

Again, IMO this should be possible. This mean a new conversation button must be introduced. When clicked an input field should be shown which aks the user 4 things:

• the JID
• the Alias/name
• whether this user should be added to the XMPP roster (A)
  -whetherr this user should be added to the OC Contacts app (B)

If the user deny A and B, the next time the Chat app is loaded this conversation will dissapear. (like in other XMPP clients). If the user accepts A or B, the user will show up when the Chat app is reloaded. When the user shoses A this will also be the case for other XMPP clients.

Note that when a XMPP JID send you a message, this conversations also will be added to the conversation list for this current session. When you reload the Chat app this conversation won't be shown, except when you receive a new message. A add to XMPP roster and a add to Contacts app button must be shown.

Should it be possible to add new users to the XMPP roster?

IMO it should. This means a button add a new contact to the XMPP roster should be introduced.

Presence

Presence means the current status of the user, e.g.:

• available
• away
• busy
• offline

Should it be possible for the user to change its presence status? (just like in other XMPP clients)

When user [email protected] subscribe* to the presence of user [email protected] user tom has to authorize this. In most clients a deny/accept popup is shown.

Should a subscribe to presence button be included in the conversation buttons?

Should the Chat app automatically subscribe to a users presence when the user add it as contact? (most xmpp clients does this)

*this means user [email protected] can see whether [email protected] is online.

cc @jancborchardt @jbtbnl @stefan-niedermann @fossxplorer @wakeup
@jancborchardt maybe you can ping @owncloud/designers?

[stefan-niedermann]

cc @owncloud/designers

[jbtbnl]

So the roster is basically an address book, but only for XMPP contacts? In that case, I doubt whether we want it to be visible for the user. It will only add confusion because contacts' information is stored in multiple places.

Apart from an initial import of existing XMPP contacts, I don't see any benefit to it. Am I wrong?

[jancborchardt]

Well, the »Roster« should just be comprised of the people in the Contacts app which have a Jabber address set. Whenever you add someone to your Buddy list, they should be added to Contacts.

Should the Chat app automatically subscribe to a users presence when the user add it as contact? (most xmpp clients does this)

Yes.

[LEDfan]

So the roster is basically an address book, but only for XMPP contacts? In that case, I doubt whether we want it to be visible for the user. It will only add confusion because contacts' information is stored in multiple places.

It's an address book, created, managad and stored by the XMPP server. It hold your "buddies", which are basically JID's with optional extra information.

Apart from an initial import of existing XMPP contacts, I don't see any benefit to it. Am I wrong?

The roster can be changed by other clients, or the server (e.g. facebook friends)

Well, the »Roster« should just be comprised of the people in the Contacts app which have a Jabber address set. Whenever you add someone to your Buddy list, they should be added to Contacts.

So every time you load the Chat app, the roster and the Contacts app are synchronised?

[jancborchardt]

So every time you load the Chat app, the roster and the Contacts app are synchronised?

Basically that would be ideal, yes. Everytime you open the Chat app, the Chat app should check if there are more (or less) people with Jabber IDs in Contacts.

[jbtbnl]

At first XMPP connection, the Chat app could create a group in the addressbook of the ownCloud user named something like "Chat contacts" and import them all. On every consecutive XMPP login the Chat app can check if there are jabber identifiers that are not yet included in the addressbook, and add them.

Later on we can implement merging with existing contacts.

[LEDfan]

@jancborchardt @jbtbnl new contacts are now saved in the Contacts app (ref #158)
What should happen when a contact is removed from the roster:

1. remove the contact in the contact apps
2. ask for confirmation
3. do nothing

[jbtbnl]

@LEDfan option 3 seems the best. If the user is eager to clean up the address book then a visit to the Contacts app will suffice.

[jancborchardt]

If the contact was created by the Chat app in the first place (and has no other info other than the XMPP handle) then delete it. If it has other info as well or existed before, do nothing.

[LEDfan]

@jancborchardt will do it that way :)

[LEDfan]

@jancborchardt @jbtbnl to keep it simple for now, I won't remove any contacts.

[jbtbnl]

@LEDfan that's fine, it can be implemented later on if necessary.

[jancborchardt]

Yup, sounds fine.