jdev - 2022-07-27

  1. emus has left
  2. FireFly has left
  3. jgart has joined
  4. FireFly has joined
  5. Ingolf has joined
  6. Kev has joined
  7. Patiga has left
  8. xecks has joined
  9. Kev has left
  10. thomaslewis has left
  11. pulkomandy has left
  12. pulkomandy has joined
  13. Patiga has joined
  14. thomaslewis has joined
  15. thomaslewis has left
  16. xnamed has left
  17. thomaslewis has joined
  18. xnamed has joined
  19. thomaslewis has left
  20. spiral has joined
  21. Kev has joined
  22. Sam has left
  23. thomaslewis has joined
  24. Kev has left
  25. Sam has joined
  26. thomaslewis has left
  27. inky has left
  28. thomaslewis has joined
  29. hearty has left
  30. hearty has joined
  31. Schimon has joined
  32. xnamed has left
  33. Kev has joined
  34. FireFly has left
  35. hearty has left
  36. hearty has joined
  37. Patiga has left
  38. FireFly has joined
  39. Sam has left
  40. sonny has left
  41. sonny has joined
  42. Kev has left
  43. Sam has joined
  44. Zash has left
  45. Kev has joined
  46. dezant has joined
  47. Kev has left
  48. Yagizа has joined
  49. paul has left
  50. hearty has left
  51. mh has left
  52. hearty has joined
  53. mh has joined
  54. Kev has joined
  55. Kev has left
  56. mirux has joined
  57. TheRealkarano has joined
  58. Kev has joined
  59. raghavgururajan has left
  60. xecks has left
  61. xecks has joined
  62. Kev has left
  63. defanor has left
  64. Stefan has joined
  65. defanor has joined
  66. atomicwatch has joined
  67. hearty has left
  68. marc0s has left
  69. hearty has joined
  70. marc0s has joined
  71. Kev has joined
  72. Sam has left
  73. john-machan has left
  74. john-machan has joined
  75. Patiga has joined
  76. jgart has left
  77. Kev has left
  78. xecks has left
  79. xecks has joined
  80. marc0s has left
  81. napen123 has joined
  82. paul has joined
  83. marc0s has joined
  84. Sam has joined
  85. mirux has left
  86. mirux has joined
  87. napen123 has left
  88. MSavoritias (fae,ve) has joined
  89. wurstsalat has joined
  90. Sam has left
  91. Patiga has left
  92. Kev has joined
  93. marc0s has left
  94. marc0s has joined
  95. xecks has left
  96. xecks has joined
  97. thomaslewis has left
  98. thomaslewis has joined
  99. thomaslewis has left
  100. marc0s has left
  101. marc0s has joined
  102. adx has joined
  103. Kev has left
  104. marc0s has left
  105. marc0s has joined
  106. thomaslewis has joined
  107. marc0s has left
  108. marc0s has joined
  109. thomaslewis has left
  110. marc0s has left
  111. marc0s has joined
  112. marc0s has left
  113. marc0s has joined
  114. marc0s has left
  115. marc0s has joined
  116. kikuchiyo has joined
  117. marc0s has left
  118. marc0s has joined
  119. Kev has joined
  120. nik has joined
  121. jgart has joined
  122. emus has joined
  123. marc0s has left
  124. marc0s has joined
  125. marc0s has left
  126. marc0s has joined
  127. Laura has left
  128. marc0s has left
  129. marc0s has joined
  130. hearty has left
  131. Alex has joined
  132. hearty has joined
  133. marc0s has left
  134. marc0s has joined
  135. marc0s has left
  136. marc0s has joined
  137. marc0s has left
  138. marc0s has joined
  139. jgart has left
  140. marc0s has left
  141. marc0s has joined
  142. FireFly has left
  143. marc0s has left
  144. marc0s has joined
  145. marc0s has left
  146. marc0s has joined
  147. debacle has joined
  148. Kev has left
  149. marc0s has left
  150. marc0s has joined
  151. marc0s has left
  152. marc0s has joined
  153. marc0s has left
  154. marc0s has joined
  155. Patiga has joined
  156. FireFly has joined
  157. john-machan has left
  158. john-machan has joined
  159. marc0s has left
  160. marc0s has joined
  161. Laura has joined
  162. paul has left
  163. pulkomandy has left
  164. Wojtek has joined
  165. FXTIA has left
  166. goffi has left
  167. mh has left
  168. mh has joined
  169. FXTIA has joined
  170. Kev has joined
  171. mh has left
  172. Kev has left
  173. thomaslewis has joined
  174. Sam has joined
  175. mh has joined
  176. Patiga has left
  177. adx has left
  178. thomaslewis has left
  179. Wojtek has left
  180. Mario Sabatino has joined
  181. gregory has left
  182. Laura has left
  183. goffi has joined
  184. atomicwatch has left
  185. paul has joined
  186. pulkomandy has joined
  187. marc0s has left
  188. marc0s has joined
  189. Wojtek has joined
  190. Wojtek has left
  191. adx has joined
  192. gregory has joined
  193. antranigv has joined
  194. drops has left
  195. Sam has left
  196. drops has joined
  197. FireFly has left
  198. Kev has joined
  199. pulkomandy has left
  200. atomicwatch has joined
  201. Laura has joined
  202. Wojtek has joined
  203. Wojtek has left
  204. Wojtek has joined
  205. Wojtek has left
  206. Wojtek has joined
  207. Wojtek has left
  208. debacle has left
  209. Laura has left
  210. Laura has joined
  211. Apollo has left
  212. Apollo has joined
  213. Patiga has joined
  214. debacle has joined
  215. Dele Olajide has joined
  216. Sam has joined
  217. goffi has left
  218. Patiga has left
  219. antranigv has left
  220. antranigv has joined
  221. antranigv has left
  222. marc0s has left
  223. marc0s has joined
  224. marc0s has left
  225. marc0s has joined
  226. marc0s has left
  227. marc0s has joined
  228. jubalh has joined
  229. disgyze has left
  230. atomicwatch has left
  231. atomicwatch has joined
  232. pasdesushi has left
  233. Sam has left
  234. pasdesushi has joined
  235. antranigv has joined
  236. antranigv has left
  237. Laura has left
  238. goffi has joined
  239. larma has joined
  240. atomicwatch has left
  241. xnamed has joined
  242. atomicwatch has joined
  243. PapaTutuWawa has joined
  244. antranigv has joined
  245. FireFly has joined
  246. antranigv has left
  247. pasdesushi has left
  248. marc0s has left
  249. marc0s has joined
  250. xnamed has left
  251. xnamed has joined
  252. pasdesushi has joined
  253. Laura has joined
  254. Sam has joined
  255. atomicwatch has left
  256. dezant has left
  257. lovetox is a type error presence, always generated as a response? Meaning is there a situation where the server would route a error presence to my client, without the client first sending out some presence?
  258. MattJ You might get error responses from your contacts after sending initial presence, which is somewhat similar
  259. MattJ Specifically, in this case you might receive multiple errors in response to a single presence
  260. mh has left
  261. MattJ I suspect that *may* also happen in some circumstances the event that another client on your account comes online and triggers presence probes
  262. mh has joined
  263. nav has joined
  264. jubalh has left
  265. nephele has joined
  266. nav Now that leaves me with the problem of what happens when someone does recycle an old JID.
  267. antranigv has joined
  268. nav Would it be useful to have some kind of unique (opaque) registration identifier to distinguish between two uses of the same JID?
  269. goffi has left
  270. nav Something like an UUID that is associated with a JID for the lifetime of the account. When a JID gets recycled a new UUID is associated with it.
  271. nav Then other services can query for the UUID to establish whether it is the same registration.
  272. Laura has left
  273. Laura has joined
  274. Kev I think the basic solution is 'never allow re-use'.
  275. dezant has joined
  276. antranigv has left
  277. atomicwatch has joined
  278. MattJ I think that's for the best. Otherwise every single slot where we currently have a JID, we would need to replace with JID and UUID
  279. nav Kev: It's one solution, but not always feasible. For instance because of a catastrophic server failure with loss of data or even GDPR considerations.
  280. MattJ Even sending a message. What if you send a message to someone, and it was delayed for a few minutes, but they deleted their account and somebody recreated it?
  281. MattJ The logical conclusion is to replace JIDs with UUIDs :)
  282. nav MattJ: I was thinking more of an as-needed approach, where the onus is on the receiving entity to validate, if they want to, that they're dealing with the same registration.
  283. MattJ But more feasible would be: treat usernames as human-readable UUIDs
  284. nephele that problem is fun, if you have a UUID you can also move servers
  285. nav For instance, via a disco#info query returning the UUID.
  286. nephele if you disallow reuse you might have users that you cannot use for *some* instances because they know your hostname and users that used to be on it, but can use it for other instances that don't know about it... might be a problem if you get a dns name that had a previous owner beforehand
  287. MattJ Sure. For Snikket I disallow hostname reuse for this reason, too.
  288. nav Of course, it doesn't cover the case where someone recycles JIDs mid-conversation. ☺
  289. nephele i'm enviromentally friendly, reuse before recycling! :D better to steal the account mid-conversation
  290. Apollo has left
  291. nav nephele: I wasn't considering active attacks. If that is a concern, then you'd want to be using encryption.
  292. nephele well, the dns entry expiring and beeing re-registered mid conversation seems quite unlikely to me?
  293. MattJ It's an extreme example of course, but certainly I could send a delayed reply to someone whose domain expires and was reregistered by someone else
  294. nephele I mean, what exactly would a UUID *reasonably* protect against that a JID does not? if it does not have any crpytographic gurantees it could also be recycled mid conversation
  295. nav has left
  296. nav has joined
  297. nephele say, if a caching entity is not told that it was recycled and maintains a wrong association of jid<->uuid
  298. nav Actually, I wonder if using encryption would be a viable approach. In theory that would allow both endpoints to authenticate each other.
  299. nav nephele: Yes, good point.
  300. Link Mauve nav, you mean like SASL EXTERNAL, which validates against TLS certificates? :p
  301. nephele I personally like the aproach of "your public key *is* your adress"
  302. nephele i am not sure if that is viable, but it would be quite neat ;)
  303. nav Link Mauve: Possibly, but how do you get say your external component to ask the user connecting to it to authenticate himself that way?
  304. nav nephele: Yeah PKA makes sense.
  305. nav I'll need to have a read of the relevant XEPs see how much hassle it is to implement something like OX on something like a component.
  306. Apollo has joined
  307. marc0s has left
  308. marc0s has joined
  309. Sam has left
  310. Sam has joined
  311. nav has left
  312. Stefan has left
  313. kujiu has left
  314. antranigv has joined
  315. kikuchiyo has left
  316. Wojtek has joined
  317. Apollo has left
  318. Zash has joined
  319. kikuchiyo has joined
  320. pasdesushi has left
  321. atomicwatch has left
  322. pasdesushi has joined
  323. marc0s has left
  324. marc0s has joined
  325. Wojtek has left
  326. mh has left
  327. marc0s has left
  328. marc0s has joined
  329. goffi has joined
  330. nephele has left
  331. nav has joined
  332. mh has joined
  333. nav Bit of a problem. Encryption support appears to be largely limited to message stanzas but not IQ or commands.
  334. antranigv has left
  335. nav It's not encryption per se that I'm concerned about but a way of verifying that you're dealing with the same identity you were dealing with at some unspecified point back in time. Maybe signed presence stanzas will fill the gap.
  336. Link Mauve nav, that was a thing in XEP-0027 fyi.
  337. marc0s has left
  338. marc0s has joined
  339. nav Link Mauve: Presence signing?
  340. Link Mauve Yes.
  341. mh has left
  342. nav Yup, at least Blabber supports it.
  343. nav Kind of out of the box if you've configured an OpenPGP key for the account.
  344. pasdesushi has left
  345. pasdesushi has joined
  346. selurvedu has joined
  347. nav Which is nice because that means the component is getting the signed message essentially for free.
  348. atomicwatch has joined
  349. nav If the component can be bothered to discover the user's public keys and cache them, then a change in the advertised fingerprints may mean that the user could be someone else (or has replaced his keys). That the advertised fingerprints are valid can be checked by verifying the signed presence message.
  350. thomaslewis has joined
  351. Laura has left
  352. pasdesushi has left
  353. nav has left
  354. nav has joined
  355. mh has joined
  356. nav And in principle, this can be done transparently and in a way that's compatible with no OpenPGP use. ☺
  357. Laura has joined
  358. thomaslewis has left
  359. flow nav: i am not confinced that presence signing is a good idea
  360. flow message signing, of course, but presence probably not
  361. flow for starters, presence signing probably significantly increases the time your OpenPGP signing key is unencrypted
  362. pasdesushi has joined
  363. mh has left
  364. mh has joined
  365. thomaslewis has joined
  366. mh has left
  367. mh has joined
  368. pulkomandy has joined
  369. thomaslewis has left
  370. dezant has left
  371. atomicwatch has left
  372. Sam has left
  373. marc0s has left
  374. atomicwatch has joined
  375. pulkomandy has left
  376. Sam has joined
  377. marc0s has joined
  378. thomaslewis has joined
  379. xecks has left
  380. thomaslewis has left
  381. norayr has left
  382. nav has left
  383. nav has joined
  384. xecks has joined
  385. norayr has joined
  386. nav has left
  387. nav has joined
  388. nik has left
  389. inky has joined
  390. thomaslewis has joined
  391. Stefan has joined
  392. marc0s has left
  393. marc0s has joined
  394. jubalh has joined
  395. marc0s has left
  396. marc0s has joined
  397. thomaslewis has left
  398. marc0s has left
  399. marc0s has joined
  400. mh has left
  401. nephele has joined
  402. nephele has left
  403. mh has joined
  404. antranigv has joined
  405. thomaslewis has joined
  406. Paul G Webster has left
  407. xecks has left
  408. nik has joined
  409. Alastair Hogge has left
  410. hearty has left
  411. hearty has joined
  412. larma has left
  413. jubalh has left
  414. hearty has left
  415. pasdesushi has left
  416. xecks has joined
  417. nav has left
  418. nav has joined
  419. thomaslewis has left
  420. al has joined
  421. pasdesushi has joined
  422. marc0s has left
  423. marc0s has joined
  424. marc0s has left
  425. marc0s has joined
  426. thomaslewis has joined
  427. inky has left
  428. debacle has left
  429. debacle has joined
  430. thomaslewis has left
  431. gregory has left
  432. gregory has joined
  433. marc0s has left
  434. marc0s has joined
  435. Dele Olajide has left
  436. pulkomandy has joined
  437. marc0s has left
  438. marc0s has joined
  439. inky has joined
  440. dezant has joined
  441. marc0s has left
  442. marc0s has joined
  443. Ingolf has left
  444. thomaslewis has joined
  445. marc0s has left
  446. marc0s has joined
  447. nik has left
  448. marc0s has left
  449. marc0s has joined
  450. Dele Olajide has joined
  451. marc0s has left
  452. marc0s has joined
  453. thomaslewis has left
  454. larma has joined
  455. nik has joined
  456. al has left
  457. Ingolf has joined
  458. pasdesushi has left
  459. raghavgururajan has joined
  460. Laura has left
  461. pasdesushi has joined
  462. sonny has left
  463. selurvedu has left
  464. dezant has left
  465. MSavoritias (fae,ve) has left
  466. atomicwatch has left
  467. pasdesushi has left
  468. dezant has joined
  469. MSavoritias (fae,ve) has joined
  470. pasdesushi has joined
  471. coleman has left
  472. Sam has left
  473. Sam has joined
  474. thomaslewis has joined
  475. marc0s has left
  476. marc0s has joined
  477. atomicwatch has joined
  478. Sam has left
  479. sonny has joined
  480. Sam has joined
  481. Ge0rG has left
  482. Laura has joined
  483. atomicwatch has left
  484. Ge0rG has joined
  485. PapaTutuWawa has left
  486. atomicwatch has joined
  487. nik has left
  488. nav flow: The same consideration applies whether you're signing and/or encrypting messages as it does to presence. In any case, at least Blabber automatically signs presence stanzas if you have a PGP key associated with your account.
  489. flow nav, the thing is, sending a message is a conscious action, whereas presences are mostly send without the user being aware
  490. flow granted, the problem was more severe in the days where whe shove everything into presence, like "the current song you are listening to"
  491. Zash XEP-0027 signed presences are *huge* and get broadcast to all your contacts every now and then
  492. Zash Doesn't feel efficient
  493. flow in those situations, your pgp key practically never got re-locked, and it always stayed unlocked, which wouldn't be the case if only messages are signed
  494. flow Zash, I think that modern cipher woulds produce smaller signed presences
  495. nav XMPP is hardly efficient to start with. As for presence stanzas, they're not being sent all the time but only when your presence status changes.
  496. Zash OpenPGP?
  497. thomaslewis has left
  498. nav Zash: ?
  499. flow nav, depending on the used extension protocols, your presence status changes quite often
  500. nav flow: For instance?
  501. Zash auto-away etc
  502. flow xep256
  503. flow but shoving stuff into presence is now large considered an anti-pattern, rightfully, if I may add
  504. flow but shoving stuff into presence is now largely considered an anti-pattern, rightfully, if I may add
  505. nav flow: Why would 0256 increase the rate at which <presence/> is being sent?
  506. Zash flow, XEP-0319 too!
  507. nav It's, as you say, just adding some more stuff into it.
  508. Zash Conversations for example has a feature where it sends presence every time you focus or unfocus it.
  509. Zash Disabled by default IIRC
  510. PapaTutuWawa has joined
  511. Zash In any case, it was agreed in the XMPP community long long ago not to shove so much stuff in presence, instead use PEP
  512. nav XEP-0319 is a better example, but as long as it's under control of the user I still don't see the problem
  513. flow xep256 isn't the best example, but it was the best I could dig up in short time
  514. nav Yup, PEP is a good idea.
  515. flow nav, but as I wrote, we had previously XEPs that put the last user tune in presence
  516. Zash OX!
  517. flow so every 3 minutes or so, you would emit a new presence
  518. flow furthermore presence gets amplified by MUCs
  519. flow imagine you are in 3 MUCs with the same people
  520. nav flow: Yeah, I remember that fad!
  521. flow every time someone emits a new presence, you get it 4 times
  522. flow (assuming you are also subscribed to the presence0
  523. flow and finally, I am not sure what a signed presence gets you
  524. Zash I think it might vary a bit actually, some clients don't send presence updates to MUC
  525. flow like what do you do with that information?
  526. flow how would you behave if it wasn't signed
  527. flow how do you behave differently if it was signed?
  528. flow Zash, hmm isn't the server doing that?
  529. flow but you are the expert on that topic :)
  530. Zash Prosody doesn't. Maybe it should? But you get problems.
  531. flow I assumed that MUC presence is based on RFC 6121 § 4.6 Directed Presence
  532. Zash Like, it gets weird if you change nickname. Should the server broadcast your presence to both nicks?
  533. nav flow: "how do you behave differently if it was signed?" Well, that's what I was getting at. I could make certain assumptions as to whether the JID is under control of the same user.
  534. Zash nav, your phone gets stolen. now what?
  535. flow nav, I am not sure if this answers my question
  536. flow could you give a concrete example?
  537. flow don't get me wrong, 20 years ago I also believed that signed presence is cool
  538. flow but today, I see only drawbacks and no advantages of presence signing
  539. nav flow: See the discussion around 1130Z today for background to the discussion.
  540. flow kk
  541. flow and fwiw, I believe signed presences should include a timestamp, for hopefully obvious reasons
  542. flow but then you need to define a time-to-live for those
  543. flow 1h, 3h, 24h, 7d?
  544. nav It all comes from the fact that yesterday I accidentally deleted my account 🙄
  545. flow in any case you now inveted a new mechanism that causes presences updates
  546. Zash Wasn't that one of the problems with XEP-0027, no replay protection?
  547. flow nav, probably the better solution would be a signed pep item in a well-defined pep node
  548. nav But the component I was testing at the time still kept all the information associated with my JID.
  549. nav It dawned on me that the component will wipe out your info if you unregister with it, but not if you unregister from your own server and someone else takes over your JID.
  550. nav flow: That sounds sensible.
  551. marc0s has left
  552. marc0s has joined
  553. flow I get that point, and I think the solution lies in PEP, not in Presence :)
  554. flow you basically want to place a proof of ownership in the PEP node
  555. nav My first thought was some kind of UUID but as was pointed out above that was kind of daft and then someone brought up crypo, and here we are.
  556. nav Indeed that sounds like a good solution! ✔
  557. mh has left
  558. marc0s has left
  559. marc0s has joined
  560. marc0s has left
  561. marc0s has joined
  562. nav I could get people to register a password with the component but the usability is not quite as good.
  563. mh has joined
  564. MSavoritias (fae,ve) has left
  565. nav What about discovering and remembering OMEMO nodes?
  566. MSavoritias (fae,ve) has joined
  567. flow if you work out a protcol with one crypto scheme it is easy to apply to the same to another crypto scheme which is able to sign bytes
  568. nav On second thought, that probably would not work.
  569. flow the main issue is that OMEMO, unlike OpenPGP, has no concept of a primary key
  570. flow at least IIRC
  571. nav Exactly
  572. Sam has left
  573. nav I like the signed PEP node approach. The disadvantage is that it requires explicit client support.
  574. flow how could something like that *not* require explicit support from implementations?
  575. nav I should have said explicit client support which is not there at the moment. ☺
  576. Zash Deploying new things 🤷️
  577. Sam has joined
  578. nav That's why I was hoping to piggyback on signed <presence/> stanzas, as some clients already do those.
  579. flow isn't that always the issue: that we imagine those kewl new protocol extensions, but then suddenly realize that someone needs to implement them? :)
  580. nav The cool thing about the signed PEP is that it could be used by people wanting to prove control over a JID *or a group of JIDs*
  581. Zash open standards go brrr
  582. nav For instance people who have accounts on different servers.
  583. marc0s has left
  584. marc0s has joined
  585. moparisthebest what's it proving? that someone with that private key at some point had access to that account and/or server ?
  586. nav moparisthebest: Yup
  587. nav No more and no less.
  588. Dele Olajide has left
  589. moparisthebest what's the intended way to use that info ?
  590. marc0s has left
  591. marc0s has joined
  592. marc0s has left
  593. marc0s has joined
  594. nav moparisthebest: https://logs.xmpp.org/jdev/2022-07-26?p=h#2022-07-26-8255b4655df233bd
  595. antranigv has left
  596. antranigv has joined
  597. antranigv has left
  598. antranigv has joined
  599. antranigv has left
  600. marc0s has left
  601. marc0s has joined
  602. FireFly has left
  603. FireFly has joined
  604. goffi has left
  605. debacle has left
  606. mirux has left
  607. goffi has joined
  608. xnamed has left
  609. marc0s has left
  610. marc0s has joined
  611. Sam has left
  612. larma has left
  613. Sam has joined
  614. debacle has joined
  615. nicoco_ has joined
  616. thomaslewis has joined
  617. nicoco_ has left
  618. goffi has left
  619. xnamed has joined
  620. nav has left
  621. nav has joined
  622. antranigv has joined
  623. thomaslewis has left
  624. FireFly has left
  625. FireFly has joined
  626. Sam has left
  627. Sam has joined
  628. marc0s has left
  629. marc0s has joined
  630. marc0s has left
  631. marc0s has joined
  632. antranigv has left
  633. antranigv has joined
  634. antranigv has left
  635. marc0s has left
  636. marc0s has joined
  637. marc0s has left
  638. marc0s has joined
  639. marc0s has left
  640. marc0s has joined
  641. Schimon has left
  642. marc0s has left
  643. marc0s has joined
  644. inky has left
  645. marc0s has left
  646. marc0s has joined
  647. marc0s has left
  648. marc0s has joined
  649. Apollo has joined
  650. mirux has joined
  651. goffi has joined
  652. nav has left
  653. nav has joined
  654. inky has joined
  655. inky has left
  656. selurvedu has joined
  657. inky has joined
  658. nicoco_ has joined
  659. nicoco_ has left
  660. marc0s has left
  661. marc0s has joined
  662. larma has joined
  663. Stefan has left
  664. TheRealkarano has left
  665. jubalh has joined
  666. larma has left
  667. nav With reference to the red warning on XEP-0086 (https://xmpp.org/extensions/xep-0086.html)…
  668. nav …considering that I am dealing with handling error conditions in the context of XEP-0030 (https://xmpp.org/extensions/xep-0030.html), I guess I should ignore that warning, right?
  669. Zash https://xmpp.org/rfcs/rfc6120.html#stanzas-error is where you should look for syntax of errors.
  670. nav Thanks!
  671. Zash And service-unavailable is the error you must return for any iq-get or set that you do not understand.
  672. nav Roger that.
  673. nav Is that specified somewhere, off the top of your head?
  674. nav Or just customary practice?
  675. Zash In the RFC I just linked
  676. nav Yup, just found it, ta. https://xmpp.org/rfcs/rfc6120.html#stanzas-error-conditions-service-unavailable
  677. marc0s has left
  678. marc0s has joined
  679. Zash 10.3.3. IQ > If the IQ stanza is of type "get" or "set" and the server does not understand the namespace that qualifies the payload, the server MUST return an error to the sending entity, which MUST be <service-unavailable/>.
  680. jubalh has joined
  681. nav Cool, that makes life easier. ☺
  682. Zash There should also be text to the effect that every iq-get and iq-set must have a matching iq-result or iq-error
  683. kfv has left
  684. kfv has joined
  685. techmetx11 has joined
  686. techmetx11 hi
  687. techmetx11 how would you implement multiple nicknames in a vcard
  688. nav Zash: True
  689. techmetx11 the DTD says that multiple <NICKNAME> elements can exist, but multiple nicknames must be a comma-seperated list
  690. techmetx11 (talking about vcard-temp)
  691. Zash My personal advice: Ignore vcard-temp.
  692. Zash All the cool kids use vcard4
  693. techmetx11 how much servers do you think support vcard4
  694. Zash Also https://xmpp.org/extensions/xep-0172.html
  695. Zash All of them!
  696. Zash All Modern XMPP servers support PEP, and that is all you need for vcard4
  697. techmetx11 Zash: i mean multiple nicknames in a vcard-temp
  698. techmetx11 also the vcard4 xep is deferred
  699. Zash vcard-temp is Historical
  700. Zash aka ugly things from before there was a standards process
  701. techmetx11 ... but still active?
  702. Zash deferred just means it hasn't moved forward in the standards process for a year
  703. techmetx11 if you could just please answer my question
  704. Zash with how slow the standards process is, one year doesn't really mean much
  705. Dele Olajide has joined
  706. Dele Olajide has left
  707. techmetx11 i'll try to send a hand-crafted vcard4 retrival request
  708. techmetx11 and see if it works
  709. techmetx11 has left
  710. techmetx11 has joined
  711. coleman has joined
  712. Zash all I can say is that the Prosody module handling vcard-temp simply takes the XML and saves it as-is
  713. PapaTutuWawa has left
  714. techmetx11 has left
  715. techmetx11 has joined
  716. techmetx11 disroot's server errored out with "No module handling this query"
  717. techmetx11 so i'm gonna assume, that this isn't as widely implemented as it might seem
  718. techmetx11 now anyway, my question was
  719. mirux has left
  720. techmetx11 how do you implement multiple nicknames in a vcard
  721. thomaslewis has joined
  722. thomaslewis has left
  723. thomaslewis has joined
  724. antranigv has joined
  725. antranigv has left
  726. antranigv has joined
  727. kfv has left
  728. kfv has joined
  729. thomaslewis has left
  730. antranigv has left
  731. atomicwatch has left
  732. marc0s has left
  733. Yagizа has left
  734. techmetx11 i'm gonna assume multiple elements
  735. Alacer_dsrt has joined
  736. Alacer_dsrt has left
  737. adx has left
  738. marc0s has left
  739. marc0s has joined
  740. atomicwatch has joined
  741. Zash has left
  742. Zash has joined
  743. marc0s has left
  744. marc0s has joined
  745. kujiu has joined
  746. Patiga has joined
  747. al has joined
  748. wurstsalat has left
  749. marc0s has left
  750. marc0s has joined
  751. thomaslewis has left
  752. thomaslewis has joined
  753. Patiga has left
  754. Patiga has joined
  755. debacle has left
  756. thomaslewis has left
  757. techmetx11 has left
  758. techmetx11 has joined
  759. thomaslewis has joined
  760. atomicwatch has left
  761. nav has left
  762. nav has joined
  763. xnamed has left
  764. techmetx11 has left
  765. techmetx11 has joined
  766. lovetox has left
  767. Kev has left
  768. thomaslewis has left
  769. thomaslewis has joined
  770. lovetox has joined
  771. Kev has joined
  772. thomaslewis has left
  773. thomaslewis has joined
  774. nav techmetx11: I've just tested and multiple elements does not work with ejabberd.
  775. nav In theory, according to the DTD on XEP-0054 it should be allowed, but also the XEP does not prescribe what to do with multiple instances of the same tag. Ejabberd just keeps the last received.
  776. Patiga has left
  777. nav The DTD does say, in a comment, that "Multiple nicknames must be specified as a comma separated list value" (I guess you've already seen that), and that is also how RFC 6350 specifies it: NICKNAME-param = "VALUE=text" / type-param / language-param / altid-param / pid-param / pref-param / any-param NICKNAME-value = text-list (https://datatracker.ietf.org/doc/html/rfc6350#section-6.2.3)
  778. techmetx11 yeah
  779. techmetx11 i was a bit confused
  780. atomicwatch has joined
  781. Alex has left
  782. pasdesushi has left
  783. thomaslewis has left