XSF Discussion - 2017-12-04

  1. Tobias has joined

  2. ThurahT has joined

  3. Alex has left

  4. Tobias has joined

  5. Kev has left

  6. goffi has left

  7. stefandxm has joined

  8. jere has joined

  9. sonny has joined

  10. stefandxm has left

  11. la|r|ma has left

  12. Zash has joined

  13. ralphm has left

  14. nyco has left

  15. nyco has joined

  16. Tobias has joined

  17. jjrh has left

  18. jere has left

  19. jere has joined

  20. la|r|ma has left

  21. la|r|ma has joined

  22. sonny has left

  23. sonny has joined

  24. daniel has left

  25. daniel has joined

  26. Lance has joined

  27. stefandxm has joined

  28. Lance has left

  29. lskdjf has joined

  30. stefandxm has left

  31. sonny has joined

  32. la|r|ma has left

  33. tux has left

  34. tux has joined

  35. efrit has left

  36. jere has joined

  37. jere has joined

  38. daniel has left

  39. daniel has joined

  40. daniel has left

  41. daniel has joined

  42. jere has joined

  43. jjrh has left

  44. sonny has joined

  45. uc has joined

  46. jjrh has left

  47. uc has joined

  48. tux has left

  49. tux has joined

  50. jjrh has left

  51. arc has left

  52. arc has joined

  53. stefandxm has joined

  54. arc has left

  55. arc has joined

  56. arc has left

  57. arc has joined

  58. arc has left

  59. arc has joined

  60. la|r|ma has left

  61. daniel has left

  62. daniel has joined

  63. daniel has left

  64. daniel has joined

  65. daniel has left

  66. daniel has joined

  67. jonasw has left

  68. jonasw has joined

  69. Ge0rG has left

  70. sonny has joined

  71. la|r|ma has joined

  72. daniel has left

  73. Neustradamus has left

  74. daniel has joined

  75. zinid has joined

  76. ralphm has left

  77. Ge0rG has left

  78. tux has left

  79. tux has joined

  80. blabla has joined

  81. blabla has left

  82. blabla has joined

  83. ralphm has joined

  84. valo has left

  85. valo has joined

  86. ralphm has left

  87. Guus has left

  88. Guus has joined

  89. blabla has joined

  90. daniel has left

  91. daniel has joined

  92. Guus has left

  93. blabla has joined

  94. Tobias has left

  95. Ge0rG

    I wonder if it would be a bad idea to ban html-only mails on standards@. It breaks display of quoting badly on text-only MUAs

  96. jonasw

    markup discussions \o/

  97. jonasw

    we haven’t had any for over a week

  98. Ge0rG


  99. Ge0rG

    or markup-meta?

  100. Ge0rG

    I'm actually catching up the Styling thread from three weeks ago.

  101. jonasw

    ah, so maybe using html-only there was an act of irony? :)

  102. Ge0rG

    So far, the html-only mails I've read didn't contribute anything positive to the discussion. If it wasn't for my Council hat, I'd have blacklisted them already.

  103. marc has joined

  104. sonny has joined

  105. Ge0rG

    I'm actually glad that we are getting XEPs that define the visual format of things.

  106. daniel has left

  107. daniel has joined

  108. Tobias has joined

  109. ThurahT has left

  110. Guus has joined

  111. ThurahT has joined

  112. blabla has joined

  113. moparisthebest has left

  114. Ge0rG has joined

  115. moparisthebest has joined

  116. zinid

    yeah, this is very important now, when basic things are borked

  117. intosi has joined

  118. Ge0rG has left

  119. Tobias

    jonasw, using the Nickname as source of coloring would have other issues, like when somebody else joins a room with the same nick they'll get the same color, suggesting to the user that they are the same

  120. zinid has left

  121. zinid has joined

  122. Ge0rG

    hey marc, any news from your XEP?

  123. Ge0rG

    zinid: why don't you volunteer some time and actually improve the protocols, then? :P

  124. zinid

    Ge0rG, typical open-source nerd detected 🙂 If you don't have the feature: write it!

  125. jonasw

    Tobias, we have that problem with anonymous MUCs in any case

  126. zinid

    while you can act like this (many do) you will end up with no users of your standards eventually

  127. Tobias

    true..so maybe in that case they should be all colored the same?

  128. sonny has joined

  129. jonasw

    Tobias, that’s what is specified now

  130. Tobias


  131. daniel

    zinid: I didn't think much about any namespace issues with the retry element. I guess I can move it around.

  132. Guus

    https://motherboard.vice.com/en_us/article/595zg5/sopranica-jmp-wom-cell-network-diy-anonymous seems to be xmpp based.

  133. zinid

    daniel, I'm concerned because ejabberd has validation mode now, and I don't know how to validate unknown elements or attributes

  134. zinid

    the mode is optional

  135. daniel

    zinid: yes I'll add it beneath the iq then. I just didn't think about validation. In fact this can probably cause issues in other implementations as well. (just due to a lack of a getExtension method for the error class)

  136. zinid


  137. Ge0rG

    "the web address in your Jabber ID will be different—for example, motherboard@jabber.ccc.de or motherboard@xmpp.jp." That made my eyes bleed.

  138. marc

    Ge0rG: no not yet (XEP)

  139. Ge0rG

    marc: I'd really like to tear it apa.. eh.. I mean.. provide some constructive feedback

  140. marc

    Ge0rG: let me check if I have Git access at the moment

  141. Ge0rG

    Guus: that's an interesting article about an interesting tech. I remember there was an announcement of the JMP service on one of our MLs two months ago or so

  142. Ge0rG

    But I didn't realize it's more than just a VoIP bridging service.

  143. Guus

    Ge0rG: I kind of had the same experience

  144. Guus

    also: be nice to marc.

  145. Ge0rG

    I'm interested in adhoc 3G infrastructure for a completely different project, but now I forgot the MUC JID :(

  146. Guus

    bookmarks! :D

  147. tux has joined

  148. Ge0rG

    Guus: I've stored it in PEP, but then it was gone after a server upgrade!!!!1!

  149. Guus

    oh no! you did a _server upgrade_ ?!

  150. jonasw


  151. Ge0rG

    Guus: I did a _server_ _upgrade_!

  152. jonasw

    Guus, we’ll be nice to marc :)

  153. daniel has left

  154. daniel has joined

  155. Guus

    I see we're back to the markup fun :)

  156. Guus

    thanks Jonas :)

  157. goffi has joined

  158. Ge0rG

    jonasw: I'm not sure whom you mean by "we"

  159. Guus takes out his trusty smelly trout and eyes Ge0rG...

  160. Guus

    (mIRC references are one step down from bash.org quotes, right? :) )

  161. Ge0rG

    Guus: you may only swing the trout from mIRC32.exe

  162. Ge0rG

    Guus: unless you have screenshots of connecting to this MUC from mIRC, I won't take any damage.

  163. moparisthebest has joined

  164. Guus

    Ge0rG: although that does sound like fun, I really should stop procrastinating :)

  165. waqas has left

  166. waqas has joined

  167. Ge0rG

    So I found some references to jmp.chat on the archives, but only from Denver's "signature"

  168. waqas has left

  169. daniel

    > https://motherboard.vice.com/en_us/article/595zg5/sopranica-jmp-wom-cell-network-diy-anonymous seems to be xmpp based. Are the Americans reinventing freifunk?

  170. Ge0rG

    daniel: it rather looks like SIP and picocells

  171. SouL

    You can join discuss@conference.soprani.ca if interested on that

  172. daniel

    picocells as in 4G? are you allowed to run those in the US?

  173. marc

    Ge0rG, https://git.zapb.de/xeps.git/log/?h=user_invite_public

  174. marc

    Ge0rG, as I said, just the protocol examples

  175. Guus has left

  176. Ge0rG

    daniel: if you are a telco and have the frequencies, then yes.

  177. daniel

    ok. i'll put it into my not gonna happen box

  178. Guus

    Is anyone going to the Paris Open Source Summit this week? https://wiki.xmpp.org/web/POSS_2017

  179. Steve Kille has left

  180. Ge0rG

    SouL: that's what I was looking for, thanks

  181. Ge0rG

    > fatal: unable to access 'https://git.zapb.de/xeps.git/': server certificate verification failed. Meh.

  182. Steve Kille has left

  183. Ge0rG has left

  184. jonasw

    Ge0rG, pluralis majestatis

  185. jonasw

    or so? ;-)

  186. Ge0rG

    jonasw: I didn't dare to suggest that. But it's probably better than personality disorder.

  187. Ge0rG has left

  188. jonasw


  189. Steve Kille has joined

  190. jonasw

    no, you’ll also be nice to marc *waves hand*

  191. Ge0rG has left

  192. marc

    Ge0rG: it works, it uses LE

  193. marc

    Must be a problem on your side ;)

  194. Guus has left

  195. Ge0rG has left

  196. ralphm has left

  197. Ge0rG

    marc: did you forget to add the cross-signed "root" cert to the chain?

  198. Ge0rG

    Chain of trust NOT ok (chain incomplete)

  199. marc

    Ge0rG: not that I'm aware of. It works on all clients for me

  200. Ge0rG

    marc: it's apparently not in the Root CA list on my old-ish Debian box

  201. moparisthebest has joined

  202. arc has left

  203. arc has joined

  204. marc

    Ge0rG: oh you're right 😬

  205. marc

    Remove the 's' for now then ;)

  206. moparisthebest has joined

  207. Ge0rG

    marc: https://git.zapb.de/xep.git/? 😀

  208. Ge0rG

    marc: I'm not removing the _other_ s.

  209. marc


  210. marc

    You have to wait with your "feedback" then ;)

  211. Alex has joined

  212. Ge0rG

    jonasw: I consider it nice to think through what another person suggests and to make constructive feedback. I also consider it nice to not steal people's time by adding large amounts of boilerplate text that simulates politeness, instead just jumping to the point. For reasons beyond my comprehension, people call me blunt and negativistic.

  213. SouL


  214. Zash has left

  215. Zash has left

  216. Zash has joined

  217. Steve Kille has left

  218. Ge0rG

    marc: the git:// URL is also a lie :(

  219. Guus has left

  220. Ge0rG

    daniel: oh, no 3G... "WOM is XMPP over chibiArduino (thin messaging on IEEE 802.15.4)"

  221. marc

    Ge0rG: fixed

  222. marc


  223. Ge0rG

    marc: thanks very much :)

  224. arc has left

  225. arc has joined

  226. jcbrand has joined

  227. arc has left

  228. arc has joined

  229. arc has left

  230. arc has joined

  231. arc has left

  232. arc has joined

  233. Guus has left

  234. Ge0rG

    Meh. How do you build html from an xeps/inbox/ file?

  235. jonasw

    Ge0rG, make build/inbox/foo.html

  236. jonasw

    or make inbox-html to build them all

  237. Ge0rG

    jonasw: ah, thanks. That actually makes sense

  238. daniel has left

  239. sonny has joined

  240. Guus has left

  241. Ge0rG

    And once again, I forgot to sql-extract from my backup phone the self-messages I wrote on MIX. :sad:

  242. tim@boese-ban.de has joined

  243. lumi has joined

  244. Guus has left

  245. Ge0rG has left

  246. daniel has left

  247. efrit has joined

  248. moparisthebest has joined

  249. moparisthebest has joined

  250. xnyhps has joined

  251. daniel has left

  252. jubalh has joined

  253. lskdjf has joined

  254. moparisthebest has joined

  255. moparisthebest has joined

  256. Ge0rG has joined

  257. jere has joined

  258. jere has left

  259. jere has joined

  260. Syndace has left

  261. jcbrand has left

  262. Steve Kille has left

  263. Steve Kille has joined

  264. ralphm has joined

  265. jere has left

  266. jere has joined

  267. jonasw

    zinid, FWIW, RFC 6120 schemas are incorrect, so I wonder how much pain you’ll be having with validation.

  268. jonasw

    at least afaict, the schemas do not allow for application-defined-condition in the error element, despite the text explicitly allowing that

  269. jonasw

    also, the text allows for the use of the "code" attribute for compatibility, but the schema does not

  270. zinid

    jonasw, I can leave with this and fix the validator accordingly

  271. zinid

    what I don't want is doing this constantly

  272. jonasw

    you may also be in violation of RFC 6120, because servers must simply route traffic addressed to clients (independent of their understanding), but I don’t have a quote for that right now

  273. zinid

    yeah, and in another place the RFC says you MAY validate, go figure

  274. jonasw

    I understand your general concern, but ignoring undefined attributes and elements is essentially how extensibility in XMPP works.

  275. Guus has left

  276. zinid


  277. zinid

    this is not how it should work, because there simply can be tag names collisions if we allow adding whatever anyone wants

  278. jonasw

    no, that’s why we have namespaces

  279. jonasw

    a namespace is defined in a single document

  280. jonasw


  281. Guus

    for what it's worth, people in here repeatedly repeat that "schema's in XEPs are not normative" - Best beware to depend on them to much.

  282. zinid

    what's the point in this namespace if anyone can extend it?

  283. jonasw

    zinid, define "anyone"

  284. Zash

    Pretty sure our equivalent to the robustness principle is "ignore what you don't understand"

  285. jonasw

    the author and maintainer of the namespace can.

  286. nyco has left

  287. zinid

    jonasw, you or me for example, can I use <foo xmlns='jabber:client'> for my extension?

  288. jonasw


  289. jonasw

    well, you can, but that’d be stupid and asking for trouble

  290. zinid

    and <retry xmlns='http:upload:0'>?

  291. jonasw

    and nobody would approve of that

  292. jonasw


  293. jonasw

    unless you’re doing this in context of a XEP-0363 update

  294. zinid

    but you can?

  295. zinid

    you = XSF

  296. daniel

    owning the samespace you must

  297. daniel

    owning the namespace you must

  298. jonasw

    I don’t think that the XSF would approve of a XEP update to any XEP *but* XEP-0363 which extends the http:upload:0 namespace

  299. intosi

    Only the IETF can introduce elements and attributes in the jabber:client xmlns through a replacement RFC, I think.

  300. zinid

    so, that means XSF can add whatever they want, but not others?

  301. jonasw

    zinid, sure, the XSF "owns" the urn:xmpp namespace. that’s the whole point of having a standards organization?

  302. Zash

    It's all in our heads anyways

  303. zinid

    well, of course it's up to you, but I won't change ejabberd validation style

  304. zinid

    as I disagree

  305. moparisthebest has joined

  306. daniel

    Zash, namespaces exists only because people believe in them?

  307. jonasw

    zinid, what would you prefer?

  308. zinid

    bumping namespace obviously

  309. daniel

    and if people stop believe the whole system will collapse?

  310. Zash

    daniel: pretty much

  311. jonasw

    zinid, that’s insanity.

  312. jonasw

    bumping the namespace is a major breakage

  313. jonasw

    also, this is an experimental XEP

  314. zinid

    jonasw, then wait for major breakage and add it in that revision

  315. jonasw

    don’t expect any type of stability in there

  316. zinid

    if this is an experimental xep I don't see a problem in bumping at all

  317. jonasw

    unnecssary namespace bumps are a bunch of the reason why "basic" things like MAM are troublesome.

  318. zinid

    but what do you expect from experimental xep?

  319. Guus has left

  320. Kev has left

  321. Flow

    what I expect from any XEP: no namespace bumps for backwards compatible changes

  322. zinid

    what I expect: the protocol should be formally verified

  323. zinid

    we can debate to death, really

  324. Guus

    This touches on a comment made by Jonasw on list - it's probably not the best of ideas to apply a change when the XEP is in last-call.

  325. daniel has left

  326. Flow

    Then we should write down that rule in xep1

  327. zinid

    yes, the rules are: 1) schemas are meaningless 2) the protocol cannot be formally verified 3) only XSF can add new elements within the same namespace

  328. zinid

    now, implement!

  329. daniel has left

  330. Guus

    Flow: I don't mind clarifying that in XEP-0001, but perhaps we can also simply try to avoid this from occurring, and save the red tape.

  331. Guus

    As the author of the XEP is also on Council, I'm interested in how this plays out though :)

  332. daniel

    zinid: I don't understand why you would want to add new elements with the official namespace. Just use your own

  333. arc has left

  334. arc has joined

  335. zinid

    daniel, not me, but I see this quite frequently among customer's code

  336. daniel

    Is there anything stopping them from using their own namespace besides lack of knowledge (that they should do this)

  337. zinid

    because they don't want to create a namespace with a single element, I think that's their logic

  338. daniel

    i see

  339. daniel

    but you can hardly blame the system or the xsf for that

  340. zinid

    I can use validator to prevent such behaviour among customers

  341. zinid

    which works ideally, they don't even create tickets 😛

  342. Alex has left

  343. daniel has left

  344. valo has left

  345. daniel has left

  346. tim@boese-ban.de has left

  347. moparisthebest has joined

  348. lskdjf has left

  349. lskdjf has joined

  350. Alex has joined

  351. daniel has left

  352. Alex has left

  353. la|r|ma has joined

  354. ralphm has joined

  355. nyco has joined

  356. Alex has left

  357. moparisthebest has joined

  358. jere has joined

  359. jere has joined

  360. moparisthebest has joined

  361. lskdjf has joined

  362. lskdjf has joined

  363. sonny has joined

  364. jere has left

  365. jere has joined

  366. daniel has left

  367. daniel has left

  368. ralphm has joined

  369. la|r|ma has left

  370. daniel has left

  371. lskdjf has joined

  372. lskdjf has joined

  373. Alex has left

  374. nyco has left

  375. nyco has joined

  376. valo has joined

  377. Syndace has joined

  378. Syndace has left

  379. Syndace has joined

  380. moparisthebest has joined

  381. moparisthebest has joined

  382. efrit has left

  383. zinid has left

  384. jabberatdemo has joined

  385. marc has left

  386. nyco has left

  387. daniel has left

  388. Guus has left

  389. Alex has joined

  390. marc has left

  391. nyco has joined

  392. jabberatdemo has left

  393. vanitasvitae has joined

  394. vanitasvitae has joined

  395. Tobias has joined

  396. lovetox has joined

  397. waqas has joined

  398. zinid has left

  399. nyco has left

  400. Guus has left

  401. daniel has left

  402. nyco has joined

  403. Kev

    It's only worth bumping the namespace when interop that wouldn't work without it will work with it.

  404. marc has joined

  405. nyco has left

  406. nyco has joined

  407. jcbrand has left

  408. Guus has left

  409. dwd

    I think it comes down to whether you see XML and XMLNS as a pragmatic solution to permissionless innovation, or as a stick with which to beat people.

  410. dwd

    Not that I'm biased here of course. ;-)

  411. lskdjf has left

  412. lskdjf has left

  413. Guus has left

  414. daniel

    MattJ, jonasw: would you feel more comfortable if retry is a direct child of the iq?

  415. jonasw

    daniel, NO

  416. jonasw

    that violates RFC 6120

  417. MattJ

    iq can only have one child

  418. jonasw

    please don’t do that

  419. jonasw

    what you’re doing now is fine with RFC 6120, albeit weird usage of the "condition"

  420. MattJ

    daniel, do you have an objection to just using the error type for this information?

  421. daniel

    MattJ: yes. I want to know _when_ I can retry

  422. daniel

    This could be seconds or hours

  423. jonasw

    daniel, hm, how would the server know when the client can retry?

  424. daniel

    Depending on implementation

  425. jonasw

    quota cleanup cronjob something?

  426. dwd

    MattJ, Well. Errors can have two, actually. Sort of.

  427. Zash

    Could this not be in a custom element next to the error?

  428. MattJ

    dwd, ?

  429. daniel

    jonasw: we are taking about quotas like only x MiB an hour

  430. dwd

    MattJ, Error + original request.

  431. jonasw

    daniel, well, actually, you could in fact make this a child of <iq/>, but I would consider that abuse. normally an error IQ only returns the original data, if anything

  432. Zash

    I haven't looked at whatever this <retry> thing is closely enough yet

  433. daniel

    Jabber.at is doing this

  434. Guus has left

  435. SamWhited has left

  436. Zash

    a "application-specific condition element" ala retry-after t=x

  437. Guus has joined

  438. jonasw

    daniel, FWIW, I’m fine-ish with this being a child of <error/>. I find it a bit weird, though. Maybe wrap it in a <quota-exceeded xmlns="http-upload"/> thing first? Then there would be an actual condition, with additional information on when to re-try. It also allows to re-use the <retry/> for other possible conditions (like <ebusy/> or so)

  439. daniel

    then i have to define every possible error condition instead of relying on normal errors + text

  440. jonasw

    daniel, good point

  441. MattJ

    It seems like this is a specific case though, not something that could be combined with every other error

  442. pep.

    I'm curious what's wrong with defining errors and not just dumping text

  443. jonasw

    pep., you need to foresee every possible condition

  444. pep.

    Can you not extent it later?

  445. daniel

    pep., we already have a huge bunch of 'predefined' errors

  446. jonasw

    pep., maybe first read up on the context; in this case, it’s about annotating errors with a time at which the client may re-try

  447. pep.

    jonasw, yeah I need to read stuff

  448. daniel

    jonasw, if anything i could wrap it in something like <temporal-error><retry/></temporal-error> (working title)

  449. jonasw

    daniel, as I said, I’m fine-ish with <retry/> as child of error. it feels weird, but I’m fine-ish with that.

  450. jonasw

    well, that’s not usefull at all, leave it as child of <retry/> in that case, because that’s realyl just saying "this is *really* a type='wait' error, no kidding" :)

  451. jonasw

    I have a larger problem with making substantial changes after last call begun :/

  452. Zash

    <error type='wait'><resource-constraint/><text>You exceeded the quota, try again in an hour or so</text><retry-after stamp="YYYY-MM-DDTHH:MM:SSZ"/></error> ?

  453. jere has left

  454. jere has joined

  455. daniel

    i disagree with that being a substantial change

  456. jonasw

    daniel, in hindsight, it probably was. see the amount o fdiscussion it caused.

  457. jonasw

    I also probably meant "non-editorial changes" instead of "substantial changes"

  458. marc has left

  459. stefandxm has left

  460. stefandxm has joined

  461. pep.

    hmm, https://xmpp.org/community/mailing-lists.html, there's a members@ somewhere?

  462. pep.

    Also https://xmpp.org/about/xsf/members.html doesn't seem up-to-date, anybody knows since when? So I can PR (if I find out who's been accepted and who hasn't)

  463. mathieui

    you’re automatically subscribed if you become a member afaik

  464. pep.

    Ok. Can you give me a header I can filter on? I usually use List-ID

  465. Guus has left

  466. jonasw

    pep., haven’t you been subscribed already?

  467. jonasw

    List-Id: XSF Members <members.xmpp.org>

  468. jonasw

    or wait, your election is still upcoming? I don’t konw

  469. pep.

    I have no email coming from members@

  470. pep.

    Maybe it's still not done yet, we'll see

  471. mathieui

    pep., it’s not done yet

  472. pep.


  473. mathieui

    it’s finalized on the 7th I think

  474. jonasw

    2017-12-06 is the meeting

  475. moparisthebest has joined

  476. Guus has left

  477. moparisthebest has left

  478. moparisthebest has joined

  479. daniel has left

  480. ralphm has left

  481. daniel has left

  482. Alex has left

  483. marc has joined

  484. Neustradamus has joined

  485. Guus has left

  486. la|r|ma has joined

  487. pep. has left

  488. pep. has left

  489. Alex has joined

  490. Guus has left

  491. edhelas

    daniel would it be possible to see if we can figure out the usage of SIMS in Conversations https://github.com/siacs/Conversations/issues/2637 ?

  492. daniel

    What particular feature do you need edhelas?

  493. edhelas

    basically that when Conversations upload a file it embed it using SIMS to the message, and not only OOB

  494. edhelas

    this allow other clients like Movim to have a bit more metadata about the file and create a nice thumbnail

  495. SamWhited

    I think I've asked like three times (sorry, I promise to write it down this time) but what was lacking from SIMS that OOB has that conversations uses?

  496. Kev has left

  497. lovetox


  498. lovetox

    it was just there before

  499. daniel

    edhelas, mind giving me an full example of a message stanza you want me to create?

  500. Zash

    Is this going to be another one of those times where the better solution dies because an okayish method already existed?

  501. lovetox

    edhelas, i would also implement this in gajim

  502. edhelas

    that would be awesome

  503. pep.

    Zash: first come first served

  504. lovetox

    but only for httpupload in short term

  505. edhelas

    daniel I can if you want, maybe tonight, but basically everything is done here in Movim https://github.com/movim/moxl/blob/master/src/Moxl/Stanza/Message.php#L101

  506. SamWhited

    OOB/SIMS is on my list of "things to deprecate one of", so if everyone wants to go implement SIMS that would make things much easier…

  507. edhelas

    I'm doing SIMS and OOB when publishing and only SIMS when receiving

  508. daniel

    edhelas, so you put the url in the body and then set no begin and end attributes in the reference?

  509. daniel

    and you ignore the XEP MUST implement Jingle File Transfer (XEP-0234)?

  510. edhelas

    that's true, I'll put this begin and end tags

  511. lovetox


  512. pep.

    Jingle-FT in movim when? :-°

  513. lovetox

    i think the xep means OR

  514. lovetox

    i dont see a reason why we have to implement jingle AND httpupload

  515. edhelas

    > This XEP delegates actual transport of the media data to one of the existing file-transfer XEPs. Thus a client supporting this XEP MUST implement Jingle File Transfer (XEP-0234) [2] and HTTP File Upload (XEP-0363) [4].

  516. daniel

    lovetox, are you sure? the <file> element is even in the jingle namespace

  517. daniel

    for what ever reason

  518. edhelas

    so how does it work if I want to embed a file that was just uploaded by HTTP Upload ?

  519. edhelas

    the file is not in my machine, I just have some metadata and a URL

  520. daniel

    edhelas, you tell me. you wanted me to implement the XEP :-)

  521. lovetox

    ah i think the xep just builds up on jingle file transfer negotiation

  522. lovetox

    so you have to implement the negotiation part

  523. SamWhited

    That whole section doesn't make much sense to me, I think it just needs to be reworded.

  524. lovetox

    but do not have to offer the actual jingle transport

  525. lovetox

    instead you put in httpupload

  526. edhelas

    daniel that's all valid questions :) thanks for raising them

  527. daniel

    you also need bob for thumbnails which i find very weird

  528. daniel

    i'm not gonna implement bob

  529. edhelas

    so we need to upaded SIMS, do HTTP Upload AND/OR Jingle FT

  530. daniel

    has *anyone* ever implemented bob?

  531. edhelas

    I do

  532. daniel


  533. lovetox

    no edhelas this xep builds up on jingle FT

  534. edhelas

    to do stickers sharing, the files are small enough to be shared using base64

  535. lovetox

    that does not mean you have to provide a jingle transport like socks5 or whatever

  536. daniel

    well yes. but the counterpart has to be online

  537. daniel

    which doesn't go well with the 'stateless' premise of the xep

  538. pep.

    I know a few people were talking of a jingle component (so server-side), any discussion started on this already?

  539. edhelas

    so we have to tackle again this "file sharing" discussion

  540. daniel

    edhelas, i mean I can totally implement what you are doing in that PHP script you linked earlier. that's like 10 minutes work

  541. daniel

    but i'm really not sure that has anything to do with implementing the XEP

  542. edhelas

    yeah I understand

  543. edhelas

    to br frank I'm using SIMS to pass the metadata of HTTP File Upload to the other JID, that's mostly it

  544. daniel

    edhelas, what meta data are you interested in? mime type and size mostly i would assume?

  545. daniel

    maybe file name

  546. Guus has left

  547. daniel

    by the way I personally also regard resolution (width * height) as a nice to have because that would could allow me to allocate space for this in the UI. which this XEP is not doing.

  548. edhelas

    yup, mime and size as well, I'm not trusting them 100% but they tells me if I need to resolve the HTTP HEADER if I'm interested to build an attachement block to the message

  549. daniel

    so for me SIMS is just not doing the right thing. because i would ignore vast parts of the XEP and couldn't even but some information in there I want to put in there

  550. daniel


  551. lovetox

    sims is just not trying to be a better OOB

  552. daniel


  553. lovetox

    thats why it reuses jingle stuff

  554. daniel

    It's doing something completely different

  555. edhelas

    if we are improving OOB to add those tags I'd be happy

  556. lovetox

    i dont think so edhelas

  557. lovetox

    or at least i dont know how easy we can extend a xep years long in draft

  558. lovetox

    and if its good

  559. SamWhited

    I don't understand what SIMS is trying to be if not a better OOB; I agree that the XEPs focus seems a bit off, but that's fixable

  560. lovetox

    oob has a clear use case, and does it well, you can communicated a uri with a description

  561. lovetox

    really SamWhited ?

  562. lovetox

    you dont see what it trys to do beside adding metadata?

  563. SamWhited

    No, as far as I can tell it's a better OOB except that it focuses on file transfer for some reason

  564. lovetox

    you can share a file with multiple connection points for the receiver

  565. lovetox

    he can choose if he wants to request it via jingle

  566. lovetox

    or httpupload

  567. SamWhited

    Right, and that's all just sharing some metadata about the file

  568. lovetox

    or any other FT method invented in the future

  569. Tobias has joined

  570. SamWhited

    And basically what OOB does except in a more general way

  571. SamWhited

    It's OOB but with arbitrary URIs and some other random metadata

  572. lovetox

    what is the argument? you can add a shittone of stuff to OOB xep then its the same?

  573. SamWhited

    Can you? I don't see definitions for anything like eg. different resolutions of the same file or other things SIMS has

  574. lovetox

    i think we going in circles

  575. lovetox

    frist you tell that you dont understand what sims trys to do

  576. lovetox

    now you tell me oob does not have definitions about file resolutions

  577. daniel

    neither has sims though?

  578. ralphm has left

  579. SamWhited

    It doesn't, and I don't see how these two things are related; you said that SIMS doesn't do the same thing as OOB, and if that's true I don't understand what it does differently. To me it seems like it's just an improved OOB.

  580. lovetox

    daniel i think you can just add more file tags

  581. lovetox

    with different images

  582. SamWhited

    I thought SIMS specifically had that? Maybe I need to read it again

  583. daniel

    within the same reference?

  584. daniel

    how do i match a source and a file then?

  585. lovetox

    nah i think im confusing this

  586. lovetox

    this was 0084 with different avatar sizes or

  587. SamWhited

    Ah yah, this one is just thumbnail. Regardless, it was just an example. "more metadata than OOB" was the point.

  588. lovetox

    yeah ok, but whats bad about this?!

  589. Zash

    It's a pointer.

  590. lovetox

    it tries to be more general and have more info then oob

  591. lovetox

    not just a bit more, WAY more

  592. SamWhited

    I don't really care if we have more or less metadata, I just think we don't need two XEPs that do more or less the same thing

  593. lovetox

    so thats what i asked you 4 minutes ago

  594. lovetox

    18:07:50] ‎lovetox‎: what is the argument? you can add a shittone of stuff to OOB xep then its the same?

  595. tux has left

  596. Guus has left

  597. Zash

    SamWhited: You are giving me the impression that we can never improve on things that already exist, since that would require overlaping protocols for some time.

  598. lovetox

    oob is a easy small xep that lets you share a description and a uri

  599. lovetox

    let it be what it is

  600. Holger has left

  601. daniel

    yes. wouldn't touch oob. if anything we would create a new XEP that is a more streamlined 'here is an uri and here is some meta data'

  602. daniel

    or SIMS can move into that direction

  603. jonasw

    I’d prefer the latter

  604. jonasw

    SIMS seems like nice framework to extend

  605. SamWhited

    I agree

  606. jonasw

    the MUST support Jingle-FT is weird though

  607. jonasw

    I didn’t know about that, maybe ask Tobias what that is about?

  608. Zash

    jonasw: Why is that weird?

  609. daniel

    and the bob thumbnails are even more weird

  610. jonasw

    Zash, Jingle-FT is a rather complex beast, isn’t it?

  611. Zash

    jonasw: If it's basically a pointer to a thing available over Jingle-FT?

  612. jonasw

    it’s not necessarily Jingle-FT, or doesn’t necessarily need to be Jingle-FT

  613. SamWhited

    Jingle-FT and SIMS are completely orthogonal; SIMS isn't a pointer to a Jingle URI, it also lets you have a pointer to an HTTP Upload API, and as far as I can tell could also provide a pointer to "my proprietary thing" URI.

  614. jonasw

    or BOB

  615. daniel

    expect that it says must support jingle ft

  616. nyco has left

  617. daniel

    and it's at least unclear how to do thumbnails without bob

  618. SamWhited

    That seems like it either means "must support using the Jingle FT metadata XML" or "must usupport Jingle FT *or* something else" and it was just poorly worded, but I guess we'd have to ask Tobias

  619. jonasw

    maybe post that to the list, daniel?

  620. SamWhited

    That and the paragraph after it confuse me though, so I suspect we just need section 5.1 reworded for clarity.

  621. lovetox

    im sure tobias just wanted to reuse already definied tags in another xep

  622. lovetox

    instead of reinventing the same tags under a new namespace

  623. daniel

    jonasw, no. i have bigger fish to fry to be honest. things I actually need for Conversations. not saying that i won't implement SIMS but let other people figure out the details

  624. lovetox

    either way i think its no problem to make this jingle agnostic

  625. jonasw

    daniel, but spark the discussion maybe?

  626. daniel

    jonasw, that's gonna get ignored anyway

  627. jonasw

    gotta love your optimism

  628. daniel

    like the one about MAM or the problems I raised with jingle-ft

  629. daniel

    and those are things i actually care about

  630. SamWhited

    MAM is being addressed isn't it? I thought Kev and Matthew responded to that and said they'd get a revision out

  631. Kev

    Hmm? Not reading context, but a MAM update is <> close to the top of my stack.

  632. daniel


  633. Holger has left

  634. nyco has joined

  635. lovetox

    i will post the questions to the list :)

  636. lovetox

    i care about sims :)

  637. Steve Kille has left

  638. Steve Kille has left

  639. jubalh has left

  640. jjrh has left

  641. Steve Kille has joined

  642. lovetox

    do we really need thumbnails?

  643. edhelas

    what I'd also like to see is a way to embed URLs in general to messages

  644. lovetox

    with the metadata i can display some placeholder

  645. edhelas

    like many other messaging solutions are doing now

  646. edhelas

    having a littke thumbnail, description, title (the client will have to resolve thoses)

  647. daniel

    edhelas, isn't that what references is doing?

  648. lovetox

    edhelas thats what the end and begin is for

  649. lovetox

    so you can embed it in a message

  650. edhelas

    let me rephrase that :)

  651. Alex has left

  652. Alex has joined

  653. edhelas

    XEP-0372: reference just gives a pointer to an URI, without metadata

  654. edhelas

    XEP-0066: OOB gives a pointer to a URL with just a description

  655. lovetox

    no, it also tells you where in the text the reference is to be places

  656. lovetox

    no, it also tells you where in the text the reference is to be placed

  657. lovetox

    with beginn and end

  658. edhelas

    XEP-0385: gives all the metadata, but doesn'yt fit well with my usage (URL only)

  659. daniel


  660. daniel

    you probably need a og extension to references

  661. daniel

    like sims but with og data

  662. edhelas

    og ?

  663. daniel


  664. daniel

    which if you have that you don't need sims anymore to cover your usecase

  665. daniel

    because you can put all that into og

  666. edhelas

    kind of yes

  667. edhelas

    also if I could have one generic way to attach thoses things to XMPP messages and/or Pubsub publications (that are actually Atom items as well) that would be nice

  668. pep.

    rrr heroku apps and their lack of tls :(

  669. pep.

    Or people failing to set it up correctly

  670. arc has left

  671. arc has joined

  672. edhelas

    daniel is it something that you'd like to have in Conversations ? URL/file embeding ?

  673. jjrh has left

  674. jjrh has left

  675. daniel

    what do you mean?

  676. edhelas


  677. Steve Kille has left

  678. daniel

    isn't that exatcly would you would og and references for?

  679. daniel

    you'd have a reference that spans the entire url in this case

  680. daniel

    and the og:tile, og:description and og:image

  681. edhelas

    yup, but would you like to implement it in Conversations as well ?

  682. daniel

    in general yes. but i have the blocker not having stanza content encryption

  683. daniel

    and that's not going to be resolved any time soon tbh

  684. daniel

    it's easier for me at this point to generate that information on the receiving end

  685. daniel

    (opt in)

  686. edhelas

    yes I understand

  687. daniel

    also ironically - generating the content on might have some privacy related down sides; but to properly circumvent this you'd have to mirror the image on the sender or else you will be at least leaking the image url

  688. vanitasvitae has left

  689. jjrh has left

  690. Lance has joined

  691. Alex has left

  692. Lance has left

  693. nyco has left

  694. jubalh has joined

  695. nyco has joined

  696. vanitasvitae has joined

  697. lskdjf has joined

  698. ralphm has joined

  699. Ge0rG has joined

  700. jere has joined

  701. Ge0rG has left

  702. Ge0rG has left

  703. arc has left

  704. arc has joined

  705. lskdjf has joined

  706. lskdjf has left

  707. lskdjf has left

  708. lskdjf has left

  709. ralphm has left

  710. lskdjf has left

  711. arc has left

  712. arc has joined

  713. lskdjf has left

  714. lskdjf has left

  715. lskdjf has joined

  716. jubalh has joined

  717. lskdjf has joined

  718. SamWhited has joined

  719. jubalh has joined

  720. jubalh has left

  721. jubalh has joined

  722. daniel has left

  723. lskdjf has left

  724. ralphm has left

  725. la|r|ma has joined

  726. lskdjf has left

  727. sonny has joined

  728. lskdjf has left

  729. zinid has left

  730. la|r|ma has joined

  731. daniel has left

  732. marc has left

  733. jere has joined

  734. daniel has left

  735. Ge0rG has joined

  736. jubalh has joined

  737. uc has left

  738. lskdjf has left

  739. Holger has left

  740. lskdjf has left

  741. lskdjf has left

  742. daniel has left

  743. ralphm has left

  744. daniel has left

  745. daniel has joined

  746. arc has left

  747. arc has joined

  748. lskdjf has joined

  749. Guus has left

  750. intosi has left

  751. daniel has left

  752. zinid has left

  753. Guus has left

  754. ralphm has left

  755. nyco has left

  756. nyco has joined

  757. daniel has joined

  758. jere has left

  759. jere has joined

  760. nyco has left

  761. nyco has joined

  762. jere has left

  763. jere has joined

  764. ralphm has left

  765. marc has left

  766. Alex has left

  767. Ge0rG has left

  768. arc has left

  769. arc has joined

  770. Zash has left

  771. la|r|ma has joined

  772. jabberatdemo has joined

  773. jabberatdemo has left

  774. ralphm has left

  775. arc has left

  776. lskdjf has left

  777. arc has joined

  778. arc has left

  779. arc has joined

  780. arc has left

  781. arc has joined

  782. arc has left

  783. arc has joined

  784. jubalh has joined

  785. arc has left

  786. arc has joined

  787. la|r|ma has left

  788. zinid has left

  789. jubalh has left

  790. blabla has joined

  791. edhelas

    what is the standard URI format fur Pubsub nodes and items ?

  792. lovetox has left

  793. zinid has left

  794. zinid has joined

  795. marc has left

  796. sonny has left

  797. Tobias has joined

  798. sonny has joined

  799. moparisthebest has joined

  800. SamWhited has left

  801. ralphm has left

  802. marc has left

  803. jubalh has joined

  804. jubalh has left

  805. jubalh has joined

  806. jere has joined

  807. valo has left

  808. vanitasvitae has joined

  809. daniel has left

  810. vanitasvitae has joined

  811. jere has joined

  812. Neustradamus has left

  813. jubalh has left

  814. jubalh has joined

  815. zinid has left

  816. Tobias has joined

  817. daniel has left

  818. Tobias has joined