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