jdev - 2020-01-21

  1. sonny has left
  2. sonny has joined
  3. debacle has left
  4. kikuchiyo has left
  5. kikuchiyo has joined
  6. kikuchiyo has left
  7. sonny has left
  8. Zash has left
  9. Zash has joined
  10. sonny has joined
  11. kikuchiyo has joined
  12. Zash has left
  13. strar has left
  14. strar has joined
  15. kikuchiyo has left
  16. kikuchiyo has joined
  17. moparisthebest has left
  18. moparisthebest has joined
  19. aj has joined
  20. aj has left
  21. sonny has left
  22. Link Mauve has left
  23. lovetox has joined
  24. kikuchiyo has left
  25. sonny has joined
  26. sonny has left
  27. lovetox rfc says https://tools.ietf.org/html/rfc6120#section-4.4 when closing a stream the side that closes has to wait for a closing in return
  28. lovetox but does that make sense in the case of a stream error?
  29. lovetox i get if i close the stream normally i want to give the other side the oppurtunity to send everything out it was going to send
  30. lovetox but in the case of a stream error, i will ignore anything anyway
  31. paul has joined
  32. sonny has joined
  33. asterix has joined
  34. kikuchiyo has joined
  35. asterix has left
  36. asterix has joined
  37. lovetox has left
  38. asterix has left
  39. asterix has joined
  40. sonny has left
  41. MattJ lovetox: if you'll ignore then yes. But does the RFC even allow clients to send stream errors?
  42. Zash has joined
  43. pulkomandy has left
  44. pulkomandy has joined
  45. sonny has joined
  46. Meta Bergman has left
  47. Meta Bergman has joined
  48. Meta Bergman has left
  49. Meta Bergman has joined
  50. wurstsalat has joined
  51. lovetox has joined
  52. lovetox yes MattJ why not
  53. sonny has left
  54. pulkomandy has left
  55. pulkomandy has joined
  56. kikuchiyo has left
  57. pulkomandy has left
  58. Zash has left
  59. pulkomandy has joined
  60. Zash has joined
  61. kikuchiyo has joined
  62. leosbrf has joined
  63. larma has left
  64. kikuchiyo has left
  65. larma has joined
  66. Alex has left
  67. Alex has joined
  68. pulkomandy has left
  69. kikuchiyo has joined
  70. pulkomandy has joined
  71. kikuchiyo has left
  72. pulkomandy has left
  73. pulkomandy has joined
  74. sonny has joined
  75. kikuchiyo has joined
  76. asterix has left
  77. asterix has joined
  78. lovetox has left
  79. lovetox has joined
  80. debacle has joined
  81. sonny has left
  82. kikuchiyo has left
  83. flow lovetox, why do you have to ignroe any inbound stanzas on stream errors?
  84. Wojtek has joined
  85. lovetox if i receive not well formed xml from the server
  86. lovetox and end the stream with a stream error
  87. lovetox why or how would it make sense to wait for more xml from the server?
  88. lovetox stream errors are not recoverable, means to me, all xml parsing ends right there
  89. flow ok, but thinking about the generic case, not the specific case where you can't recover from an ill formed xml stream
  90. goffi has joined
  91. flow nothing forces you to not wait for the other side to close the stream and continue processing inbound stanzas
  92. pulkomandy has left
  93. lovetox nothing forces me, but then i would ignore the "unrecoverable" rule for stream errors
  94. lovetox as i would still wait and parse inbound stanzas even after an stream error
  95. flow I think the rule leaves room for interpretation
  96. lovetox that was not my question, if i *could* do it
  97. lovetox may question was does it make sense
  98. lovetox is there a case where i want data from the server even after he violated basic rules of a stream
  99. flow If you can process the data, then I don't see and advantage by not doing it
  100. flow *an advantage
  101. pulkomandy has joined
  102. flow If you can process the data, then I don't see an advantage by not doing it
  103. flow hast to learn how poezio does autocorrect
  104. lovetox but there is no stream error other than malformed xml ones
  105. lovetox that client could send
  106. lovetox most stream errors are related to server actions
  107. lovetox like conflict, host-gone, not-authorized
  108. lovetox etc
  109. lovetox but yeah from the examples, i think its expected to send a close stream back even on error
  110. lovetox maybe malformed-xml is the exception where it really makes no sense
  111. flow What about errors on the layer above xml, like using XML mixed content, which is allowed by XML but disallowed in XMPP
  112. pulkomandy has left
  113. pulkomandy has joined
  114. pep. flow, /correct
  115. flow pep., and then I have to type the whole message again? Or is the idea that I select the message from the history, prefix it with '/correct', then correct it and hit enter?
  116. pep. /correct <tab>
  117. pep. Then you can edit and resend
  118. pep. But you can also /correct anothermessageinstead
  119. flow ahh
  120. flow ohh
  121. flow ui
  122. pep. And poezio doesn't yet implement the LMC "clarification"
  123. flow the "strike the last" from LMC?
  124. pep. no, the "always use the first id"
  125. pep. Otherwise yes in reading we do "Message Correction", not Last Message Correction.
  126. pep. We only send the last via /correct, but you can do /rawxml :x
  127. sonny has joined
  128. kikuchiyo has joined
  129. lovetox another problem, say i send close stream
  130. lovetox and the server answers with more stanzas because i let him like the XEP suggests
  131. lovetox i cant ack these messages anmore via streammanagement
  132. lovetox so the server will think i didnt get those messages
  133. lovetox ..
  134. MattJ You can if you resume
  135. lovetox does close stream not mean i cant resume?
  136. MattJ Oh, right :)
  137. MattJ Yeah
  138. lovetox i think it causes more complexity and problems if after stream close, i wait for a stream close in return or any other stanza
  139. lovetox i dont see any benefit for client or server
  140. kashi has joined
  141. pulkomandy has left
  142. pulkomandy has joined
  143. aj has joined
  144. jonas’ lovetox, the stanzas could still have been in flight
  145. jonas’ if your link has latency
  146. jonas’ you need some way to deal with this, even though "drop everything and log errors" may be a valid way
  147. Zash Resource-*un*-binding before /stream?
  148. jonas’ you still have to deal with stanzas which are in-flight when you send your unbind
  149. jonas’ same difference
  150. asterix has left
  151. asterix has joined
  152. aj has left
  153. kashi has left
  154. Zash send un-bind, maybe receive stanzas, receive unbind-ack, send /stream, receive /stream
  155. jonas’ how’s that different from send /stream, maybe receive stanzas, receive /stream?
  156. Zash you can maybe send sm:a?
  157. jonas’ ah, that
  158. jonas’ yeah
  159. Zash more roundtrips!
  160. pulkomandy has left
  161. Zash gotta add some after removing from the start
  162. flow Zash, I thought about that too, sure adds complexitly, which always opens up the discussion if its worth it
  163. Zash probably not
  164. flow Zash, I thought about that too, sure adds complexitly, which always opens up the discussion if it's worth it
  165. Zash can get Close Enough ™ with unavailable presence I guess
  166. flow yeah, but nice to think about it
  167. kikuchiyo has left
  168. goffi has left
  169. goffi has joined
  170. pulkomandy has joined
  171. Link Mauve has joined
  172. kikuchiyo has joined
  173. kikuchiyo has left
  174. pulkomandy has left
  175. Syndace has left
  176. pulkomandy has joined
  177. Syndace has joined
  178. Kev has joined
  179. leosbrf Hi all, when an user join a private room, I don't want him to have access to previous messages, only new messages. Is there a way I can accomplish that?
  180. Zash Yes, this can be implemented
  181. Zash Not aware of any publicly available such implementations tho
  182. kikuchiyo has joined
  183. leosbrf Thank you, Zash. So I would have to write a module for this? I'm new to XMPP and currently I'm using ejabberd. Could you give me some references on how to get started on that?
  184. leosbrf links with docs or tutorials, besides ejabberd website itself, if any.
  185. Zash I can't do better than your favorite search engine I'm afraid
  186. kikuchiyo has left
  187. leosbrf no problem, thanks anyway
  188. kikuchiyo has joined
  189. pulkomandy has left
  190. pulkomandy has joined
  191. kikuchiyo has left
  192. flow leosbrf, you may also want to ask this in the official ejabberd muc
  193. pulkomandy has left
  194. sonny has left
  195. pulkomandy has joined
  196. sonny has joined
  197. debacle has left
  198. pulkomandy has left
  199. pulkomandy has joined
  200. kikuchiyo has joined
  201. kikuchiyo has left
  202. kikuchiyo has joined
  203. pulkomandy has left
  204. pulkomandy has joined
  205. kikuchiyo has left
  206. kikuchiyo has joined
  207. asterix has left
  208. pulkomandy has left
  209. lovetox has left
  210. pulkomandy has joined
  211. sonny has left
  212. sonny has joined
  213. sonny has left
  214. lovetox has joined
  215. pulkomandy has left
  216. wurstsalat has left
  217. pulkomandy has joined
  218. asterix has joined
  219. wurstsalat has joined
  220. debacle has joined
  221. pulkomandy has left
  222. asterix has left
  223. asterix has joined
  224. pulkomandy has joined
  225. asterix has left
  226. asterix has joined
  227. sonny has joined
  228. lovetox has left
  229. sonny has left
  230. pulkomandy has left
  231. sonny has joined
  232. lovetox has joined
  233. sonny has left
  234. pulkomandy has joined
  235. sonny has joined
  236. asterix has left
  237. asterix has joined
  238. Wojtek has left
  239. pulkomandy has left
  240. asterix has left
  241. asterix has joined
  242. asterix has left
  243. asterix has joined
  244. pulkomandy has joined
  245. sonny has left
  246. leosbrf has left
  247. asterix has left
  248. asterix has joined
  249. sonny has joined
  250. asterix has left
  251. asterix has joined
  252. debacle has left
  253. asterix has left
  254. asterix has joined
  255. pulkomandy has left
  256. pulkomandy has joined
  257. sonny has left
  258. asterix has left
  259. asterix has joined
  260. asterix has left
  261. asterix has joined
  262. pulkomandy has left
  263. pulkomandy has joined
  264. sonny has joined
  265. asterix has left
  266. asterix has joined
  267. sonny has left
  268. asterix has left
  269. asterix has joined
  270. sonny has joined
  271. pulkomandy has left
  272. pulkomandy has joined
  273. sonny has left
  274. strar has left
  275. strar has joined
  276. strar has left
  277. pulkomandy has left
  278. strar has joined
  279. strar has left
  280. strar has joined
  281. strar has left
  282. strar has joined
  283. strar has left
  284. strar has joined
  285. strar has left
  286. pulkomandy has joined
  287. debacle has joined
  288. sonny has joined
  289. lovetox has left
  290. lovetox has joined
  291. pulkomandy has left
  292. pulkomandy has joined
  293. asterix has left
  294. marc0s hi, is there some XEP or part of Core that defines capabilities for registered accounts? something like userA cannot make use of the MAM or Carbons, for instance? Something like different kind of accounts with different sets of permissions
  295. Ge0rG marc0s: that sounds like a policy configuration, not a protocol. What would you write down in the xep?
  296. sonny has left
  297. marc0s Ge0rG, that sounds right, indeed. Maybe I'd like to have a way to query that policy. We've been asked for some weird (IMHO) requirement where some kind of accounts would only be allowed to receive messages, not sending them, but at the same time, senders should be aware of the recipient will not be able to answer because of that policy. I was just wondering if something already existed for that before inventing our own (basically doing that check out of band)
  298. Ge0rG marc0s: you might be able to appropriate https://xmpp.org/extensions/xep-0317.html (Hats) or https://xmpp.org/extensions/xep-0310.html Presence State Annotations
  299. Ge0rG but I'm sure there is no in-the-wild client support for either
  300. marc0s thanks Ge0rG. Client support is not an issue, we're rolling our own, based on stanzajs. Will have a look at that XEPs
  301. lovetox em, disco info comes to mind?
  302. lovetox but instead of routing it to the users, let the server answer with the caps for this account
  303. lovetox so a little server addon :)
  304. moparisthebest A: "can you send messages" B: "no but since I can't send messages I can't reply" A: *still waiting for response*
  305. strar has joined
  306. pulkomandy has left
  307. marc0s lovetox, yes, disco can be another way of solving this. Actually the XEP states than when querying a bare jid, it's the server who should answer, if I didn't misread it... so maybe yes, that's something a module can solve
  308. marc0s moparisthebest, :D
  309. lovetox has left
  310. pulkomandy has joined
  311. debacle has left
  312. debacle has joined
  313. debacle has left
  314. wurstsalat has left
  315. debacle has joined
  316. sonny has joined
  317. goffi has left
  318. sonny has left
  319. debacle has left
  320. debacle has joined
  321. paul has left
  322. larma has left
  323. mathieui has joined
  324. larma has joined
  325. aj has joined