jdev - 2021-07-02

  1. emus has left
  2. pasdesushi has left
  3. gutuning has left
  4. gutuning has joined
  5. debacle has left
  6. dezant has left
  7. dezant has joined
  8. gutuning has left
  9. gutuning has joined
  10. lovetox has left
  11. dezant has left
  12. wurstsalat has left
  13. dezant has joined
  14. mac has joined
  15. lovetox has joined
  16. idk has left
  17. marc0s has left
  18. marc0s has joined
  19. dezant has left
  20. dezant has joined
  21. idk has joined
  22. idk has left
  23. hardweary has joined
  24. Burn has joined
  25. hardweary has left
  26. hardweary has joined
  27. idk has joined
  28. mac has left
  29. mac has joined
  30. Burn has left
  31. Yagizа has joined
  32. Burn has joined
  33. dezant has left
  34. dezant has joined
  35. Burn has left
  36. kikuchiyo has joined
  37. wurstsalat has joined
  38. şişio has joined
  39. idk has left
  40. hardweary has left
  41. idk has joined
  42. mikeye has joined
  43. şişio has left
  44. şişio has joined
  45. asterix has left
  46. asterix has joined
  47. Yagizа has left
  48. goffi has joined
  49. Burn has joined
  50. mikeye has left
  51. dezant has left
  52. idk has left
  53. emus has joined
  54. gutuning has left
  55. 512bit has joined
  56. 512bit What are the typical transfer speeds achieved during a jingle file transfer?
  57. jonas’ 512bit, whatever the link between the two clients can achieve
  58. jonas’ there is no "typical" number there
  59. jonas’ depends on the negotiated transfer method
  60. asterix has left
  61. asterix has joined
  62. mac has left
  63. marc has joined
  64. kikuchiyo has left
  65. marc has left
  66. marc has joined
  67. kikuchiyo has joined
  68. nixi has joined
  69. idk has joined
  70. gutuning has joined
  71. FireFly has joined
  72. Zash has left
  73. mac has joined
  74. debacle has joined
  75. nixi has left
  76. gutuning has left
  77. şişio has left
  78. gutuning has joined
  79. pasdesushi has joined
  80. gutuning has left
  81. kikuchiyo has left
  82. pasdesushi has left
  83. kikuchiyo has joined
  84. şişio has joined
  85. pasdesushi has joined
  86. mac has left
  87. pasdesushi has left
  88. marc has left
  89. gutuning has joined
  90. marc has joined
  91. pasdesushi has joined
  92. pep. has left
  93. pep. has joined
  94. pasdesushi has left
  95. pasdesushi has joined
  96. pasdesushi has left
  97. pasdesushi has joined
  98. pep. has left
  99. pep. has joined
  100. pasdesushi has left
  101. pasdesushi has joined
  102. Alex has left
  103. Alex has joined
  104. şişio has left
  105. pasdesushi has left
  106. Zash has joined
  107. edhelas has left
  108. edhelas has joined
  109. şişio has joined
  110. pep. has left
  111. pep. has joined
  112. x51 has joined
  113. emus has left
  114. gutuning has left
  115. gutuning has joined
  116. emus has joined
  117. moparisthebest has left
  118. moparisthebest has joined
  119. Alex has left
  120. nephele has joined
  121. Alex has joined
  122. Wojtek has joined
  123. gutuning has left
  124. mikeye has joined
  125. pasdesushi has joined
  126. Wojtek has left
  127. Wojtek has joined
  128. pasdesushi has left
  129. pasdesushi has joined
  130. kikuchiyo has left
  131. pasdesushi has left
  132. pasdesushi has joined
  133. pasdesushi has left
  134. pasdesushi has joined
  135. mikeye has left
  136. pasdesushi has left
  137. wellsfargo@exploit.im has joined
  138. wellsfargo@exploit.im has left
  139. pasdesushi has joined
  140. kikuchiyo has joined
  141. pasdesushi has left
  142. gutuning has joined
  143. Burn has left
  144. kikuchiyo has left
  145. şişio has left
  146. gutuning has left
  147. Alex has left
  148. Alex has joined
  149. Sam Okay, trying again to phrase a problem that's been bugging me, maybe someone here will have insights. I'm building a MUC library and it's showing me the weaknesses in my core XMPP library. One is that I have no way to track stanza errors (other than IQs). When I send a join presence for the MUC for instance, I always expect a response so I block until receivnig it, something like muc.Join(timeout, jid) roomOrError. This works for the self-presence because the MUC handler is tracking all presence payloads that have the <x xmlns="muc#user"/> or whatever in them so it can associate the response and hand it back. It can't hand back an error though because that is not a MUC specific payload and it doesn't know about it.
  150. Sam So instead I thought about having a general xmpp.SendPresence(timeout, presence) error that will block until it gets a presence error. I can call that from within muc.Join to send the presence, then if the success response happens I can cancel the timeout (don't worry about that, just realize that timeouts can be canceled early) and return it, otherwise we wait for the error until the timeout is hit and then return an error if no error or success was received.
  151. Sam However, this feels wrong. Using xmpp.SendPresence or whatever the *expected* behavior will be that it times out and returns that it timed out 90% of the time (since we hopefully don't get presence errors often). It works for the MUC case, but for genreally using it it feels weird.
  152. Sam Has anyone else run into something like this?
  153. kikuchiyo has joined
  154. larma has left
  155. larma has joined
  156. MattJ I think the summary of what you're trying to say is that in some cases in XMPP there is no explicit success response
  157. MattJ Which is indeed the case
  158. Kev I have generally found that I don’t need stateful errors for very much outside iqs.
  159. MattJ Yet any stanza can trigger an error, that you would want to handle
  160. Sam Heh, yes, I suppose that's all I was saying with all of that. It makes it hard to track errors because the timeout is indeterminant (sp?).
  161. Zash I
  162. Sam Normally it's not a problem for that reason, but MUCs it can be since I want to block until the join was successful or an error is received (or the timeout is hit). It makes more sense to have the timeout only if there is an error and a success case
  163. Kev You can always* use ids for tracking errors to particular stanzas if you care.
  164. MattJ I think the answer is partly as Kev says - the stanzas without an explicit success /usually/ don't need one for practical use-cases
  165. Sam Kev: yah, that's what we're talking about
  166. Kev When you say block, I assume you mean that a MUC join is happening in its own coroutine that you’re blocking, not that you’re blocking the calling site?
  167. Zash I've thought about this too. Not sure I'd want anything blocking, but some way to race a timer came to mind.
  168. Sam Yes, sorry blocking a coroutine.
  169. Kev (Since MUC joins you generally want to be async and to continue processing other data while you wait for them)
  170. Sam Blocking is the normal and expected behavior for things like this; the user can always await it if they want it in the background (more or less)
  171. Kev Right.
  172. Kev Blocking the join, not blocking the caller.
  173. Sam The issue is more or less that if I've registered a "muc" handler the success case gets picked up (it's a MUC specific payload), the error case doesn't (unless I want the MUC handler to handle *all* error presences)
  174. Kev I’m missing why it’s hard to timer this (probably my fault).
  175. Sam The timer isn't the issue, that part is fine
  176. Sam Sorry, I've been struggling to explain this; not your fault.
  177. Zash It's even more fun. The true completion signal is the subject message 🙂
  178. Zash For a MUC join at least.
  179. Kev What we do in Swift is we start a timer on join. If we succeed the timer’s cancelled. If it doesn’t succeed and the timer fires the user is warned that the join probably won’t complete - but you could easily hard fail instead.
  180. Sam hmm, good point, I was taking the completion message to be the self-presence.
  181. Zash A way to have composable completion events might be nice.
  182. Kev Zash: Ah. It’s the subject message…or the first non-history message because some servers don’t send a subject. Although that was an old ejabberd bug, and it’s probably been fixed for a decade.
  183. Sam Kev: that's what we do as well. I'd also like it to be able to return the presence error (if any) though.
  184. Zash Then you could take a message and a timer, or a message and a thing that watches for a message receipt, or a presence and a thing that watches for the subject.
  185. Kev Sam: But that’s easy enough, isn’t it? If you get a presence error reply to your join stanza, you have the error.
  186. Sam Kev: right, but this is a MUC handler that receivese MUC paylods. The presence error is a normal generic one, not a MUC specific thing. So I'd have to listen for *all* presences in the MMUC handler to do that. This isn't actually how my library works right now, and it seems like there is a better way.
  187. jonas’ Sam, make a thing which allows you to listen to presences with a specific ID
  188. Kev I would personally just listen to all presences, and check the id. Or have a ‘tell me if this id comes in’ handler.
  189. Sam Right, so like I said in the orignial post if I do that it works okay for MUCs, but then if the user uses it the API feels weird:
  190. jonas’ then it’s tied semantically to the MUC by the ID and it’s less ugly
  191. Kev But I would very very much not make sending presence into a thing with a reply handler, because 99% of the time that’s just pointless.
  192. Sam xmpp.SendPresence(timeout, presence) error or whatever. The expected case is that the timeout is triggered momst of the time. Feels weird.
  193. Kev Yes. That is what I would not do.
  194. Sam Right, what Kev said
  195. jonas’ Sam, how about xmpp.WaitPresenceError(timeout, id)?
  196. Sam Works great for MUC, not great for 90% of other cases :)
  197. Sam jonas’: yah, that's what I was saying (more or less)
  198. jonas’ and keep xmpp.SendPresence fire-and-forget naive
  199. Kev But why not make xmpp.SendPresence(presence, optionalHandler, optionalTimer)?
  200. Kev Off for lunch :)
  201. Zash Kev, it may have been Prosody (too) which didn't used to send a subject if the subject was empty/unset. Fixed now anyways.
  202. Sam That's what I've done right now (ish). There's Send for sending any general stanza in a fire-and-forget way, SendPresence for sending a presence specifically and waiting for an error (or timnig out).
  203. Sam And a bunch of other sort of related things that don't matter.
  204. kikuchiyo has left
  205. Sam Anyways, maybe this is the only way with how I have this structured (or give the MUC thing access to all presences and what not, but that feels wrong) and the answer is "Okay, SendPresence is weird, don't use it most of the time"
  206. Sam Thanks for the brainstorming.
  207. jonas’ fwiw, it seems that aioxmpp does not track presence errors during muc join based on the ID but on the from
  208. Sam I thought about adding a way to track based on from so that any errors from a specific thing get forwarded to the MUC handler but that requires being able to modify the handler at runtime (eg. when we join a room, add "chat.myserver.com" to the valid from) which bothers me a bit, and also means that every separate plugin has to do its own id (or from) tracking internally to match responses with requests instead of the main XMPP handler thing just doing it for everything
  209. Sam But maybe that would be better than adding weird SendPresence functions that are expected to fail
  210. Sam (or timeout, rather)
  211. gutuning has joined
  212. Burn has joined
  213. Sam Hmm, now the subject thing is bothering me a bit. Does it matter if they can do things before the message history is sent, or should I block until the subject is set? I can't tell that it would matter, you might just send a message before getting context back, which feels weird but isn't the end of the world. Also I'm kind of assuming a MUC-MAM future anyways, so I dunno if I care about history/subject as much.
  214. gutuning has left
  215. Kev > fwiw, it seems that aioxmpp does not track presence errors during muc join based on the ID but on the from Pretty sure that’s what we did in Swiften, without checking.
  216. pasdesushi has joined
  217. jonas’ Sam, aioxmpp doesn’t prevent you from doing things before the subject was received. It only uses it as a marker for when to start trusting nickname<->jid relationships because it has up-to-date presence or somesuch (I’d have to look it up).
  218. Sam Makes sense; for now I'll probably consider join successful on self-presence then. We'll see if I use subject for anything later (so far I haven't even looked at that and am not tracking the subject at all)
  219. Zash It would be weird for the join to fail between self-presence and subject.
  220. Sam As far as I can tell from the spec it can't, you're actually done once you get self-presence. Subject is just something that might or might not show up later.
  221. Kev Zash: What if the server has to hit storage to fetch the subject, but not the members? That *might* mean a noticable delay between them.
  222. Sam (it's a SHOULD, so it probably will, but I don't see anything that relies on it)
  223. Kev But ultimately a network can fail at any point.
  224. Zash True. The whole thing could crash at any moment!
  225. Kev Sam: What relies on it is it’s what implementations use for knowing the join’s complete :)
  226. Zash Sam, hm? I thought sending subject was mandatory
  227. Kev SHOULD doesn’t mean OPTIONAL, it means “Things might break if you don’t do this, so be sure you know what you’re doing” ;)
  228. Sam Kev: why rely on that instead of getting self-presence?
  229. Kev Sam: Because presence comes before history.
  230. Sam I mean, if it's what everything does I can do that too, the spec just makes it sound like self-presence is the thing that means you're joined. What does it matter if I've gotten history or not yet?
  231. Kev And you almost always want to know what’s live messages and what’s join context.
  232. pasdesushi has left
  233. Kev So you need the subject to know you’re done with the history and everything after will be live changes.
  234. Sam Oh yah, I guess I might want to draw a line after history or something to distinguish it for the user
  235. Kev Also, subject is a MUST.
  236. Kev Not SHOULd :)
  237. Kev Not SHOULD :)
  238. Sam oops, so it is. Weird, I swear I just read that and it said SHOULD.
  239. Zash SHALL == MUST?
  240. Sam Yes
  241. Zash Words.
  242. Sam Still, I'm joined after self-presence. When I get subject, I can draw the line and start live messages. Does it matter that I was already joined?
  243. Sam Anything I send I'll still get the reflection back after the history (I assume).
  244. Zash If you wanna have a "ready" signal, separate from "success", I suppose.
  245. Zash May matter for UI stuff.
  246. Sam What's the difference between "ready" and "success", I guess?
  247. Sam I just don't see how it would matter in the UI or anything
  248. pasdesushi has joined
  249. Zash If you wanna show a spinner or something while it's throwing history at you?
  250. Sam In that case it seems like I'd just do the Join, show the spinner, then when I get the history back I'd clear the spinner. I don't have to block the join call on it.
  251. Zash I think some clients don't let you start writing until then
  252. Sam The writing thing makes sense, but this is a library so the clients could always still do that.
  253. Sam Returning on self-presence seems more flexible in that way; clients can still do either. If I return on subject they are stuck with that.
  254. Sam But also I have a nagging suspicion that if everyone else does subject there's probably a good reason that actually will break later that I'm not thinking of.
  255. Kiwi has joined
  256. kikuchiyo has joined
  257. pasdesushi has left
  258. kikuchiyo has left
  259. pasdesushi has joined
  260. Yagizа has joined
  261. Sam > // SendPresence is like Send except that it returns an error if the first token > // read from the stream is not a Presence start token and blocks until an error > // response is received or the context times out. > // Presences are generally fire-and-forget meaning that the success behavior of > // SendPresence is to time out and that methods such as Send should normally be > // used instead. > // It is thus mainly for use by extensions that define an extension-namespaced > // success response to a presence being sent and need a mechanism to track > // general error responses without handling every single presence sent through > // the session to see if it has a matching ID. > // > // SendPresence is safe for concurrent use by multiple goroutines. Good enough (I hope).
  262. Sam Thanks again for all the help.
  263. Zash Sam, what's that about returning an error if not reading a presence from the stream?
  264. pasdesushi has left
  265. Sam Wrong type of stream, it's confusing out of context but it copies XML tokens so you'd do SendPresence(timeout, Presence{Type: whatever}.Wrap(somepayload)) which returns an XML token stream that gets copied to the XMPP stream.
  266. Sam See SendIQ (https://pkg.go.dev/mellium.im/xmpp#Session.SendIQ) for an already existing example.
  267. Sam I should probably not re-use "stream" in the docs, that's confusing.
  268. kikuchiyo has joined
  269. Zash Sounds a bit overloaded, yes.
  270. Sam "first token read from the reader" or something will fix that. Done.
  271. Sam Or "from the input".
  272. Sam There are now 16 basic sending methods that match (Send|Encode)(Message|Presence|IQ)?(Element)?
  273. Sam I don't love that, but it does work quite well in my experience so far even if it's a lot of options.
  274. emus has left
  275. emus has joined
  276. 512 has joined
  277. larma has left
  278. dezant has joined
  279. 512 has left
  280. 512bit has left
  281. pasdesushi has joined
  282. larma has joined
  283. pasdesushi has left
  284. pasdesushi has joined
  285. pasdesushi has left
  286. pasdesushi has joined
  287. gutuning has joined
  288. pasdesushi has left
  289. Yagizа has left
  290. FireFly has left
  291. Burn has left
  292. debacle has left
  293. Burn has joined
  294. FireFly has joined
  295. Yagizа has joined
  296. emus has left
  297. Burn has left
  298. paul has left
  299. paul has joined
  300. paul has left
  301. paul has joined
  302. gutuning has left
  303. gutuning has joined
  304. emus has joined
  305. FireFly has left
  306. marc has left
  307. marc0s has left
  308. marc0s has joined
  309. Burn has joined
  310. Alex has left
  311. Alex has joined
  312. is_bru has joined
  313. gutuning has left
  314. is_bru Does anyone still use talkonaut?
  315. is_bru has left
  316. FireFly has joined
  317. Kiwi has left
  318. Martin What is a talkonaut?
  319. Sam Looks like it's similar to jmp.chat? The website doesn't work for me, so I dunno if it still exists or not.
  320. marc has joined
  321. Martin Ah, so a telephone xmpp transport. Never used one of those.
  322. moparisthebest > Talkonaut by GTalk2VoIP, Inc.
  323. moparisthebest Hehe
  324. MattJ Wow, haven't heard of Talkonaut for a while
  325. sonny has left
  326. gutuning has joined
  327. sonny has joined
  328. Martin GTalk2VoIP sounds like it's long dead also.
  329. Martin When was gtalk switched off?
  330. MattJ Never, it's still going I think :)
  331. MattJ Still responding on 5222 anyway
  332. gutuning has left
  333. Burn has left
  334. Martin Oh, I thought it's dead for a long time already.
  335. Holger s2s is dead, c2s isn't.
  336. kikuchiyo has left
  337. MattJ Yeah, they announced it was. Then it continued to work for years. Then they eventually turned off s2s (which nobody used anyway because it didn't do TLS). Now they're shutting down Hangouts, which is likely tied up in the same infrastructure, so it possibly might actually disappear soon.
  338. Martin Is there even a client nowadays? Can't really follow googles pace of inventing and killing chat systems. 😁
  339. MattJ You can use any XMPP client, but it only really works with other XMPP clients. If people are using the Google Hangouts client they appear online but don't receive messages.
  340. kikuchiyo has joined
  341. MattJ All that based on old observations, I haven't poked around in the past year or so
  342. Martin Sounds like a long forgotten service running on a long forgotten machine in the basement. 😂
  343. MattJ Well, that Hangouts users appear online suggests it's all the same infrastructure, and the Hangouts conferences in the browser used XMPP for signalling even after they announced the end of GTalk, so it's very likely still all production.
  344. MattJ But now Hangouts is supposedly dead (EOL June), all that may change
  345. Link Mauve MattJ, s2s also didn’t let outsiders communicate with Hangouts users, fyi.
  346. MattJ or they may just keep it limping along for those few enterprise customers who insist they can't live without it
  347. Link Mauve With an extremely annoying failure model, where our messages would simply get redirected to /dev/null.
  348. MattJ Yeah
  349. emus has left
  350. Martin Just pretend it never existed and keep on working on xmpp world domination. 😃
  351. emus has joined
  352. Burn has joined
  353. Link Mauve Also Hangouts video calls from the Firefox plugin were printing MUC and Jingle debug stuff on stderr.
  354. marc has left
  355. marc has joined
  356. FireFly has left
  357. sonny has left
  358. Yagizа has left
  359. Wojtek has left
  360. Yagizа has joined
  361. Kiwi has joined
  362. sonny has joined
  363. gutuning has joined
  364. gutuning has left
  365. nephele has left
  366. FireFly has joined
  367. nephele has joined
  368. debacle has joined
  369. kikuchiyo has left
  370. kikuchiyo has joined
  371. kamui has joined
  372. kamui Is there a way I can upload files when using encryption?
  373. kamui Is there a way I can upload files?
  374. kamui everytime I try to do it, it just errors out with "File transfer failed"
  375. kamui https://imgur.com/a/sbAyQ0m
  376. Burn has left
  377. kamui has left
  378. mac has joined
  379. paul has left
  380. paul has joined
  381. kikuchiyo has left
  382. hardweary has joined
  383. nephele has left
  384. kamui has joined
  385. marc has left
  386. marc has joined
  387. nephele has joined
  388. kamui has left
  389. kikuchiyo has joined
  390. mac has left
  391. kamui has joined
  392. hardweary has left
  393. hardweary has joined
  394. gutuning has joined
  395. x51 has left
  396. Martin What server do you use?
  397. gutuning has left
  398. asterix has left
  399. asterix has joined
  400. mac has joined
  401. gutuning has joined
  402. kamui sqli.io
  403. gutuning has left
  404. mac has left
  405. debacle has left
  406. 512 has joined
  407. idk has left
  408. selurvedu has joined
  409. idk has joined
  410. 512 has left
  411. Yagizа has left
  412. alacer has left
  413. dezant has left
  414. kikuchiyo has left
  415. gutuning has joined
  416. selurvedu has left
  417. selurvedu has joined
  418. FireFly has left
  419. kikuchiyo has joined
  420. FireFly has joined
  421. pasdesushi has joined
  422. kikuchiyo has left
  423. dezant has joined
  424. kikuchiyo has joined
  425. alacer has joined
  426. pasdesushi has left
  427. idk has left
  428. idk has joined
  429. alacer has left
  430. kikuchiyo has left
  431. goffi has left
  432. gutuning has left
  433. gutuning has joined
  434. FireFly has left
  435. debacle has joined
  436. pasdesushi has joined
  437. nephele has left
  438. debacle has left
  439. marc0s has left
  440. marc0s has joined
  441. asterix has left
  442. asterix has joined
  443. kikuchiyo has joined
  444. alacer has joined
  445. paul has left
  446. paul has joined
  447. paul has left
  448. paul has joined
  449. 512 has joined
  450. gutuning has left
  451. asterix has left
  452. asterix has joined
  453. paul has left
  454. paul has joined
  455. pasdesushi has left
  456. paul has left
  457. paul has joined
  458. pasdesushi has joined
  459. 512 has left
  460. gutuning has joined
  461. debacle has joined
  462. şişio has joined
  463. asterix has left
  464. asterix has joined
  465. idk has left
  466. asterix has left
  467. idk has joined
  468. asterix has joined
  469. şişio has left
  470. pasdesushi has left
  471. şişio has joined
  472. pasdesushi has joined
  473. wurstsalat has left
  474. pasdesushi has left
  475. pasdesushi has joined
  476. şişio has left
  477. pasdesushi has left
  478. pasdesushi has joined
  479. debacle has left
  480. hardweary has left
  481. dezant has left
  482. dezant has joined
  483. paul has left
  484. pasdesushi has left