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 Right.
  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 Nope
  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 Haha
  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 https://xmpp.net/result.php?id=25275
  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 https://xmpp.net/result.php?id=25097
  129. intosi Etc.
  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 hi
  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 ^to
  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 t
  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 Hmm.
  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 right
  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 aye
  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 Thanks.
  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 AFAIK.
  290. Tobias k
  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