Conversations: reenable custom XMPP resource (2.0.0-beta.2)

[UweSauter]

General information

• Version: 2.0.0-beta.2
• Device: Moto G (peregrine)
• Android Version: LineageOS 14.1 (Android 7.1.2)
• Conversations source: F-Droid

Steps to reproduce

1. update to 2.0.0-beta.2
2. be annoyed that you cannot differentiate your devices any more in desktop XMPP clients

Expected result

Be able to select a predefined or custom resource for each device that runs Conversations.

Actual result

I'm using Gajim on several of my desktops. Before the update I was able to differentiate my Android devices by their resource name that could be set to a predefined value. With 2.0.0-beta.2 the resource is set to "Conversations." + 4 random characters. Between connection attempts, those random characters change, which isn't helpful at all.

[Mrfuyu]

Some decisions made in v2 were a step back in my opinion. :'(
I hope at least this one will be reconsidered.

E.g. new resource naming convention as default but allow setting a custom resource name.

[licaon-kter]

What's the use case exactly here?

[UweSauter]

Identifing your clients if you have several devices connecting to the same account.

As far as I understand, one of the reasons for XMPP resources is that you can chat with either an account, in which case all resources get the messages (at least if carbon copies are enabled, else the client with highest priority).
Or you can chat with a resource of an account, where only this particular resource / client / device will get the messages.
If I cannot identify the resource because it is a random string, then this use case is rendered moot.

See also the official explanation about resources.

BTW: With this use case configurable priorities would be nice as well.

BTW2: And there are many people that have several Android devices so you cannot argue that there will be only one "Conversations.XXXX" resource per account.

[licaon-kter]

So when you talk with someone you don't want to have that chat history on all of your devices, but each one would have a part? I don't understand the usefulness of such a behaviour :-|

Modern servers, imho, should have MAM+Carbons anyway...

[SamWhited]

As far as I understand, one of the reasons for XMPP resources is that you can chat with either an account, in which case all resources get the messages (at least if carbon copies are enabled, else the client with highest priority).

This is not exactly correct. You can build a chat system that works this way with XMPP, but then you would probably want to use information supplied by the client to identify it, not the resource (because the server can always override the resource that the client requests). The resource is just used by the server for routing, it is not necessarily supposed to be a human readable identifier. For that you probably want XEP-0092: Software Version or device type information from XEP-0030: Service Discovery.

All that being said, most chat systems built on XMPP don't do this anyways, you just send a message and get it on all the logged in devices. Conversations is made to work on servers that work this way.

See also the official explanation about resources.

That link is not official, it is also very outdated and somewhat inaccurate (I will attempt to fix it up a little).

[UweSauter]

So when you talk with someone you don't want to have that chat history on all of your devices, but each one would have a part? I don't understand the usefulness of such a behaviour :-|

Modern servers, imho, should have MAM+Carbons anyway...

It might be that not every message is wanted to be logged and distrubuted to all clients…!?!

The resource is just used by the server for routing, it is not necessarily supposed to be a human readable identifier. For that you probably want XEP-0092: Software Version or device type information from XEP-0030: Service Discovery.

So if I understand your POV correctly resources once were used the way I described but this is now discouraged.
Looking at XEP-0092: Software Version I don't see any reason to use this to identify a certain device as the information provided would still be "Conversations Version 2.0.0 Android 7.1.2" for my devices…
Skimming over XEP-0030: Service Discovery example 8 is probably what I'd like to see then, with the possibility to set a custom name.

That link is not official,

Where else would you get official documentation then if not from xmpp.org?

[SamWhited]

So if I understand your POV correctly resources once were used the way I described but this is now discouraged.

Yes, we have better means of getting the same data now; resources were never a good solution because sometimes the server overrides them and they're just random anyways, regardless of what your client asked for.

Where else would you get official documentation then if not from xmpp.org?

The RFCs and the XEPs, but even some of those could use a rework. That is a wiki though, lots of people edit it and it doesn't make whatever they say the truth.

[Mrfuyu]

I use it with an server setup like @SamWhited said, but I would like to configure my resource name manually. I like it because of better looking resource names and to identify my devices (e.g. to see which are online). Why should this setting disturb an user if it is located in an advanced account setting.

[licaon-kter]

@Mrfuyu

to see which are online

This is vapourware in the mobile world as you roam from cell to cell to Wi-Fi, using push for the Play version or periodic refresh for F-Droid. You just send the message and the server takes care of it.

[iNPUTmice]

