like /msg buddy/phone
Currently you can use the /resource set <resource> command.
/msg buddy
/resource set phone
However I've noticed that when the contact's presence changes this is no longer used. I've raised a separate issue for this: #914
I'll keep this issue open to allow your suggestion:
/msg buddy/phone
/msg buddy/phone
Could open a separate window. If resource phone is not available then fallback to old behavior or show error message. Maybe this could help https://xmpp.org/extensions/xep-0296.html
Reading https://wiki.xmpp.org/web/XMPP_2.0 it sounds like resource locking is not a popular idea anymore in the XMPP community.
I'm considering to close this issue ant not implement this for this reason.
I agree with @jubalh here. Most people I know have message carbons so writing to a specific resource is useless.
i second that. While it is nice to see resources and distinguish them, i would not want to write to one exclusively. After all i have no idea which of his four devices my chat partner uses.
Since i consider profanity more of a nerd client i think resources should still be shown, be it only to see if your chat partner uses a new device. could be interesting in OMEMO context too.
So this should be closed to, i guess?
Since i consider profanity more of a nerd client
I could see a way to explicitly send a single message to a given resource, for nerd reasons (like debugging Carbons issues, a hobby of mine for the last decade or so). But that shouldn't entail resource locking and instead default to sending everything else to the bare JID. This could be implemented by means of /msg user@domain/client text
That said, I'm not a profanity user and I'm the most vocal opponent to resource locking :grin:
I think this is not worth the hassle.
People who want to test can use:
/msg buddy
/resource set phone
/resource off
Most helpful comment
Reading https://wiki.xmpp.org/web/XMPP_2.0 it sounds like resource locking is not a popular idea anymore in the XMPP community.
I'm considering to close this issue ant not implement this for this reason.