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 Forwarding?
  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 297
  427. jonasw https://xmpp.org/extensions/xep-0297.html
  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 Yes
  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 simj
  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 Some*
  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 Yes
  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 right
  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 no
  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 Yes
  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 lovely
  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 <foo/>?
  663. moparisthebest a new element inside <message> or inside <body> or a new attribute on something?
  664. waqas has joined
  665. jonasw NOT INSIDE BODY
  666. jonasw ahem
  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 yes
  703. jonasw please wrap the message once
  704. moparisthebest I was going to include the no-copy and no-carbons stuff
  705. jonasw no
  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 done
  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 ah
  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 no
  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