XSF Discussion - 2014-03-27

  1. martin.hewitt@surevine.com has left

  2. Lance has joined

  3. Lance has joined

  4. emcho has left

  5. emcho has joined

  6. martin.hewitt@surevine.com has joined

  7. emcho has left

  8. emcho has joined

  9. Zash has joined

  10. martin.hewitt@surevine.com has left

  11. Kev has left

  12. martin.hewitt@surevine.com has joined

  13. martin.hewitt@surevine.com has left

  14. martin.hewitt@surevine.com has joined

  15. Lance has left

  16. Lance has joined

  17. martin.hewitt@surevine.com has left

  18. martin.hewitt@surevine.com has joined

  19. martin.hewitt@surevine.com has left

  20. martin.hewitt@surevine.com has joined

  21. martin.hewitt@surevine.com has left

  22. martin.hewitt@surevine.com has joined

  23. martin.hewitt@surevine.com has left

  24. martin.hewitt@surevine.com has joined

  25. simon@imaginator.com has joined

  26. martin.hewitt@surevine.com has left

  27. Santiago26 has joined

  28. martin.hewitt@surevine.com has joined

  29. martin.hewitt@surevine.com has left

  30. simon@imaginator.com has left

  31. simon@imaginator.com has joined

  32. Tobias has joined

  33. martin.hewitt@surevine.com has joined

  34. emcho has left

  35. emcho has joined

  36. Zash has joined

  37. ralphm has left

  38. Zash has left

  39. Zash has joined

  40. fsteinel has joined

  41. martin.hewitt@surevine.com has left

  42. fsteinel has left

  43. Santiago26 has left

  44. Neustradamus has joined

  45. Laura has joined

  46. martin.hewitt@surevine.com has joined

  47. Zash has left

  48. martin.hewitt@surevine.com has left

  49. martin.hewitt@surevine.com has joined

  50. Ge0rG

    somebody needs to write an anti-spam proof-of-work XEP based on dogecoin for next week.

  51. simon@imaginator.com

    much wow!

  52. Zash has joined

  53. intosi

    Ge0rG: thanks for volunteering :)

  54. Ge0rG

    in the context of http://arstechnica.com/security/2014/03/apps-with-millions-of-google-play-downloads-covertly-mine-cryptocurrency/ it would make a great prank for yaxim :>

  55. Ge0rG

    intosi: I never have written an XEP before, but I would try if there is a "writing XEPs for dummies" kind of resource

  56. Bunneh has joined

  57. Zash

    Ge0rG: Something like {xep 143} perhaps?

  58. Bunneh

    Ge0rG: XEP-0143: Guidelines for Authors of XMPP Extension Protocols is Procedural (Active, 2011-07-08) See: http://xmpp.org/extensions/xep-0143.html

  59. Ge0rG

    Zash: perhaps, yeah.

  60. Ge0rG

    not sure if I will be able to comply with all these points within the next five days, though

  61. simon@imaginator.com has joined

  62. Kev has joined

  63. ralphm

    hey Kev, was missing you here

  64. Kev

    Here now :)

  65. ralphm

    I read back on the room history. Regarding node identifiers, on principle I still believe they should be opaque. I know we have the exception with auto-subscribe / caps. I don't know how that interacts with your ideas.

  66. Kev

    ralphm: Ah, thanks. Opaque to what, thought?

  67. Kev

    To the server or the client?

  68. Maranda has joined

  69. ralphm

    Kev: well, I'm kinda ok if it has some meaning for a particular application

  70. Kev

    I think that's what I'm implying.

  71. ralphm

    but on the protocol level it should remain opaque

  72. Kev

    To the server it's just opaque as always.

  73. ralphm

    ok, just making sure

  74. Kev

    But the applications will construct the nodes in a known way.

  75. Kev

    *node ids

  76. ralphm

    I still have horrible memories of how ejabberd implemented pubsub with node identifiers that included the owner's JID

  77. Kev

    And could use the id of the template node to get the id of the publishing node.

  78. ralphm

    Our usage of pubsub nodes at Mediamatic also gave them an application-specific structure. That's fine.

  79. ralphm

    Problems rise when different applications share the same nodeid namespace, where node identifiers have some meaning.

  80. ralphm

    This is also why I think that eventually you don't want generic pubsub services for such applications.

  81. ralphm

    We started out with one for Mediamatic, too, and quickly reimplemented it as a pubsub 'shell' around some business logic

  82. ralphm

    made my life so much easier

  83. Kev


  84. Kev

    I think your Mediamatic needs were somewhat more advanced than the requirements for this.

  85. Kev

    This is fairly simple "get a bunch of form templates, let people submit completed forms".

  86. MattJ

    The problem is that there's no way for the pubsub service to indicate whether it's suitable for hosting forms

  87. simon@imaginator.com has left

  88. MattJ

    Say I create an XMPP firewall whose configuration is exposed as pubsub nodes, and the node id represents namespaces to filter

  89. Kev

    MattJ: At least for my use case, that's fine. Configuring templates is an administrative function.

  90. MattJ

    That's the problem though, it's fine for you... but there's no way for a client to know when it's not fine

  91. MattJ

    and the form-fillers might find stuff they didn't expect when they look at the node

  92. Kev

    I'm not quite sure I understand the problem.

  93. Kev

    A form-filler will always be OK, because if the templates have been published, the foms will be published OK. Short of much silliness from admins trying to break things.

  94. MattJ

    In your case, yes

  95. Kev

    For a template publisher, I'm not sure that's any different to any other pubsub application. You can't just go publishing to a ~random pubsub service and hope you're allowed to do so.

  96. MattJ

    That's fair enough, yes... but what about form-fillers? Are they also configured with which pubsub services are safe to look for forms on?

  97. MattJ

    Because you mentioned automatically picking them up from disco

  98. Kev

    I'm using the presence of templates to indicate this.

  99. Tobias has left

  100. MattJ

    So the node exists with a name in a certain format *and* the item contains an element of a certain kind?

  101. Kev

    If the node id is in a given format, you can try to request templates from it.

  102. Kev

    If the template then isn't really a template, I guess you're not going to present it to the user, so not being able to publish it is irrelevant.

  103. Maranda has left

  104. Simon has joined

  105. Simon

    Could it be that adium.in has a script auto-checking their server on xmpp.net. EVERY single time I check the wall-of-shame, they are running a test.

  106. Ge0rG

    maybe the last test just never completed?

  107. xnyhps

    I'm not sure I'm comfortable with them using that name...

  108. Zash

    > Test started 2014-03-27 10:00:03 UTC 22 minutes ago.

  109. Simon

    I'm going to presume it's nothing to do with Adium?

  110. xnyhps


  111. xnyhps

    That's adium.im

  112. Kev

    I assumed Simon had just typod :)

  113. Ge0rG

    there is a test going on for adium.in though

  114. intosi

    And it has SRV records for XMPP

  115. Zash

    And is running ejabberd

  116. Simon

    xynhps: what about hell-banning them with a 59minute long test that always results in an F?

  117. xnyhps


  118. Simon

    I'm looking forward to Peter's promised cleanup of https://xmpp.net/directory.php#

  119. Simon

    imho that list should only be for A-grades.

  120. Ge0rG

    no yax.im on that list :(

  121. Ash has joined

  122. Simon

    MattJ: where did you get to with the public server directory that you mentioned during the Portland Summit?

  123. MattJ

    Nowhere I'm afraid, and it's going to be a while till I can resume

  124. intosi

    adium.in test seems to be automated.

  125. intosi


  126. intosi

    That's yesterday, at 10:00 as well.

  127. Ge0rG

    oh, good idea. I will add all my servers for automated tests as well.

  128. intosi


  129. intosi


  130. Ge0rG

    xnyhps: what about monetizinig that as a service? auto-test daily for $5/month?

  131. Simon

    I have a feeling they just want visibility in the list

  132. Ge0rG

    I wonder about adium.in: if StartTLS is required, why are there pre-TLS SASL methods on the list?

  133. Simon

    speaking of service monetisation and my question to MattJ, would anyone be interested in an XMPP component that they could fire off a "authenticate this new user with SMS" iq at, user gets SMS and clicks link, you get a real-ish user proof back from the component?

  134. Ge0rG

    Simon: generally a nifty thing, but not something that I would add to yax.im

  135. xnyhps

    Ge0rG: Aside from visibility, what's the point in scheduled retesting anyway? It's not like the test changes daily and people's configuration probably neither.

  136. Ge0rG

    xnyhps: I have tasked myself with modifying the config once a day, just for the sake of it. Didn't you?

  137. Simon

    I'm going to presume Ge0rG was being sarcastic.

  138. Simon


  139. Ge0rG is in the process of negotiating a good deal for yax.im, even though it is not $19bln

  140. Zash

    Ge0rG: ejabberd being silly? (re pre-tls sasl)

  141. Ge0rG

    Zash: ah, kay

  142. Zash

    With PLAIN before TLS too

  143. fsteinel has joined

  144. Ash has left

  145. emcho has left

  146. Lance has joined

  147. Lloyd has joined

  148. Lance has joined

  149. Ash has joined

  150. ralphm

    Kev: sorry I tuned out a bit, but I have the same concerns as MattJ. Purely conceptually, I don't like the idea of needing a heuristic based on node identifiers with a certain pattern and coincidently having particular types of items.

  151. Kev

    Well, it's not a heuristic, it's an algorithm.

  152. ralphm

    I'm abandoning all pragmatism in my argument.

  153. ralphm

    Kev: I disagree about it being an algorithm.

  154. ralphm

    Ignoring implementation details like generic v.s. app-specific pubsub server, I'd want to just use disco to find out of a thing is what I'm looking for.

  155. Kev

    Which is exactly what happens.

  156. Kev

    Or what I'm proposing.

  157. ralphm

    We used to have a push side in XEP-0030, but abandoned that in favor of pubsub. Going back to the discussion earlier, I might agree that generic pubsub services would need to be able to accept custom node config fields.

  158. ralphm

    Kev: I'm talking about using disco#info to find that a 'form endpoint' or whatever you want to call it.

  159. ralphm

    (... that a node is ...)

  160. Kev

    But we don't have this mechanism.

  161. Kev

    If we had this mechanism, I'd have suggested using it.

  162. Kev

    What we do have is node identifiers.

  163. Kev

    So I'm suggesting we use them to identify nodes :)

  164. ralphm

    Kev: as I mentioned, I am arguing conceptually, and would rather have it work as I describe. If you really need / want to do this in some kind of generic services, we should bring back the ability to set identities on nodes, and/or require that generic pubsub services accept custom form fields for node config (and maybe subscription options,too)

  165. ralphm

    Kev: and obviously, doing it as app-specific pubsub service, it is trivial.

  166. Kev

    I'd quite like if our story as the XSF isn't "XEP-0060 is great, but for even the most trivial real-world requirements, you'll have to hack your service because it's not suitable" :)

  167. Lance has joined

  168. Kev

    What's not clear to me so far is what the problem is with using node identifiers to identify nodes.

  169. Simon

    IMHO XEP-0060 specs even too much - for example specific roles and their capabilities. Much better to leave 60 as a framework and have application specific enhancements in new XEPs that reference 60's fundamentals.

  170. Kev

    I accept that it feels as if you should be able to disco#info stuff to find out more about it, but AFAICS the node identifiers are sufficient for this.

  171. ralphm

    Kev: I agree that the story is not great in this respect. On and off, I've been thinking of an example application to build a tutorial around, and haven't really found a 'good' one.

  172. ralphm

    Kev: the problem with it is that node identifiers are specified to be opaque. If another app has a similar setup, with similar URIs as node ids and the same type of items (xep-0004 namespace, right), what to do? That's why I called it a heuristic.

  173. ralphm

    Simon: we all agree that XEP-0060 has to be split up and I have always promoted a more lenient interpretation of the specs.

  174. Kev

    Another app won't have similar node IDs unless it goes trampling over other people's namespaces.

  175. Kev

    If we're worried about people trampling over namespaces they shouldn't, the same argument applies to all our protocols.

  176. ralphm

    Simon: the roles and all that are not part of the protocol per se, but of business logic of a generic service, maybe.

  177. ralphm

    Kev: except that node identifiers are not specified to hold URIs. Of course the chance of conflicts is almost zero. I just don't like it conceptually. Same with well-known nodes in disco, one of those necessary evils. You do have precedent there, so it probably works fine in practice.

  178. ralphm

    It would be so much better if 'discovery' isn't spread over multiple places.

  179. Simon has left

  180. Kev

    ralphm: Conceptual argument aside, do you have a suggestion of how better to specify this in practice?

  181. ralphm

    Kev: in a generic service as they currently exist, no

  182. Kev

    So the pragmatic thing to do is to continue writing a proposal as I've described it, then?

  183. ralphm

    Kev: yes. I hope I haven't wasted your time.

  184. edhelas has joined

  185. edhelas


  186. Kev

    Thanks. I don't disagree that disco would be nicer conceptually. Just that we've got to work with what we've got :)

  187. ralphm

    and we probably should work on the problems here

  188. fsteinel has left

  189. ralphm

    either by suggesting the practise as a 'best' one, or fixing the expectations of generic services

  190. edhelas

    I think that there's a lot of improves that can be added to Pubsub

  191. Kev

    FWIW, I think doing it 'this way' could be picked up as a best practice.

  192. ralphm

    Kev: my point

  193. Kev

    If you standardise a way of doing pubsub, choose a node prefix, and then append application-specific data to that.

  194. Lloyd has left

  195. Kev

    e.g. we might have all geoloc nodes identified by starting with urn:xmpp:geoloc:repository/ or something.

  196. ralphm

    Kev: we could even easily suggest node identifiers in general being URIs. This is backwards compatible in most real-world cases.

  197. ralphm

    Kev: I'm not sure I agree about that

  198. Kev

    So e.g. if the military wanted to use geoloc, they could use xmpp:geoloc:repository/tanks/goldfish/1 xmpp:geoloc:repository/tanks/goldfish/2 etc.

  199. edhelas

    Kev: are you working on a Pubsub client ?

  200. Kev

    edhelas: Depends what you mean.

  201. ralphm

    Kev: I think that's a bit restrictive and I'd also would expect app-specific node identifiers

  202. edhelas

    I'm looking for clients which implements correctly pubsub to test the compatibility with my project (Movim)

  203. Kev

    ralphm: Maybe geoloc was a bad example. Although it's not entirely clear to me that it was.

  204. ralphm

    Kev: also, we lack a mechanism for searching with patterns in disco

  205. Kev

    edhelas: what does a client supporting pubsub mean?

  206. Kev

    edhelas: Swiften/Sluift have pubsub support that you can use.

  207. edhelas

    that he can discover, read, write on nodes

  208. Kev

    But a generic pubsub client doesn't make a great deal of sense.

  209. Kev

    You can do that with Sluift very easily.

  210. ralphm

    edhelas: that's meaningless in itself

  211. ralphm

    edhelas: clients implement as specific *use* of pubsub

  212. Kev

    edhelas: http://swift.im/blog/swiften-pubsub/

  213. edhelas

    ok thx

  214. Kev

    ralphm: Although my requirement is slightly different to the geoloc example I gave, because of the expected format of items *plus* the semantics in having templates plus completed forms published.

  215. ralphm

    Kev: the thing they push forms too, is that app-specific? If not, why doesn't *that* implement pubsub?

  216. ralphm


  217. Kev

    No, it's all a pubsub service.

  218. Ash has joined

  219. ralphm

    so they don't really use regular form submission, righ

  220. ralphm


  221. Kev

    'regular form submission'?

  222. Alex has joined

  223. ralphm

    normally you request a form (using XEP-0004 protocol), fill in fields and then submit it

  224. Kev


  225. Kev

    Is that true?

  226. Kev

    XEP-0004 doesn't provide a mechanism of requesting a form, or submitting it, AFAIR.

  227. Kev

    Only the format of the form itself.

  228. ralphm

    wait huh?

  229. Kev

    So I'm suggesting that both the empty forms, and the completed forms, are pubsubbed.

  230. ralphm

    oh you're right

  231. ralphm

    it is always part of another protocol

  232. ralphm

    never mind that part

  233. Kev

    So you have a bunch of nodes that are identifiable by their ID that contain templates (empty xep4 forms).

  234. ralphm

    yes, I understand

  235. ralphm

    I was confused with how pubsub uses forms

  236. Kev

    So when a client wants to publish a form, it fills in the template, generates the right ID for the publishing node (by s/template/result/ in the node ID or similar), and publishes. All using xep60.

  237. ralphm

    and who gets those forms?

  238. ralphm

    where is the sub part of the story?

  239. Kev

    Whoever is subscribed to those nodes.

  240. ralphm

    I think I like the general concept here, by the way

  241. Kev

    There's some sort of incident, a user picks the appropriate form to report it, fills it in and presses 'send'.

  242. ralphm


  243. Kev

    Then the relevant incident handler operators will receive the notifications in their clients.

  244. Kev

    And although my requirements are along these lines, it actually works more generally - e.g. you could use this in an application that has users fill out questionnaires, or whatever.

  245. Kev

    So my intention here is that the 'get templates, fill out, submit' bit is standardised through a description of process, and that then the nodes are specified to have a standard and an application-specific part.

  246. ralphm


  247. Kev

    So if you were building a questionnaire application, you might have something like urn:xmpp:pubsub-form-template:isode.com/employeesatisfaction/2014

  248. ralphm

    I'd be happy to give that a thorough run-through, sponsor or co-edit it

  249. Kev

    I think the spec itself is dead simple, because there's no protocol, only a way of generating the right node IDs.

  250. ralphm

    yeah, it is mostly informational

  251. Kev

    So yes, I'm trying to write it up, if you'd like to give it a run-through once I've done that it'd be marvellous please.

  252. ralphm

    but examples would help greatly

  253. Kev

    Yes, I thought about it not being standards-track, but I think it is really.

  254. Kev

    Yes, examples would help. I'm vaguely inclined to clear the first hurdle of Council before I put too much work into it.

  255. ralphm

    you have my no-objection, for what it is worth

  256. Kev


  257. ralphm

    since we are telling people how to use identifiers, it surely is standards track

  258. ralphm

    gotta drive a car

  259. Kev

    Enjoy. Thanks.

  260. ralphm

    catch you later

  261. intosi has left

  262. intosi has joined

  263. Tobias has joined

  264. Jef has joined

  265. emcho has joined

  266. emcho has left

  267. emcho has joined

  268. emcho has left

  269. emcho has joined

  270. emcho has left

  271. emcho has joined

  272. lloyd.watkin has joined

  273. Ash has left

  274. Lance has joined

  275. emcho has left

  276. emcho has joined

  277. lloyd.watkin has left

  278. Lance has joined

  279. edhelas

    I'd like to know if you have a comment to make on the prososal I've made yesterday on this email Tags and Pubsub subscriptions in XEP-0048 (Bookmarks)

  280. Ash has joined

  281. Zash has left

  282. Zash has joined

  283. emcho has left

  284. emcho has joined

  285. Zash has left

  286. Lance has joined

  287. Tobias

    Kev, the wordpress should be editable right?

  288. Tobias

    at xmpp.org

  289. Kev


  290. Tobias


  291. Tobias has left

  292. Tobias has joined

  293. Lance has joined

  294. Kev

    http://doomsong.co.uk/extensions/render/pubsubforms.html is the bare minimum to describe what I've been going on about, I think.

  295. Tobias has left

  296. Tobias has joined

  297. edhelas has left

  298. Zash has joined

  299. simon@imaginator.com has joined

  300. stpeter has joined

  301. emcho has left

  302. Tobias has left

  303. dezant has joined

  304. Laura has left

  305. Laura has joined

  306. Laura has left

  307. Laura has joined

  308. Zash has left

  309. Tobias has joined

  310. Ash has left

  311. martin.hewitt@surevine.com has left

  312. Neustradamus has joined

  313. martin.hewitt@surevine.com has joined

  314. Laura has left

  315. martin.hewitt@surevine.com has left

  316. Tobias

    Kev, what was the XEP that describes JID binding during chat sessions?

  317. mathieui

    Tobias, 296?

  318. Tobias

    -xep 296

  319. Bunneh

    Tobias: XEP-0296: Best Practices for Resource Locking is Informational (Deferred, 2011-08-18) See: http://xmpp.org/extensions/xep-0296.html

  320. Tobias

    mathieui, thanks, i think that is the one

  321. Ash has joined

  322. emcho has joined

  323. emcho has left

  324. emcho has joined

  325. Neustradamus

    http://wiki.xmpp.org/web/Mojo_Lingo_Application_2014 VS http://wiki.xmpp.org/web/Ben_Langfeld_Application_2014?

  326. emcho has left

  327. emcho has joined

  328. simon@imaginator.com

    Well up until recently companies could be members of the XSF.

  329. Kev

    Still can, no?

  330. simon@imaginator.com

    What's the status of the amendment?

  331. Kev

    The change to not allow companies was uncontentious, I think.

  332. Kev

    But bylaw votes need to go through a members meeting.

  333. simon@imaginator.com

    Which is the next summit or ?

  334. Kev

    It's the next members meeting.

  335. Kev

    The summit isn't a members meeting.

  336. Kev

    Members meetings = those things we have four times a year to vote on members stuff.

  337. Lance has joined

  338. simon@imaginator.com

    ah those :)

  339. Kev

    The XEP1 changes are somewhat more contentious.

  340. martin.hewitt@surevine.com has joined

  341. Lance has joined

  342. emcho has left

  343. emcho has joined

  344. martin.hewitt@surevine.com has left

  345. Ash has left

  346. Ash has joined

  347. simon@imaginator.com has left

  348. martin.hewitt@surevine.com has joined

  349. Ash has left

  350. Zash has joined

  351. martin.hewitt@surevine.com has left

  352. Santiago26 has joined

  353. Tobias has left

  354. Tobias has joined

  355. martin.hewitt@surevine.com has joined

  356. emcho has left

  357. emcho has joined

  358. emcho has left

  359. Ge0rG

    is there an XMPP Extensions Editor?

  360. Kev

    A team, even.

  361. Ge0rG

    the link from http://xmpp.org/extensions/xep-0143.html#submit leads to a page not mentioning anybody responsible

  362. Ge0rG

    is there already a candidate for the 2014-04-01 XEP?

  363. emcho has joined

  364. Kev

    Not of which I'm aware.

  365. Ge0rG

    Kev: are you part of the above-mentioned team?

  366. Kev

    I am not.

  367. Lance

    it was decided best for the council and editor team to not overlap

  368. Tobias

    Ge0rG, http://xmpp.org/participate/become-a-member/editor-team/

  369. Kev

    Lance: I don't think any such thing was decided, actually.

  370. Kev

    The opinion was presented, but I don't think there was any formal acceptance of it.

  371. Ge0rG

    Tobias: maybe that page should be linked from xep0143

  372. Lance

    not officially, but that seemed to be the opinion in the air

  373. Tobias

    Ge0rG, maybe...something for the editor team to fix :P

  374. martin.hewitt@surevine.com has left

  375. martin.hewitt@surevine.com has joined

  376. Santiago26 has left

  377. dezant has left

  378. dezant has joined

  379. Santiago26 has joined

  380. martin.hewitt@surevine.com has left

  381. Ash has joined

  382. simon@imaginator.com has joined

  383. Santiago26 has left

  384. stpeter has left

  385. martin.hewitt@surevine.com has joined

  386. ralphm has left

  387. Ash has left

  388. emcho has left

  389. emcho has joined

  390. martin.hewitt@surevine.com has left

  391. simon@imaginator.com has joined

  392. simon@imaginator.com has left

  393. Alex has left

  394. mathieui has left

  395. martin.hewitt@surevine.com has joined

  396. mathieui has joined

  397. martin.hewitt@surevine.com has left

  398. dezant has left

  399. dezant has joined