XSF Discussion - 2017-10-30

  1. daniel has left

  2. daniel has joined

  3. la|r|ma has joined

  4. daniel has left

  5. daniel has joined

  6. la|r|ma has joined

  7. daniel has left

  8. daniel has joined

  9. Steve Kille has left

  10. daniel has left

  11. daniel has joined

  12. daniel has left

  13. efrit has left

  14. daniel has joined

  15. Valerian has left

  16. arc has left

  17. la|r|ma has joined

  18. daniel has left

  19. daniel has joined

  20. arc has joined

  21. lskdjf has left

  22. arc has left

  23. arc has joined

  24. daniel has left

  25. arc has left

  26. daniel has joined

  27. lskdjf has joined

  28. arc has joined

  29. vanitasvitae has joined

  30. daniel has left

  31. arc has left

  32. arc has joined

  33. daniel has joined

  34. daniel has left

  35. daniel has joined

  36. daniel has left

  37. daniel has joined

  38. daniel has left

  39. daniel has joined

  40. tux has left

  41. tux has joined

  42. la|r|ma has left

  43. Arc has joined

  44. daniel has left

  45. uc has joined

  46. lskdjf has joined

  47. la|r|ma has joined

  48. daniel has joined

  49. lumi has left

  50. dwd has left

  51. arc has left

  52. arc has joined

  53. arc has left

  54. arc has joined

  55. arc has left

  56. arc has joined

  57. moparisthebest has left

  58. nyco has left

  59. Zash has left

  60. Syndace has joined

  61. Syndace has joined

  62. daniel has left

  63. daniel has joined

  64. uc has left

  65. uc has joined

  66. Wiktor has left

  67. Wiktor has joined

  68. ralphm has left

  69. zinid has left

  70. zinid has joined

  71. Guus has left

  72. Guus has joined

  73. waqas has joined

  74. waqas has left

  75. waqas has joined

  76. alacer has joined

  77. zinid has left

  78. zinid has joined

  79. alacer has left

  80. alacer has joined

  81. ralphm has left

  82. waqas has left

  83. dwd has left

  84. Ge0rG has joined

  85. dwd has left

  86. ralphm has left

  87. Guus has left

  88. Guus has joined

  89. ralphm has left

  90. Ge0rG has left

  91. Ge0rG has joined

  92. Guus has left

  93. Guus has joined

  94. arc has left

  95. arc has joined

  96. arc has left

  97. arc has joined

  98. intosi has joined

  99. arc has left

  100. arc has joined

  101. arc has left

  102. arc has joined

  103. Steve Kille has left

  104. alacer has joined

  105. Guus has left

  106. Guus has joined

  107. arc has left

  108. arc has joined

  109. Steve Kille has left

  110. Arc has left

  111. arc has left

  112. arc has joined

  113. arc has left

  114. arc has joined

  115. arc has left

  116. arc has joined

  117. Steve Kille has left

  118. arc has left

  119. Steve Kille has left

  120. arc has joined

  121. Steve Kille has joined

  122. edhelas has left

  123. daniel has left

  124. mimi89999 has joined

  125. alacer has joined

  126. Steve Kille has left

  127. ralphm has joined

  128. efrit has joined

  129. zinid has left

  130. zinid has joined

  131. Syndace has left

  132. Syndace has joined

  133. zinid has left

  134. zinid has joined

  135. Syndace has joined

  136. Syndace has joined

  137. alacer has joined

  138. dwd has left

  139. Guus has left

  140. dwd has left

  141. goffi has joined

  142. Ge0rG has left

  143. Ge0rG has joined

  144. dwd has left

  145. jubalh has joined

  146. dwd has left

  147. dwd has left

  148. daniel has left

  149. dwd has left

  150. ralphm has left

  151. zinid has left

  152. zinid has joined

  153. dwd has left

  154. dwd has left

  155. daniel has left

  156. dwd has left

  157. jonasw has left

  158. dwd has left

  159. efrit has left

  160. dwd has left

  161. dwd has left

  162. dwd has left

  163. jonasw has left

  164. ralphm has left

  165. dwd has left

  166. dwd has left

  167. tux has left

  168. dwd has left

  169. dwd has left

  170. dwd has left

  171. dwd has left

  172. dwd has left

  173. dwd has left

  174. sonny has left

  175. sonny has joined

  176. dwd has left

  177. sonny has joined

  178. sonny has joined

  179. jubalh has joined

  180. sonny has left

  181. sonny has joined

  182. dwd has left

  183. daniel has left

  184. sonny has left

  185. sonny has joined

  186. dwd has left

  187. dwd has left

  188. sonny has left

  189. sonny has joined

  190. dwd has left

  191. jubalh has left

  192. dwd has left

  193. daniel has left

  194. Guus has joined

  195. dwd has left

  196. dwd has left

  197. jcbrand has joined

  198. dwd has left

  199. dwd has left

  200. jubalh has joined

  201. jubalh has left

  202. dwd has left

  203. ralphm has left

  204. dwd has left

  205. la|r|ma has joined

  206. alacer has joined

  207. dwd has left

  208. alacer has left

  209. Alex has joined

  210. tux has joined

  211. tim@boese-ban.de has joined

  212. daniel has left

  213. dwd has left

  214. dwd has left

  215. tux has joined

  216. dwd has left

  217. dwd has left

  218. lskdjf has joined

  219. dwd has left

  220. intosi has left

  221. intosi has joined

  222. sonny has left

  223. sonny has joined

  224. tux has left

  225. sonny has left

  226. sonny has joined

  227. sonny has left

  228. sonny has joined

  229. Alex has left

  230. thomas_ has joined

  231. Alex has joined

  232. thomas_

    Hi guys, while reading the MIX spec, I'm wondering how the roster item for the MIX channel is added to the user joining the channel if it's an external MIX server? Is the user's server supposed to scan the MIX join/leave stanzas in order to determine if the user successfully joined the channel?

  233. daniel has left

  234. Alex has left

  235. jubalh has joined

  236. daniel has left

  237. daniel has left

  238. tux has joined

  239. moparisthebest has joined

  240. jere has joined

  241. jere has left

  242. jere has joined

  243. jonasw

    thomas_, yes

  244. jonasw

    the server needs MIX support

  245. jonasw

    (that is, the users server)

  246. jonasw

    you may note that the join is a command sent to the users account, not to the channel the user wants to join

  247. jonasw

    see Example 22

  248. thomas_

    jonasw, oh okay, I missed that bit of information

  249. thomas_

    jonasw, thanks for clarifying this!

  250. jonasw

    you’re welcome!

  251. daniel has left

  252. la|r|ma has left

  253. efrit has joined

  254. jubalh has left

  255. daniel has left

  256. Valerian has joined

  257. dwd has left

  258. lumi has joined

  259. jonasw has joined

  260. jubalh has joined

  261. efrit has left

  262. jubalh has left

  263. daniel has left

  264. jubalh has joined

  265. jubalh has left

  266. daniel has left

  267. zinid has left

  268. jjrh has left

  269. sonny has joined

  270. sonny has joined

  271. jubalh has joined

  272. zinid has left

  273. sonny has joined

  274. sonny has joined

  275. sonny has joined

  276. sonny has joined

  277. sonny has joined

  278. sonny has joined

  279. sonny has left

  280. sonny has joined

  281. sonny has left

  282. sonny has joined

  283. Valerian has left

  284. sonny has left

  285. sonny has joined

  286. alacer has joined

  287. sonny has joined

  288. ralphm has left

  289. Ge0rG has joined

  290. sonny has joined

  291. jjrh has left

  292. jere has left

  293. jere has joined

  294. daniel has left

  295. jjrh has left

  296. sonny has left

  297. sonny has joined

  298. daniel has left

  299. jubalh has left

  300. sonny has joined

  301. sonny has joined

  302. Valerian has joined

  303. sonny has joined

  304. zinid has left

  305. jubalh has joined

  306. jubalh has left

  307. jubalh has joined

  308. dwd has left

  309. waqas has joined

  310. lumi has left

  311. jubalh has left

  312. Valerian has left

  313. edhelas has left

  314. jjrh has left

  315. zinid has left

  316. jjrh has left

  317. jjrh has left

  318. efrit has joined

  319. alacer has joined

  320. alacer has joined

  321. bjc has left

  322. bjc has joined

  323. Wiktor has left

  324. jjrh has left

  325. sonny has joined

  326. pep. has left

  327. efrit has left

  328. jubalh has joined

  329. Wiktor has left

  330. Ge0rG has joined

  331. jjrh has left

  332. jubalh has left

  333. sonny has left

  334. sonny has joined

  335. sonny has joined

  336. sonny has joined

  337. sonny has left

  338. sonny has joined

  339. arc has left

  340. arc has joined

  341. jjrh has left

  342. arc has left

  343. arc has joined

  344. ralphm has joined

  345. daniel has left

  346. arc has left

  347. arc has joined

  348. bjc has left

  349. bjc has joined

  350. sonny has joined

  351. sonny has joined

  352. arc has left

  353. arc has joined

  354. arc has left

  355. arc has joined

  356. mimi89999 has joined

  357. sonny has joined

  358. sonny has joined

  359. sonny has joined

  360. sonny has joined

  361. sonny has joined

  362. sonny has joined

  363. arc has left

  364. arc has joined

  365. arc has left

  366. arc has joined

  367. xnyhps has left

  368. lskdjf has left

  369. lskdjf has left

  370. sonny has joined

  371. sonny has joined

  372. ralphm has left

  373. lumi has joined

  374. arc has left

  375. arc has joined

  376. Alacer has joined

  377. Alacer has left

  378. jcbrand has left

  379. la|r|ma has left

  380. lskdjf has left

  381. lskdjf has left

  382. arc has left

  383. arc has joined

  384. ralphm has joined

  385. jere has left

  386. jere has joined

  387. ralphm has left

  388. jcbrand has joined

  389. lskdjf has joined

  390. lskdjf has left

  391. lskdjf has left

  392. arc has left

  393. arc has joined

  394. lskdjf has left

  395. lskdjf has left

  396. lskdjf has joined

  397. jere has left

  398. jere has joined

  399. lskdjf has left

  400. lskdjf has left

  401. lskdjf has left

  402. moparisthebest

    Is there a xep for, probably wording this wrong, a client sending messages to itself and other resources (mam/carbons) from other domains?

  403. moparisthebest

    Basically spoofing from, but only to itself

  404. Zash


  405. jonasw

    moparisthebest, why would you do that?

  406. moparisthebest

    Ok so jmp.chat gives you a phone number for sending/receiving sms with xmpp

  407. moparisthebest

    Basically thinking the same thing as a conversations plugin

  408. jonasw

    i.e. a local transport for SMS <-> XMPP?

  409. waqas has left

  410. jonasw

    I don’t think there’s a XEP for that, but I think that’s not the worst idea.

  411. Zash

    Why not treat it as another account?

  412. jonasw

    Zash, replication to other devices

  413. jonasw

    moparisthebest, question though: how would you intercept messages sent to those SMS JIDs?

  414. jonasw

    essentially you want a component, but only for the account.

  415. moparisthebest

    Ie my phone gets SMS from 5555, I see it in conversations and all my other xmpp clients as from 5555@some.specific.fake.domain

  416. moparisthebest

    If I respond in conversations it sends it over sms, if I respond in other clients conversations sends sms when it gets the carbon?

  417. Zash

    Oh dear, is this leading to an argument for uploading into your archive?

  418. Zash

    ... like 136 hasq

  419. Zash

    ... like 136 has?

  420. moparisthebest

    So this would need a server plugin too

  421. jonasw

    moparisthebest, that carbons trick there would kindof work, but it would also create some strain on the server for error handling of stanzas it doesn’t even need to s2s-route

  422. moparisthebest

    Basically to allow a client to spoof from for a certain domain but only for that account

  423. Zash

    But, there's the forwarding xep (used for encapsulation by carbons and mam)

  424. moparisthebest

    That might work have a xep number handy?

  425. Zash

    297 maybe? (wild guess)

  426. jonasw


  427. jonasw


  428. Zash

    Bunneh: xep forwarding

  429. Bunneh

    Zash: XEP-0297: Stanza Forwarding (Standards Track, Draft, 2013-10-02) See: https://xmpp.org/extensions/xep-0297.html

  430. jonasw

    it doesn’t magically give you the kind of handling you want though

  431. moparisthebest

    Because yea I'd want carbons and mam etc

  432. jonasw

    it only defines an encapsulation protocol (as re-used by carbons etc.)

  433. Steve Kille has left

  434. Steve Kille has left

  435. moparisthebest

    This would work as a separate component of course but that had issues like this

  436. moparisthebest

    Not encrypted, different connection, separate component for each account etc etc

  437. Zash

    The architecture with transports as server components kinda breaks down when clients are also transports

  438. jonasw

    to have things well defined, you have to use this on one account only anyways

  439. moparisthebest


  440. jonasw

    so user components are an interesting concept

  441. jonasw

    like a component, but the domain is only visible to the user

  442. jonasw

    (and other users may have the same domain)

  443. moparisthebest

    Yes that

  444. jonasw

    but that’s not specified yet

  445. moparisthebest

    Forwarding wouldn't work I think

  446. jjrh has left

  447. moparisthebest

    No real great way to respond and such I think

  448. moparisthebest

    Can clients send carbons to other resources?

  449. jonasw

    yes, but those must ignore them

  450. moparisthebest

    Bunneh: xep carbons

  451. Bunneh

    moparisthebest: XEP-0280: Message Carbons (Standards Track, Proposed, 2017-02-16) See: https://xmpp.org/extensions/xep-0280.html

  452. Zash

    You probably want to invent some new protocol

  453. Zash

    There /was/ that {xep remote control}

  454. Bunneh

    Zash: XEP-0146: Remote Controlling Clients (Informational, Active, 2006-03-23) See: https://xmpp.org/extensions/xep-0146.html

  455. lskdjf has left

  456. moparisthebest

    I'll have to abuse gajims XML console later and play around

  457. moparisthebest

    I feel like maybe carbons from other resources would be safe right?

  458. arc has left

  459. Zash

    Broadcast is the kind of thing you want your server to help you with

  460. Steve Kille has joined

  461. goffi has left

  462. moparisthebest

    I think jonasw 's description is closest to what I'm looking for, user or client components

  463. lskdjf has joined

  464. moparisthebest

    True Zash

  465. moparisthebest

    Hmm then you could use the phone's dialer to jingle call through it too...

  466. Steve Kille has left

  467. moparisthebest

    Leave your cell at home and sms/call through it wherever you have an xmpp client and internet

  468. waqas has joined

  469. moparisthebest

    Anyone interested in working with me on something like that? :)

  470. Steve Kille has left

  471. arc has joined

  472. lskdjf has left

  473. Guus has left

  474. sonny has left

  475. sonny has joined

  476. lskdjf has left

  477. Arc has joined

  478. lskdjf has left

  479. thomas_

    moparisthebest, maybe I didn't get your idea but why not using a transport with <phonenumber>@transport for each phone contact?

  480. moparisthebest

    I think it could be as simple as the server advertising that the client can send messages to itself from *@*.somedomain then the server not doing s2s for *. somedomain and allowing that

  481. Steve Kille has left

  482. moparisthebest

    thomas_: the transport is per user account and runs on one of their clients is why

  483. lovetox has joined

  484. thomas_

    moparisthebest, why does the transport run on a client?

  485. Zash

    It's a phone?

  486. moparisthebest

    thomas_: conversations on your phone is the only thing with access to send/recieve sms

  487. Zash

    You wanna pretend that the native SMS functionality is a component

  488. thomas_

    Oh, I though you have a device with your SIM card somewhere and want to connect via XMPP

  489. jonasw

    thomas_, the component protocol is insecure

  490. Guus has joined

  491. jonasw

    that’s one reason why you don’t want to run that $somewhere

  492. jonasw

    second, if you don’t run your own server / the server is shared with multiple entities, you don’t want them to access your transport

  493. moparisthebest

    Plus it's per server not per account

  494. jonasw

    that’s what I mean, essentially

  495. thomas_

    ah okay

  496. la|r|ma has left

  497. la|r|ma has joined

  498. moparisthebest

    Hmm you could run a component that you register with and send arbitrary messages to your own account through...

  499. la|r|ma has joined

  500. la|r|ma has joined

  501. la|r|ma has joined

  502. moparisthebest

    Then no server changes needed

  503. la|r|ma has joined

  504. la|r|ma has joined

  505. la|r|ma has joined

  506. la|r|ma has joined

  507. la|r|ma has joined

  508. la|r|ma has joined

  509. jonasw


  510. Steve Kille has left

  511. jonasw

    kind of an echo component?

  512. la|r|ma has joined

  513. waqas has left

  514. jonasw

    that would work.

  515. la|r|ma has joined

  516. moparisthebest

    Essentially yes

  517. jonasw

    a meta-component

  518. la|r|ma has joined

  519. moparisthebest

    Done extra rules but yea

  520. jonasw

    a component to create per-user components :D

  521. la|r|ma has joined

  522. moparisthebest


  523. la|r|ma has joined

  524. jonasw

    that’s quite fancy, actually, because you get stream management etc. "for free"

  525. la|r|ma has joined

  526. la|r|ma has joined

  527. moparisthebest

    Yep I like simple

  528. la|r|ma has joined

  529. Zash

    You could also register a normal account and send yourself messages via that

  530. la|r|ma has joined

  531. la|r|ma has joined

  532. jonasw

    Zash, you’d need one account for each phone number you text?

  533. la|r|ma has joined

  534. moparisthebest

    Zash: no you need from to be multiple accounts based on phone number

  535. la|r|ma has joined

  536. moparisthebest


  537. la|r|ma has joined

  538. la|r|ma has joined

  539. Zash

    Abuse resources! :D

  540. la|r|ma has joined

  541. sonny has left

  542. jonasw

    resource abuse will wreak havoc with message routing 2.0

  543. la|r|ma has joined

  544. sonny has joined

  545. la|r|ma has joined

  546. moparisthebest

    Can't add them to your contacts though

  547. la|r|ma has joined

  548. jonasw

    (also, one connection per peer, really? ;-))

  549. la|r|ma has joined

  550. la|r|ma has joined

  551. la|r|ma has joined

  552. moparisthebest

    With jmp.chat it's phonenumber@cheogram.com

  553. la|r|ma has joined

  554. la|r|ma has joined

  555. jonasw

    moparisthebest, you should write a XEP for this echo component with the given use-case.

  556. la|r|ma has left

  557. moparisthebest

    This component could even be public and require no local server support

  558. jonasw

    the only thing I don’t like about it is that you can only have N components per user, where N is the number of server-side components :/

  559. jonasw

    it doesn’t even need to be a component

  560. jonasw

    you should probably not reference any component-specific protocol

  561. jonasw

    only that it is a domain-JID entity which implements that protocol

  562. jonasw

    which means that servers could also offer you *@*.local for example.

  563. moparisthebest

    I'll give it a try jonasw , I'm the type to code/test first and write specs later :)

  564. jonasw


  565. jonasw

    happy to proof-read if you want to before submission.

  566. Zash

    <message to=self><forwarding><message from="number@actually.sms.invalid" to="self"><body>hi</body><////>

  567. Zash

    Thing gets wrapped in seven layers of carbons and forwarded to all your clients.

  568. jonasw

    Zash, that’s the easy part -- the tricky part is to be able to send messages to number@actually.sms.invalid

  569. Zash

    jonasw: <message to="me@self/phone"><forward><message to="number@sms"><body>HELLO<///>

  570. moparisthebest

    But being able to do component and avoid lua or erlang makes it something I can do myself at least (sorry server devs...)

  571. nyco has left

  572. Zash

    Add some caps and call it a day!

  573. moparisthebest

    jonasw: does your Python lib do components?

  574. moparisthebest

    I've only ever used the ancient first Python lib for components

  575. jonasw


  576. jonasw

    Zash, right

  577. Guus has left

  578. jonasw

    that’d work but ...

  579. jonasw

    but it would also require client support on the clients which are not the component

  580. Zash


  581. jonasw

    simple clients!

  582. jonasw

    (also, I’m not entirely sure how serious your proposals are)

  583. Zash

    I don't think clients are simple anymore

  584. Zash

    jonasw: On a scale from dead serious to trolling? Usually somewhere in the middle.

  585. Guus has joined

  586. zinid

    > But being able to do component and avoid lua or erlang makes it something I can do myself at least pussy detected

  587. Guus has left

  588. Zash

    jonasw: "That's my secret. I'm always joking." :D

  589. moparisthebest

    zinid: I prefer the word 'sane' :)

  590. zinid

    moparisthebest: writing in python is sane?

  591. Zash

    not writing everything in Lua is sane???

  592. moparisthebest

    Hoping to use rust if there are component libs, but yea point taken about Python :)

  593. jonasw

    moparisthebest, there is xmpprs or so

  594. jonasw

    not sure if it can do components

  595. moparisthebest

    Yea I've used it for a client

  596. zinid

    yeah, rust...

  597. lskdjf has joined

  598. moparisthebest

    the component will be dead simple in any language

  599. moparisthebest

    the client will have to decide whether or not to send new SMS on carbon/mam etc, ew

  600. Steve Kille has left

  601. Steve Kille has left

  602. Guus has joined

  603. sonny has joined

  604. bjc has joined

  605. sonny has joined

  606. bjc has joined

  607. moparisthebest

    next ridiculous question, is there anything defined in jingle for one resource to make a call through another resource?

  608. moparisthebest

    same account, resource A is connected to a phone line, resource B is not

  609. moparisthebest

    B wants to make a phone call, any current way to do that?

  610. Zash

    I don't think there's anything special about that

  611. Zash

    The problem with Jingle is that it works exactly like that

  612. Zash

    One arbitrary JID calls another arbitrary JID.

  613. Zash

    As opposed to one account calling another account.

  614. daniel has left

  615. daniel has joined

  616. moparisthebest

    that's not exactly what I mean though

  617. Zash

    So I don't think anything in the Jingle spec prevents two resources of the same account from establishing calls

  618. Guus has left

  619. moparisthebest

    not a call between A and B, a call between B and +1-555-555-5555 THROUGH A

  620. moparisthebest

    so the jingle session would be between A and B, but A would be, uh, forwarding through the PSTN

  621. Guus has joined

  622. Zash

    There's a thing, hold on

  623. Zash

    -xep dtmf

  624. Bunneh

    Zash: XEP-0181: Jingle DTMF (Standards Track, Deferred, 2009-10-02) See: https://xmpp.org/extensions/xep-0181.html

  625. jonasw


  626. jonasw

    so you’d start a jingle call through A and send DTMF to actually dial a number

  627. moparisthebest

    ha you could I guess, maybe, not sure what android phone API looks like

  628. Zash

    Like, whatever it's called when you call somewhere and go into an answering machine that you type more numbers into to get passed on

  629. jonasw

    moparisthebest, but I don’t think you need special protocol for that. you’d contact the gateway client at its pseudo-JID at the component and it would re-write the jingle connection negotiation messages accordingly so that the call is routed through it

  630. Zash

    Maybe you need to find/invent some way to tell the other end to proxy you

  631. Zash

    But, isn't that basically how PSTN works (or used to, way back in the analog era)?

  632. jonasw

    don’t need to, it’s already proxied through the pseudo-JID magic

  633. moparisthebest

    hmm not sure I kind of imagined them seperately

  634. moparisthebest

    that would probably be best, have to think about it

  635. Zash

    -xep rayo

  636. Bunneh

    Zash: Multiple matches: Rayo https://xmpp.org/extensions/xep-0327.html Rayo Fax https://xmpp.org/extensions/xep-0342.html Rayo CPA https://xmpp.org/extensions/xep-0341.html Rayo Clustering https://xmpp.org/extensions/xep-0349.html

  637. Zash

    Uh, maybe anything in those have anything usable?

  638. jonasw

    I’m not sure if I was understood

  639. moparisthebest

    hmm possibly

  640. moparisthebest

    jmp.chat neatly bypasses all this by 'if you want voice, connect to this SIP account:'

  641. Zash

    Neatly solve this problem by putting your phone next to your server and writing a component that connects over USB or somesuch :)

  642. Arc has left

  643. Arc has joined

  644. moparisthebest

    anyway one step at a time, SMS is much simpler

  645. Alex has joined

  646. bjc has joined

  647. bjc has joined

  648. jubalh has joined

  649. jonasw has left

  650. jubalh has left

  651. jubalh has joined

  652. daniel has left

  653. goffi has joined

  654. daniel has left

  655. jcbrand has left

  656. jcbrand has joined

  657. ralphm has left

  658. jubalh has left

  659. ralphm has left

  660. tux has joined

  661. moparisthebest

    if I'm sending a message to a JID but need to encode 1 seperate piece of info, what's the best way to do that?

  662. jonasw


  663. moparisthebest

    a new element inside <message> or inside <body> or a new attribute on something?

  664. waqas has joined

  665. jonasw


  666. jonasw


  667. jonasw

    never ever mix elements and text

  668. waqas has left

  669. moparisthebest

    yea but where and what should I do about namespaces?

  670. jonasw

    (unless you’re doing XHTML or something)

  671. jonasw

    "choose" a namespace

  672. jonasw

    don’t add attributes to any existing elements, make your own element and put it an <message/>

  673. moparisthebest

    but inside message is fine?

  674. jonasw

    think about what happens if your peer doesn’t understand it

  675. moparisthebest

    great thanks

  676. waqas has joined

  677. zinid has left

  678. moparisthebest

    what's the precedent for naming these things with multiple words, for example, <echo-from xmlns="urn:xmpp:echo-self">+15555555555</echo-from> ?

  679. Zash

    Metadata in attributes and content in text nodes :)

  680. Zash

    Most things are just one word afik

  681. moparisthebest

    ah so I could go

  682. moparisthebest

    <echo xmlns="urn:xmpp:echo-self" from="+15555555555" />

  683. moparisthebest

    looks cleaner anyhow probably

  684. Zash

    and urn:xmpp is technically not something anyone can just use without going through the XSF

  685. moparisthebest

    yea I'll make something else for testing

  686. jonasw

    Zash, sure you can, it just breaks things.

  687. jonasw

    (or may break due to conflict etc.)

  688. Zash

    Do we have any recommendations for these things, or do they exist anywhere?

  689. jubalh has left

  690. jubalh has joined

  691. moparisthebest

    yea that's what I was asking about

  692. moparisthebest

    doesn't matter at this point but would be nice to see

  693. Zash

    Stuff like {urn:example:foo}foo usually annoy me slightly

  694. Zash

    *ahem* {http://jabber.org/protocol/pubsub}pubsub/action *hrr*

  695. jonasw

    moparisthebest, I’m not entirely sure what you need that element for, but I suggest that you orient your wire-format on what XEP-0280 (Message Carbons) does

  696. jonasw

    at least for the communication between the component and the user component implementation

  697. jonasw

    (not for component<->normal resources)

  698. moparisthebest

    I think this might be the only thing the server component needs

  699. moparisthebest

    basically that would mean 'send me this message from that JID'

  700. moparisthebest

    the component ignores everything else, carbons handles that

  701. jonasw

    so the user component implementation on the phone client would send <message to=component><body>...</body><echo xmlns="..." ...>...</echo></message>?

  702. moparisthebest


  703. jonasw

    please wrap the message once

  704. moparisthebest

    I was going to include the no-copy and no-carbons stuff

  705. jonasw


  706. moparisthebest

    why wrap it so I wouldn't have to do that?

  707. jonasw

    because it makes things explicit

  708. jonasw

    something like <message><echo send-from="..."><forwarded><message ...>...</message></forwarded></echo></message>

  709. jonasw

    re-uses XEP-0297 even though the naming is a bit off

  710. jonasw

    has the advantage that this won’t be picked up by MAM or carbons

  711. jonasw

    (because of type="normal" on the outer and no <body/>)

  712. valo has left

  713. bjc has left

  714. moparisthebest

    jonasw, that seems harder

  715. moparisthebest

    right now the entire logic of the component is this:

  716. moparisthebest

    if msg.find('{urn:moparisthebest:echo-self}echo') is not None: to = msg['to'] msg['to'] = msg['from'] msg['from'] = to msg.send()

  717. moparisthebest


  718. jonasw

    moparisthebest, given that <no-store/> and <no-copy/> are from XEP-0334 which is in limbo since Council rejected its advancement, it seems like the more future-proof approach

  719. moparisthebest

    ignores everything without <echo>, if it has echo, swaps to/from and sends it back?

  720. jonasw

    that’s not what you want though

  721. jonasw

    what you’re doing requires all involved clients to know the echo protocol

  722. jonasw

    I’d avoid that

  723. moparisthebest

    no it's working exactly right without any clients knowing it

  724. daniel has left

  725. moparisthebest

    except the one sending it that is

  726. arc has left

  727. arc has joined

  728. moparisthebest

    (currently gajim xml console)

  729. jonasw

    how would I reply to a message from somenumber@thatcomponent.domain?

  730. dwd

    moparisthebest, You're not an SDO - don't use "urn:...". Just use an http scheme URI to your domain. Or an xmpp scheme one, like your jid.

  731. valo has joined

  732. jonasw

    what is an SDO?

  733. dwd

    moparisthebest, For example, I could use xmlns="xmpp:dwd@dave.cridland.net/some-proto"

  734. dwd

    jonasw, In this context, a Standards Development Organisation

  735. jonasw


  736. moparisthebest

    before today I've happily lived completely ignoring xmlns

  737. moparisthebest

    oh how I yearn for 10 minutes ago

  738. dwd

    jonasw, You're an XSF Editor, right? I noticed some of "my" XEPs are using old contact info - what's the best way to update that?

  739. Arc has left

  740. daniel has left

  741. dwd

    moparisthebest, They're strings. Mostly without meaning, except the ones that do have meaning. But we're supposed to know how to use them properly.

  742. zinid has joined

  743. jonasw

    dwd, which ones exactly?

  744. efrit has joined

  745. jonasw

    or rather: have you checked whether your info in xep.ent is up-to-date? if it isn’t, that’d be a great way to start.

  746. moparisthebest

    also, how dare dwd assume I'm not a Standards Development Organization :)

  747. dwd

    jonasw, I happened to notice XEP-0286, but there might be others.

  748. dwd

    moparisthebest, Actually the best definition I have for an SDO is whether they can register a urn prefix.

  749. jonasw

    dwd, https://github.com/xsf/xeps/blob/master/xep.ent#L924 is this up-to-date?

  750. moparisthebest


  751. dwd

    jonasw, Yes.

  752. jonasw

    dwd, okay, will update the XEPs not using that entity definition.

  753. dwd

    jonasw, Thanks. Much appreciated.

  754. jonasw

    (there are two)

  755. jonasw

    (XEP-0376 is the other one)

  756. jonasw

    moparisthebest, I was thinking something like this: <!-- User component to Component --> <message to="component.domain" from="account@domain/user-component-client"> <echo xmlns="foo"> <forwarded> <message from="phonenumber@component.domain" to="account@domain" id="xyz"> <body>Hi there!</body> </message> </forwarded> </echo> </message> <!-- Component to account --> <message from="phonenumber@component.domain" to="account@domain" id="xyz"> <body>Hi there!</body> </message> <!-- Some client from the account replies --> <message from="account@domain/resource" to="phonenumber@component.domain" id="abc"> <body>Hi yourself!</body> </message> <!-- Component to User component --> <message from="component.domain" to="account@domain/user-component-client"> <echo xmlns="foo"> <forwarded> <message from="account@domain/resource" to="phonenumber@component.domain" id="abc"> <body>Hi yourself!</body> </message> </forwarded> </echo> </message>

  757. daniel has left

  758. jonasw

    this has the advantage that the protocol between user component and the server-side component is explicit

  759. jonasw

    the interaction between the component and other clients is like with any other domain

  760. jonasw

    which is nice

  761. jonasw

    wrapping the actual payload saves it from being archived etc.

  762. moparisthebest

    then the component has a state

  763. jonasw

    moparisthebest, why would it need state for that?

  764. moparisthebest

    and there is, registering stuff involved

  765. la|r|ma has left

  766. moparisthebest

    <!-- Component to User component -->

  767. jonasw

    right, it needs to know that anyways?

  768. moparisthebest

    I don't think so

  769. jonasw

    how would it not need that?

  770. jonasw

    it does have to know where to deliver messages sent by other clients to the component?

  771. moparisthebest

    the user's server handles it for them, with carbons

  772. moparisthebest

    and/or mam etc

  773. jonasw

    ugh, you’ll simply ignore them and rely on carbons? :/

  774. jonasw

    I see

  775. moparisthebest

    exactly :)

  776. jonasw

    I don’t like that approach :)

  777. jonasw

    it relies on carbon rules which are super-foggy

  778. moparisthebest

    it has the advantage of the component being potentially the simplest xmpp component of all time

  779. jonasw

    I can also see the use-case of <iq/> and other stanza types for user components.

  780. jonasw

    but it’s not really re-usable

  781. moparisthebest

    true it only works for carbon'd things

  782. moparisthebest

    still that seems like an additional xep for non-message things that don't get carboned, might as well keep this super simple

  783. jonasw

    but consistency.

  784. edhelas has left

  785. Alex has left

  786. thomas_ has left

  787. arc has left

  788. arc has joined

  789. jjrh has left

  790. Steve Kille has left

  791. Valerian has joined

  792. moparisthebest

    does message have to have a body ?

  793. jonasw


  794. jonasw

    carbons for example do not have bodies

  795. moparisthebest

    I don't know if it's sleekxmpp or prosody, but one is refusing to deliver it

  796. jonasw

    care to show some XML traces?

  797. moparisthebest

    no errors, just doesn't go through until I add a body

  798. jonasw

    I suspect that might not be the only difference. there are a lot of use-cases for non-body messages.

  799. jonasw

    (chat state notifications for example)

  800. moparisthebest

    no I'm pasting into the gajim xml console and that's the only difference :)

  801. jonasw

    how are you trying to receive the message?

  802. moparisthebest

    it's sleekxmpp

  803. moparisthebest

    if I turn on COMM level logging it logs it, but doesn't send it to my app

  804. jubalh has left

  805. moparisthebest

    well that's a bug I'm not dealing with now

  806. moparisthebest

    will mess with <forwarded> later meh

  807. daniel has left

  808. sonny has joined

  809. sonny has joined

  810. jjrh has left

  811. jcbrand has left

  812. jubalh has joined

  813. arc has left

  814. jcbrand has joined

  815. arc has joined

  816. Syndace has joined

  817. daniel has left

  818. jere has joined

  819. waqas has left

  820. moparisthebest has joined

  821. Arc has joined

  822. lskdjf has joined

  823. lskdjf has joined

  824. bjc has joined

  825. jubalh has left

  826. jcbrand has left

  827. Guus has left

  828. Valerian has left

  829. Valerian has joined

  830. daniel has left

  831. Guus has joined

  832. tux has joined

  833. tux has joined

  834. efrit has left

  835. daniel has left

  836. efrit has joined

  837. daniel has left

  838. sonny has left

  839. sonny has joined

  840. lovetox has left

  841. valo has left

  842. valo has joined

  843. efrit has left

  844. jcbrand has joined

  845. jcbrand has left

  846. Valerian has left

  847. efrit has joined

  848. goffi has left

  849. daniel has left

  850. daniel has left

  851. daniel has left

  852. daniel has left

  853. daniel has joined

  854. Valerian has joined

  855. la|r|ma has left