First of all identifying different clients shouldn’t really be necessary. Most things will just arrive on all resources. That’s the goal Conversations is working to.
In the rare instances where the user does need to decide on a resource (oversized file transfers, or previously OTR messages) Conversations would display kind of device (Tablet, phone, desktop) and if that is not unique enough the client name as well. So like Desktop / Psi. That’s how it is supposed to work and the change on the display side was made two years ago or so. Only that you didn't notice because Conversatios would rarely ask for the resource.

If you don’t like the changes use Conversations Legacy which is currently on it’s way to the Play Store and will probably be available on F-Droid as well.

If you don’t like the changes use Conversations Legacy which is currently on it’s way to the Play Store and will probably be available on F-Droid as well.

[UweSauter]

Just to see if I get you right:
You're discarding a valid use case (targeting individual devices for messages) with the argument that today, everyone wants to receive all messages on all devices? I think that argumentation is a bit too generalized…
I'll have a look at Conversations Legacy once it lands in F-Droid but v2 will be deinstalled on my devices…

[ValdikSS]

@UweSauter, @iNPUTmice Conversations is a program for communications between people, not between connected devices. I argue some @iNPUTmice decisions, but this one I consider sane.
Some XMPP features were designed not for people communications, or before using multiple devices was a common thing, and now are hardly helpful. Minority of people want multiple resources without carbons.

[Mrfuyu]

@iNPUTmice I understand the advantages, but why not a simple setting for this feature in "advanced account settings". Default could be the new resource naming convention, and everybody is happy.

