XSF logo 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 meta-markup.
  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 great
  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 right
  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 s/upgrade/restart/?
  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 :P
  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 Haha
  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 Sorry
  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 no
  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 (roughly)
  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 no
  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 same
  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. cool
  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 nothing
  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 daniel
  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 weird
  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 *put
  551. lovetox sims is just not trying to be a better OOB
  552. daniel Sure.
  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 gf
  660. daniel you probably need a og extension to references
  661. daniel like sims but with og data
  662. edhelas og ?
  663. daniel http://ogp.me/
  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 https://a.slack-edge.com/66f9/img/api/cnn_embed.png
  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