XSF Discussion - 2018-07-06


  1. jonasw

    when receiving a presence subscription without a roster entry existing, the server does *not* create a roster entry as per RFC 6121 § 3.1.3: > Security Warning: Until and unless the contact approves the subscription request as described under Section 3.1.4, the contact's server MUST NOT add an item for the user to the contact's roster. To deny a subscription request, a client uses the flow described in RFC 6121 § 3.2.1+: > If a contact would like to […] deny a subscription request, it sends a presence stanza of type "unsubscribed". Later on in § 3.2.2: > The contact's server then MUST send a roster push with the updated roster item to all of the contact's interested resources, where the subscription state is now either "none" or "to" (see Appendix A). Two questions: 1. This seems inconsistent, because there is no roster item as per § 3.1.3. Am I wrong/missing something? 2. How, if at all, are other resources of the *rejecting* user informed about the fact that the subscription request was rejected?

  2. Kev

    By the roster push.

  3. jonasw

    the roster push for the non-existent item?

  4. Kev

    :)

  5. Zash

    wat

  6. jonasw

    this would effectively create an item

  7. jonasw

    because subscription="none" is perfectly valid for a roster item

  8. jonasw

    and thus be in violation of 3.1.3

  9. jonasw

    and cause all kinds of funny out-of-sync stuff

  10. jonasw

    (if the server doesn’t also add that item)

  11. jonasw

    what do existing servers do?

  12. MattJ

    https://hg.prosody.im/trunk/file/tip/plugins/mod_presence.lua#l163

  13. MattJ

    "FIXME" ;)

  14. jonasw

    this is about unsubscribed, not unsubscribe

  15. MattJ

    Ah right

  16. MattJ

    It looks like we skip the roster push then

  17. Zash

    Can haz The Great Presence State Tests

  18. jonasw

    skipping the roster push is the right thing™ imo (as I said above), but this means there’s no way for resources to know when the subscription request has been denied

  19. jonasw

    except by reconnecting and not receiving the type="subscribe" again

  20. jonasw

    "meh"

  21. flow

    jonasw, write a XEP that will forward the unsubscribe presence to the other resources of the client

  22. jonasw

    flow, so you’d forward a stanza with @to not equal to the clients address to the client?

  23. flow

    I think that would be the first use case where there is a presence in <forwarded/>

  24. jonasw

    what would be the outer thing? message?

  25. flow

    yep, and a special extension element

  26. jonasw

    hurr-durr

  27. flow

    cause onions and their layers are cool

  28. jonasw

    so XEP-0045 apparently suggests to put full JIDs in MUC occupant <item/> info things (e.g. <presence><x><item jid=".../foo"/></x></presence>). do servers include multiple items if multiple resources are connected?

  29. MattJ

    Prosody picks one at random

  30. jonasw

    right

  31. jonasw

    going ahead with the plan of dropping that on the client

  32. MattJ

    Dropping the real JID?

  33. jonasw

    no, dropping the resource

  34. MattJ

    Dropping the resource?

  35. jonasw

    (from the real JID)

  36. MattJ

    Yeah

  37. MattJ

    Resources shouldn't be seen by users anyway :)

  38. jonasw

    it breaks my understanding of aioxmpp’s APIs (which is a weird thing to say as the main dev)

  39. jonasw

    this is not about end-users, but about library users

  40. jonasw

    *shrug* if they want that information they have to sniff the presence stanzas :)

  41. MattJ

    +1

  42. MattJ

    I don't expect much would break if we just made it the bare JID on the server

  43. MattJ

    But not sure I can be bothered to find out

  44. daniel

    Conversations actually utilizes the full jid

  45. daniel

    Because some servers still don't include 110 and then being able to match the full jid is a nice fall back

  46. MattJ

    :/

  47. jonasw

    I refuse to interoperate with those servers.

  48. jonasw

    *sigh*

  49. jonasw

    daniel, do you have statistics how often that occurs and which software versions are affected?

  50. daniel

    Having metrics in Conversations for every time one of my many fun little work around gets triggered would be pretty cool

  51. daniel

    But my audience hates metrics

  52. daniel

    So no

  53. jonasw

    do you happen to know the server which caused you to write the workaround?

  54. jonasw

    I wonder whether I could add scans for such things to muclumbus

  55. daniel

    Well there is definitely more than one. Because 110 is a late addition to 45 AFAIK.

  56. daniel

    There are some servers which don't include it in all circumstances

  57. daniel

    I think ejabberd community didn't include it in error stanzas up until a while ago

  58. daniel

    Ejabberd SaaS doesn't include it in affiliation changes

  59. muppeth

    nyco: about swag. I started a project called aptgetshirt.com while back where we produce (print) shirts and donate 50% of profit to projects. We use water based inks and fair trade (organic) garment as oppose to slave labor zazzle and alike. We thought of running xmpp shirt campaign somewhere around november, since you guys are looking for something we could work together on that. We also start slowly with stickers too.

  60. MattJ

    muppeth, sounds great!

  61. nyco

    Thanks alot @muppeth

  62. MattJ

    <number>102</number> <stanza>message</stanza> <context>Configuration change</context> <purpose> Inform occupants that room now shows unavailable members </purpose>

  63. MattJ

    What

  64. muppeth

    MattJ, nyco: i'll get back to you once we are properly up and running. currently we just re-launched the webshop and selling old stock, plus setting up our own silkscreen studio to cut the costs and be able to produce smaller batches on demand. My jid is muppeth@disroot.org

  65. pep.

    Am I the only one seeing 404.city stuck typing?

  66. MattJ

    You are not

  67. 404.city

    pep., I fell asleep by putting the phone on the key

  68. pep.

    nice

  69. Seve

    :)

  70. pep.

    I was already picturing client bug