XSF Discussion - 2017-11-04


  1. marc

    Hey, is somebody working on a XEP for user invitation? (see mod_invite of prosody)

  2. Flow

    marc, MUC invitation? or "roster"? or?

  3. Ge0rG

    marc: have a look at [xep 379]

  4. Flow

    I was just about to mention that :)

  5. Flow

    https://xmpp.org/extensions/xep-0379.html

  6. marc

    It doesn't create an account on a server, right?

  7. marc

    It is just for adding a contact to the roster if I understand it correctly

  8. marc

    mod_invite generates an invitation token and let's an user create an account on a non-public server

  9. marc

    s/let's/lets

  10. marc

    Ge0rG, correct? Just noticed that it's your XEP :)

  11. Ge0rG

    marc: it's right.

  12. Ge0rG

    marc: I'd like to leverage it for account invitations though

  13. Ge0rG

    no idea how

  14. marc

    I'm working on a POC for account invitations and would like to make a XEP for that

  15. marc

    Invitations are too "complicated" at the moment IMO, at least for the normal "whatsapp user" :)

  16. Ge0rG

    marc: so true

  17. marc

    It shouldn' take more than a minute to create an account and start a conversation

  18. marc

    Is somebody on 34c3 for some hacking? Will there be a XSF/XMPP assembly?

  19. Ge0rG

    marc: I think so, there should be something in the SCAM section on the wiki

  20. marc

    Ge0rG, yes, thanks!

  21. Ge0rG

    marc: https://wiki.xmpp.org/web/34C3

  22. jonasw

    marc, I agree

  23. jonasw

    I’d be very interested in your ideas of the flow

  24. jonasw

    ideally there would be something with a token in the URI which allows users to register immediately with a server from within the client even if the server doesn’t allow registrations otherwise.

  25. Ge0rG

    what jonasw said.

  26. Ge0rG

    like a PARS token, but for IBR instead of for presence subscription

  27. Ge0rG

    bonus points for allowing the token to also function as a PARS

  28. jonasw

    yupp

  29. jonasw

    I’d also like to have Pre-Authenticated MUC Join :)

  30. jonasw

    (for members-only MUCs)

  31. Ge0rG

    jonasw: what's wrong with mediated invitations?

  32. jonasw

    when I don’t know the JID yet?

  33. Ge0rG

    oh

  34. Ge0rG

    jonasw: any reason why PARS can't do it for MUC join presence?

  35. jonasw

    Ge0rG, members-only, you’d have to add the user

  36. pep.

    You'd still have to add the user somehow right? To generate the token

  37. jonasw

    pep., no, you generate the token and sedn the token to the user via an out-of-band mean. The whole point is that at the time of invitation, the user might not yet have an XMPP account.

  38. pep.

    Yeah I got that part. nvm I didn't get Ge0rG's sentence in the first place

  39. pep.

    I'd also be interested in whatever this leads to :)

  40. Guus

    One day for the deadline to apply for Board and Council. The current candidacy list is to short! If you're interested, please sign up now!

  41. Link Mauve

    You mean sign up tomorrow?

  42. marc

    jonasw, done ;)

  43. Ge0rG

    jonasw [13:38]: > Ge0rG, members-only, you’d have to add the user The user adds the token to the join presence and is added instantly

  44. marc

    If I have some time these days I'll make a small video of how it works (implemented in Gajim+Conversations)

  45. marc

    And ejabberd

  46. Ge0rG

    What's the membership election deadline? I don't want to risk getting kicked out of council because I forgot my membership application

  47. Ge0rG

    marc: of how what works?

  48. marc

    Well, still some missing parts and all very hackish but the idea should work very well

  49. marc

    Ge0rG, the invitation "flow" :D

  50. Ge0rG

    marc: yay for more "Easy XMPP"!

  51. Guus

    Ge0rG: November 21st

  52. marc

    Yes, I would really see "easy xmpp"

  53. Ge0rG made some videos of PARS back then

  54. Ge0rG

    marc: that's also a category on the wiki

  55. marc

    Otherwise XMPP will never be accepted by end-users

  56. Ge0rG

    marc: that's what I'm saying for years now

  57. marc

    Ge0rG, I guess you'll help me with my XEP and the implementation then ;)

  58. Ge0rG

    marc: yes I will.

  59. marc

    Ge0rG, nice :)

  60. Ge0rG

    marc: also related https://github.com/ge0rg/easy-xmpp-invitation

  61. marc

    Ah cool

  62. marc

    QR codes are nice for invitation, I already use it

  63. Ge0rG

    marc: I think we can extend the http invitation link with an account creation token that allows you to register on a specific server

  64. marc

    Yes

  65. marc

    I already have this somehow

  66. marc

    Afk, Ge0rG looking forward to work with you on this topic :)

  67. Ge0rG

    I wish I had more time to actually implement things in yaxim

  68. jonasw

    Ge0rG, now I get it, right

  69. jonasw

    requires support by the MUC service

  70. jonasw

    and PARS needs some more acceptance

  71. Ge0rG

    jonasw: yes, do you see another way? Additional handshake with the inviting client?

  72. jonasw

    Ge0rG, no

  73. Ge0rG

    jonasw: PARS is blocked by lack of private pep storage

  74. jonasw

    *in prosody

  75. Ge0rG

    jonasw: in one of the widely deployed OSS servers

  76. jonasw

    yes

  77. jonasw

    I’m also not convinced that PEP is the right place for this.

  78. jonasw

    I mean to push the topic further soon, I’m still lagging behind from vacation.

  79. Ge0rG

    jonasw: whatever works on prosody 0.10 and will convince daniel is fine with me

  80. Ge0rG

    jonasw: bonus points for solving MUC and account creation invitations in the same track

  81. jonasw

    not sure this shouldn’t be different XEPs

  82. jonasw

    but I think people complained that yet-another-custom-IQ-protocol is not desirabel

  83. Ge0rG

    jonasw: as opposed to what?

  84. jonasw

    private PEP

  85. Ge0rG

    Right

  86. jonasw

    I re-read the thread from april

  87. jonasw

    I think the arguments for private PEP are convincing

  88. jonasw

    (it allows easy client-side handling and server integration at the same time)

  89. jonasw

    it would be great to have the token in the roster, too.... that’d allow clients to purge all entries created by a certain token

  90. Ge0rG

    The only issue I have is the "unlimited count" for pars tokens

  91. jonasw

    unlimited count is fine for me.

  92. Ge0rG

    I can live with it, and having it in the roster is a great idea

  93. jonasw

    lovely roster extensions which break things

  94. jonasw

    #mix

  95. jonasw

    pity people didn’t follow my suggestion for generic roster extensions

  96. jonasw

    that would be handy now

  97. Ge0rG

    I wanted to have some identifier for auto added roster items, the token can well be used for that

  98. Flow

    jonasw, why roster extensions when you can use private PEP?

  99. jonasw

    different things

  100. Ge0rG

    Flow: do you want to duplicate the roster structure in pep?

  101. Flow

    like a private PEP shadow roster with all you metadata from the extension

  102. Flow

    Ge0rG, possibly

  103. Flow

    I'm not 100% decided which approach is better

  104. jonasw

    Flow, would probably work, yeah. except that you’d really want multiple items in that and PEP services aren’t good at that

  105. Flow

    but then again, thinks will probably break if you extends the roster

  106. Flow

    *things

  107. jonasw

    I doubt that they will

  108. Flow

    so there is only this approach left

  109. jonasw

    adding elements in foreign namespaces shouldn’t break things.

  110. jonasw

    or the approach the MIX people went for

  111. jonasw

    which is equally bad or even worse

  112. Kev

    Roster extensions are a sensible thing that we've been talking about for about a decade.

  113. jonasw

    Kev, why don’t we have them and why is MIX inventing its own probably not really extensible protocol for that?

  114. Kev

    1) Reasons 2) I'm not sure what you're suggesting as the alternative. MIX is injecting a roster extension.

  115. Ge0rG

    If we do roster extensions, can't we put MUCs there too?

  116. jonasw

    Kev, re 2: right, I was confused I think

  117. Kev

    Off out, back later.

  118. Flow

    jonasw, I think that it will cause a lot of trouble if clients see entities in the roster but don't understand the metadata found in the extension

  119. Flow

    or maybe no trouble, but confusion at least

  120. jonasw

    Flow, right, for PARS tokens it would be irrelevant though

  121. Flow

    jonasw, probably

  122. jonasw

    for sure.

  123. jonasw

    it doesn’t do harm if it’s ignored

  124. Ge0rG

    Flow: do you think it will also break for normal roster items with extensions, as opposed to things like mix?

  125. marc

    Ge0rG, my invitation is based on an adhoc command for token generation, the inviter can chosse contacts to be shared

  126. marc

    these contacts are then added to the roster of the new account

  127. jonasw

    I am now embarrased that I didn’t think of Ad-Hoc commands.

  128. marc

    sounds not too complicated to me

  129. marc

    jonasw, :)

  130. jonasw

    marc, sounds like a solid approach

  131. marc

    jonasw, cool, thanks! So I'm going to further improve my POC

  132. jonasw

    since the account will be on exactly that server, it can of course handle the presence subcsription, no need for PARS

  133. jonasw

    lovely

  134. marc

    yes

  135. jonasw

    marc, I’ll be happy to proof-read things and guide you through the XEP process.

  136. marc

    and I think there is no privacy implication

  137. marc

    since the inviter could send the jids to the invitee later as well

  138. jonasw

    there may be if the token is lost, in the sense that all contact information which was shared server-side is exposed.

  139. marc

    yes, until the token expires

  140. marc

    jonasw, thanks for the offer!

  141. marc

    but even in this case there is only the information that somebody invited an unknown person and shared some contacts

  142. Ge0rG

    I think all we need is an opaque token, the server can implement any amount of logic when it's passed on

  143. marc

    well, shared contacts could be disabled by the provider if this is an issue

  144. Ge0rG

    And we need a robust out of band mechanism to transport it

  145. marc

    I use XMPP URI and QR codes at the moment

  146. marc

    works like a charm

  147. marc

    this enables me in-app invitation

  148. marc

    as fallback it generates an URL

  149. Ge0rG

    Maybe contact sharing should be separated

  150. Ge0rG

    marc: what's the URI format?

  151. marc

    Ge0rG, well, it's not "defined" but something like xmpp:example.com?account;invite_toke=TOKEN

  152. Ge0rG

    Sounds reasonable

  153. Ge0rG

    Could be integrated into the landing page

  154. marc

    yep, together with the QR code

  155. Ge0rG

    Might need some information about the inviter, but then that's easy to fake

  156. marc

    Well, my idea was, if that's required, that the server provides a simple REST API to gather information about the invitation

  157. marc

    This could be done via the token as well

  158. marc

    Well, for the landing page, of course

  159. marc

    Information included in the URI would be nice but could be faked

  160. Ge0rG

    Invitation links from third party systems are opaque as well, so this is not a priority for me. Having a rest API means we need a way to determine the url from the server name, which is not trivial

  161. marc

    The landing page and the REST stuff is all optional and out of the scope of this XEP

  162. marc

    If the landing page web server is implemented in the xmpp server itself, no REST API etc. is needed

  163. marc

    Just for the case the landing page uses another service like lighttpd

  164. Ge0rG

    marc: then the ad hoc command needs a way to find out the landing page link

  165. jonasw

    can simply be returned in the result IIRC

  166. Ge0rG

    What happens if I send a "chat" message to the full proxy JID of a MIX participant?

  167. jonasw

    Ge0rG, I think it’d behave just like a message sent to the actual JID of a MIX participant, except that it is relayed through the MIX

  168. jonasw

    cf. https://xmpp.org/extensions/xep-0369.html#usecase-user-private-messages

  169. jonasw

    this appears to contains resource locking logic

  170. marc

    Ge0rG, yes, the landing page is returned by the adhoc command

  171. jonasw

    marc, how does the signup work?

  172. jonasw

    in-band or out-of-band?

  173. marc

    Ge0rG, the result of the adhoc command is a landing page URL (optional) and a token

  174. Ge0rG

    I'd just do IBR with an additional field stuffed somewhere

  175. marc

    jonasw, that's not implemented at the moment but I would like to send a field like a captcha

  176. jonasw

    IBR itself doesn’t really allow for custom fields

  177. marc

    really? I thought I've read something about it in the XEP

  178. jonasw

    ah right

  179. jonasw

    data forms may be used instead

  180. jonasw

    lovely

  181. marc

    :)

  182. Ge0rG

    Am I right that with MIX, a MIX-capable user server needs to keep in memory a list of all participants of all MIXes of all its users, online or offline?

  183. jonasw

    Ge0rG, why?

  184. jonasw

    (I don’t think so)

  185. jonasw

    gotta go