(PS: I also find resources useful to see on which devices my chat partner is active. We use resources in combination with the setting to set the status to AFK if the display is off. What would this setting be for, if I can't determine on what device the user is AFK?)

[mabkenar]

@Mrfuyu:

why not a simple setting for this feature in "advanced account settings". Default could be the new resource naming convention, and everybody is happy.

Because at some point decisions should be made. If there is a sane reason for removing a certain feature to simplify the interface and the workflow, then it should just be removed. Carrying the legacy in the code and adding extra advanced options for features that 99% of people will never use, eventually makes the code an unmaintainable mess. If we want a sustainable software project, such cleanups have to be done.

And in this case, nobody loses anything because they can still use the legacy version if they want. I sincerely applaud @iNPUTmice for his efforts to improve Jabber for everyone.

[SlavekB]

Resource name is nothing more than a simple string - it does not look like "something that requires complex code that is demanding to maintain". The resource name will be used in the code anyway - here is just the question whether it will be set automatically or by the user. For the UI will be sufficient one toggle button "Custom resource name" and a one plain text field where the user can enter what they want. Is that really with demanding maintenance?

I understand that a regular user will not change the resource name. But when a resource can be set up, it is useful for advanced users. Removing resource setting makes "resource" absolutely useless to everyone == this change is not beneficial to anyone at all.

The argument that I can use the Legacy version is valid, but by switching to Legacy, I could not get any more new stuff in this great software. And all because of such a small, unpleasant change :(

[rfc2822]

For me, it's also important to known which resources are on which devices. I send messages from my PC to various JIDs and devices, and when I only want to send to the smart phone of a friend, for instance, I need the resource name.

Also, status comes from various devices, so when a friend is "Online" on one device and "Away" on another, it's important for me to know which device they're "Online" with and where they are away so that I can know where I shall call them etc.

Resource names are in my opinion a substantial part of XMPP and everything has worked with Conversations already. Please reconsider reenabling useful XMPP resource names.

[SlavekB]

It's exactly how write @rfc2822 - resource name is a very important thing for me and most of my jabber friends. For me, it's important to know if contact is at work, at home, on tablet, on mobile, etc. Instead of destroying the option to set up a custom resource name, I'd like to see the resource name in the contact details.

If most users do not know the benefits of using a reasonable resource name, it does not mean that the resource name is not a useful thing. In Conversations, it has become unusable now - when it is not possible to set a reasonable resource name. Please reconsider re-enabling custom resource names.

[matlag]

Use case: I use MAXS, XMPP based tools for Android. Amongst other things, it allows reception and sending of SMS. It has an option to NOT send messages to a list of defined resources, so that you don't get messages for sending or receiving SMS... on your phone's Conversations.
Except I can't and get notified on Conversations for each SMS, call, etc.

[iNPUTmice]

@matlag Conversations’ resources are still fairly stable. You can still enter the resource generated by Conversations in MAXS or what ever.

[dbielz]

I am also quite annoyed to not be able any more to differenciate between different clients. What's the benefit of "getting rid of customizable resources" anyway? One option less in "advanced settings" to prevent advanced users being confused when having a look in advanced settings? well, well, well...
I admit, I still do not see the point. Do you want to educate all users to a certain use?
And to stick to "Conversations Legacy" and refuse upcoming security fixes and feature updates just to keep one single feature? Is that a really serious advice?

[sfjes]

Agree that I would also like to see the setting return under Expert settings. It's true that we can jump through hoops to map the new random resources to meaningful names, but removal benefits no one and hurts many users/use cases.

[keiyakins]

@SamWhited If you're supposed to use Service Discovery for that, then how do I set a human-readable string in Service Discovery? Say you're logged in on your desktop, laptop, phone, and tablet. How can you tell which is which, especially since the first two and last two are likely running the same client?

[SamWhited]

If you're supposed to use Service Discovery for that, then how do I set a human-readable string in Service Discovery? Say you're logged in on your desktop, laptop, phone, and tablet. How can you tell which is which, especially since the first two and last two are likely running the same client?

Because they will report that they are a desktop, laptop, phone, and tablet respectively. The web version of the disco-categories registry doesn't seem to be up to date (eg. tablet isn't there, but it's in the registry), but you can look here for more information: https://xmpp.org/registrar/disco-categories.html

There's plenty enough information avialable to give us a nice string that explains what the clilent is. If more is needed, eg. something the user can enter, we can figure that out too. What it says isn't the important part, we can do whatever we need there.

[rozzin]

@SamWhited wrote:

Because they will report that they are a desktop, laptop, phone, and tablet respectively. The web version of the disco-categories registry doesn't seem to be up to date (eg. tablet isn't there, but it's in the registry), but you can look here for more information: https://xmpp.org/registrar/disco-categories.html

There's plenty enough information avialable to give us a nice string that explains what the clilent is. If more is needed, eg. something the user can enter, we can figure that out too. What it says isn't the important part, we can do whatever we need there.

Not only is "tablet" not there, there also doesn't appear to actually be a distinction between "desktop" and "laptop"--instead just lumping them together as "pc".

I'm not sure I entirely understand the point of this whole "type of hardware" identification--and to the extent that I do understand it, I do somewhat disagree with it.

While hardware-type distinctions like "I am using something with a real 10-finger keyboard" vs. "I am thumb-typing on a touch screen" is useful as a context-descriptor for the other person to form reasonable expectations about why responses are written the way they are (there have been plenty of articles written about "why you should include a `sent from my smartphone' signature on your e-mails, for similar reasons), what sort of depth of response to expect from someone (there's no e-mail analog for this part)..., there are other dimensions that aren't captured by that.

One of the dimensions that's most important to _me_:

• the devices that I leave online somewhere even when I'm not there (e.g.: at home, at an office, as a mostly-headless service running on some server...).
• the devices that are only online if I'm actually using them

And basically I don't see why I need to care about "which class of device" if I already know "which device"; one of them implies the other.

In settings where I've had to use systems that don't support any kind of resource-descriptor (Slack, for example), it's been extremely frustrating both for myself and everyone else when the system conflates "one of my devices is online somewhere, either intentionally or accidentally" with "I am online".

And, I guess I can see an argument that there are (multiple) other ways of conveying that stuff in XMPP (presence state strings, priorities, maybe disco-categories if they're actually either free-form or provide enough specific options).

But where does Conversations actually make _any_ of those things available to the user? AFAICT it _doesn't_ make _any_ of those things available to the user.

Which of those things does Conversations actually give control over? AFAICT none of them--so it's not even meaningful to go on to the next question of `which subset are people using other clients likely to be able to see?' (since it's a null set already).

"Well we don't need that mechanism for that functionality because we could implement equivalent functionality using different mechanisms" isn't really useful until "could implement" changes to "have implemented".

[GigabyteProductions]

Use case: I'm collecting data from an experiment by querying my phone by full JID with resource, but my resource changed as I disconnected from wifi and reconnected on cellular.

[licaon-kter]

@GigabyteProductions I have the same resource for years already. What else changed during disconnect? Account was deleted/readded? App was killed?

[GigabyteProductions]

No longer sure. Server logs imply resource stayed the same. I deleted the account to test re-adding as user@host/resource to no luck, which screwed up that resource.

My point was specifying an exact resource would simplify writing clients that intend to communicate with an exact resource; no surprises.