XSF Discussion - 2017-12-10

  1. jubalh has joined
  2. sonny has joined
  3. jubalh has left
  4. vanitasvitae has left
  5. vanitasvitae has joined
  6. daniel has joined
  7. daniel has left
  8. la|r|ma has joined
  9. daniel has joined
  10. moparisthebest has joined
  11. zinid has joined
  12. moparisthebest has joined
  13. zinid has left
  14. jubalh has joined
  15. la|r|ma has joined
  16. la|r|ma has joined
  17. daniel has left
  18. daniel has joined
  19. zinid has joined
  20. daniel has left
  21. zinid has left
  22. jubalh has left
  23. daniel has joined
  24. daniel has left
  25. daniel has joined
  26. daniel has left
  27. daniel has joined
  28. daniel has left
  29. tux has left
  30. tux has joined
  31. moparisthebest has left
  32. Tobias has joined
  33. zinid has joined
  34. zinid has left
  35. ThurahT has left
  36. ThurahT has joined
  37. daniel has joined
  38. ralphm has joined
  39. sonny has left
  40. arc has left
  41. arc has joined
  42. moparisthebest has joined
  43. arc has left
  44. arc has joined
  45. jjrh has left
  46. jjrh has left
  47. daniel has left
  48. daniel has joined
  49. efrit has left
  50. jjrh has left
  51. daniel has left
  52. daniel has joined
  53. valo has left
  54. valo has joined
  55. jjrh has left
  56. daniel has left
  57. jjrh has left
  58. jjrh has left
  59. jjrh has left
  60. SamWhited has left
  61. uc has joined
  62. valo has left
  63. valo has joined
  64. @Alacer has joined
  65. daniel has joined
  66. daniel has left
  67. @Alacer has left
  68. @Alacer has joined
  69. jjrh has left
  70. zinid has joined
  71. ralphm has left
  72. zinid Yeah, and they should be square (or round, council would decide it)
  73. daniel has joined
  74. lskdjf has joined
  75. ralphm has joined
  76. daniel has left
  77. daniel has joined
  78. zinid has left
  79. ralphm has left
  80. valo has left
  81. valo has joined
  82. valo has joined
  83. ralphm has joined
  84. la|r|ma has joined
  85. daniel has left
  86. arc has left
  87. arc has joined
  88. zinid has joined
  89. ralphm has left
  90. daniel has left
  91. daniel has left
  92. zinid has left
  93. daniel has left
  94. daniel has left
  95. moparisthebest has joined
  96. daniel has joined
  97. daniel has left
  98. daniel has joined
  99. ralphm has joined
  100. SouL has left
  101. daniel has left
  102. zinid has left
  103. daniel has joined
  104. Ge0rG No, they need to be properly displayable in both round and square elements, and they also need a secondary graphic that can be used as a 16:9 background
  105. marc has joined
  106. daniel has left
  107. daniel has joined
  108. edhelas Ge0rG for this I'd advice to add a "background" picture, like on many other social networks
  109. zinid has left
  110. Ge0rG And we also need a sarcasm tag!
  111. edhelas :X
  112. Ge0rG Or at least an according Emoji
  113. daniel has left
  114. ralphm has joined
  115. jabberatdemo has joined
  116. jabberatdemo has left
  117. Guus Openfire has a plugin that allows administrators to reduce the size of to large avatars. One of the XEPs does define a preferred size. (I _think_ it's 96x96 pixels).
  118. Ge0rG I think we should significantly increase that, maybe to 512*512?
  119. ralphm has joined
  120. daniel has left
  121. Guus Ge0rG: I'm not sure about the defined size in the first place.
  122. daniel has left
  123. daniel has joined
  124. Ge0rG I haven't had a look into avatars yet. Need to fix message routing and MUC first
  125. Guus For avatars (icons), 512 seems excessive? Full profile picture, sure, but the picture in a roster or next to a chat message?
  126. Ge0rG Guus: I'm sure clients will (ab)use the avatar as a profile picture if they can get away with it
  127. marc Ge0rG, regarding PARS: what if I have multiple clients (A and B) and invite C with client A and C accepts the invitation while I'm online with B only?
  128. Ge0rG marc: with the current text, this will be a normal manual fallback. We've talked about making PARS approval server-side
  129. marc Okay, manual fallback sucks :-/
  130. Ge0rG marc: I'm still sceptical that we will get fast adoption of a server side feature, though. Just consider the OMEMO situation for non roster conversations
  131. marc Ge0rG, but rolling out an easy-xmpp feature which has some fallback scenarios just confuses users IMO
  132. Ge0rG marc: so I had to decide whether to have the manual fallback when the inviting client is offline or to have manual fallback until all server operators have rolled out a module that hasn't been written yet.
  133. marc Ge0rG, and that's why I'm inviting "my" users to "my" server ;)
  134. Ge0rG marc: maybe your users are smart enough to understand what happens if their client is suddenly asking them to choose an account for every single new conversation.
  135. Ge0rG marc: I'm writing protocol for the general case, and let me tell you that multi account is always a UX nightmare
  136. marc Ge0rG, don't get the "choose an account for every single conversation" hint
  137. marc Ge0rG, what I'm saying is that if we implement user-invitation (which is server-side) we shouldn't use a XEP which is client-side and has problems with multiple clients
  138. marc It should require/implement server-side PARS as well
  139. Ge0rG marc: I'm all for server - side PARS, and the inviter should use that if it's available. But I'm realistic, and so far there are zero servers supporting it
  140. Ge0rG marc: client side PARS, on the other hand, is already working for thousands of users
  141. marc Ge0rG, yes and I don't say that it is useless but it doesn't fit my "easy-xmpp" understanding
  142. marc User invitation should be always the same workflow for end-users
  143. Ge0rG marc: most people have an always on mobile client, and I'm sure that most PARS invitations will happen in person. You are describing a corner case that I'm well aware of, and I've chosen the trade-off I consider most suitable for the reality of federated xmpp
  144. Ge0rG marc: I agree.
  145. Ge0rG marc: now tell me how to solve this problem?
  146. marc Ge0rG, user-invitation XEP must implement server-side PARS
  147. Ge0rG "always use my server" is not a solution because it breaks federation and comes with significant transition cost
  148. marc Because we have to store an invitation token anyway
  149. marc Ge0rG, oh you mean this problem
  150. Ge0rG marc: and how are you going to roll this out to all servers?
  151. Ge0rG marc: I'm talking about PARS only now
  152. marc Solution: Public XMPP server list with high requirements regarding supported XEPs
  153. Ge0rG marc: that will not fix existing servers
  154. jonasw and existing users
  155. marc Ge0rG, correct
  156. Ge0rG marc: so it's not a solution
  157. marc If a server operator don't want to upgrade features we can not solve it...
  158. Ge0rG marc: we can easily add support for server side token generation to PARS, eg using your proposed protocol
  159. jonasw we can if there’s a client-side fallback
  160. marc The solution can not be to implement everything on client side ;)
  161. Ge0rG marc: except that I have a client side solution working in the 90% case.
  162. marc Existing users on a bad server will change to other services if "basic" features don't work
  163. jonasw marc, no
  164. zinid has joined
  165. marc Ge0rG, 90 % coverage is not enough for nice UX like for WhatsApp/...
  166. lovetox has joined
  167. Ge0rG marc: and you propose a perfect solution that will work for maybe 20% of users, once implemented and rolled out
  168. Ge0rG marc [10:53]: > Existing users on a bad server will change to other services if "basic" features don't work Now THIS is really bad for UX, because people will change to WhatsApp instead
  169. marc Ge0rG, there are a lot of feature which require server-side support
  170. marc It is _not_ a solution to build workarounds on client side IMO
  171. jonasw Ge0rG, ha, that’s what I was going to say
  172. jonasw marc, I think for robustness, a protocol which can work in both cases would be neat
  173. Ge0rG marc: please pretty please read up the PARS thread on standards@. You are repeating arguments from a year ago
  174. marc Ge0rG, We don't need to repeat the discussion ;)
  175. Ge0rG I'm out, got some appointments to make.
  176. Ge0rG marc: then provide new arguments to convince me. On standards@
  177. jonasw good luck
  178. marc No, that would take too much time ;)
  179. jonasw marc, discussion on standards@ is vtial
  180. jonasw discussion here in xsf@ is transient and will get lost
  181. marc jonasw, to me it quite obvious that the whole XMPP thing doesn't work if we have good server support
  182. marc This problem needs to be fixed
  183. jonasw *"we don’t have good server support" you mean?
  184. jonasw I think we can blame MySQL
  185. jonasw right, Zash? ^
  186. marc And if server operators don't want to upgrade, users must change to better servers which have feature which a "standard" nowadays
  187. jonasw except that changing servers is a huge PITA
  188. marc jonasw, there is no other solution for some features
  189. marc "You want to share picture in a group chat? Sorry, that's not supported by your server but you can send the picture to each individual contact via Jingle!!1! Have a nice day"
  190. jonasw Ge0rG, actually, it might not be the worst thing if PARS requires server support. Prevents new people from flocking to unmaintained servers.
  191. Syndace has left
  192. Syndace has joined
  193. Ge0rG marc: except that users won't be able to find out (or care) that it's their server's fault. They will blame xmpp and just move to FaceApp.
  194. jonasw or they might not understand that they can even switch servers
  195. Ge0rG marc: ever tried to migrate your roster to a different server?
  196. marc correct
  197. marc Ge0rG, no
  198. Ge0rG marc: you should take some time to shoulder surf xmpp novices
  199. Ge0rG Really.
  200. Ge0rG And then come back and ask about enforcing server transition
  201. marc But if I can share pictures in a group chat I would spend some time on it ;)
  202. Ge0rG &
  203. zinid has left
  204. marc Ge0rG, I know a lot of XMPP novices, really
  205. marc Ge0rG, that's why I know what sucks about XMPP and XMPP clients ;)
  206. marc And that's why I want an easy user invitation process
  207. marc Not because I want to invite some pro-users...
  208. zinid has joined
  209. daniel has left
  210. @Alacer has left
  211. daniel has joined
  212. @Alacer has joined
  213. daniel has left
  214. jubalh has joined
  215. ThurahT has left
  216. daniel has joined
  217. zinid has left
  218. daniel has left
  219. jonasw Ge0rG, given that jdev@ is flaky, care to elaborate on: 13:58:10 Ge0rG> Zash: csi:active won't help, for multiple reasons 09:51:02 jonasw> Ge0rG, I think Zash meant csn:active, at least that’s what I assumed. Would that help?
  220. ThurahT has joined
  221. zinid has joined
  222. arc has left
  223. arc has joined
  224. vanitasvitae has left
  225. arc has left
  226. vanitasvitae has joined
  227. ralphm has joined
  228. arc has joined
  229. ralphm has joined
  230. ralphm has joined
  231. pep. > jonasw> or they might not understand that they can even switch servers Strictly speaking they can't. It's a new account with new contacts etc.
  232. Guus has left
  233. lumi has joined
  234. zinid has left
  235. zinid has joined
  236. daniel has joined
  237. blabla has joined
  238. ralphm has left
  239. Zash Acrynoms with shared prefixes? Meh
  240. jonasw csi is not csn :)
  241. Guus has left
  242. Zash Should have just written "an active chat state" or somesuch
  243. jonasw also, xmpp.net reaches its resurrection
  244. Zash Dun dun DUN
  245. Zash has left
  246. Zash has left
  247. jonasw puts away the arcane scrolls of necromancy
  248. Zash has joined
  249. jonasw we might wanna import Holgers database
  250. pep. Wut, one second I could see Zash's avatar, and the next second it was gone. And now it's back. Conversations?!
  251. jonasw maybe zash left for a second?
  252. pep. Zash you can't do that to me
  253. Zash My server was restarted
  254. pep. Nonetheless, the client doesn't need the contact to always be online right?
  255. pep. Or maybe that's a feature
  256. jonasw I guess it’s a feature
  257. pep. But then I can't differentiate with people with no avatars
  258. daniel has left
  259. pep. Or people I can't see the avatar
  260. Zash 153 quirk probably
  261. Zash Can't know the avatar hash without presence
  262. pep. Cache until next presence?
  263. jonasw now I can’t stop playing with my own xmpp.net instance
  264. pep. jonasw: nice :)
  265. ralphm has joined
  266. zinid has left
  267. Guus has left
  268. blabla has left
  269. blabla has joined
  270. @Alacer has left
  271. @Alacer has joined
  272. Guus has left
  273. la|r|ma has left
  274. jonasw Holger, do you happen to know what’s needed to make xmppoke work with .onion domains?
  275. la|r|ma has joined
  276. Zash Is there any hint of SOCKS support in there?
  277. jonasw it seems to have worked with .onion before, at least
  278. Zash That and a local Tor instance ought to do it
  279. Zash Ah yes, onions.lua
  280. arc has left
  281. arc has joined
  282. jonasw ah, it assumes a SOCKS at port 9150
  283. jonasw let’s do that
  284. daniel has joined
  285. zinid has joined
  286. ThurahT has left
  287. ralphm has joined
  288. pep. jonasw, wouldn't it depend on the machine being able to resolve .onions? and just that
  289. jonasw Zash, any clue why conn:receive(5) in line 60 of onions.lua (<https://bitbucket.org/xnyhps/xmppoke/src/fbf8af64f6611b32bbc820a18643333d3459fb28/onions.lua?at=default&fileviewer=file-view-default>) would return nil?
  290. pep. Ah, socks, hmm
  291. zinid has left
  292. jonasw now it magically works
  293. jonasw timeout, probably
  294. Guus has left
  295. Guus is jabber.org unavailable?
  296. efrit has joined
  297. jonasw looking for a victim to test? feel free to target zombofant.net
  298. Guus no, conversations warned me that it can't connect.
  299. jonasw ah
  300. ralphm has joined
  301. jonasw test takes suspiciously long, too
  302. Guus https://status.conversations.im/
  303. Guus sees it fail too
  304. ThurahT has joined
  305. jonasw > Error: Connection failed.
  306. Guus I've left a message for intosi, who's the only one I know administers that domain.
  307. Guus oh
  308. Guus now it's back?
  309. jonasw sorted out tor support in xmppoke-docker, and also tested version querying
  310. jonasw Guus, it’s been flaky all day
  311. jonasw now I realize that jdev@ is at jabber.org :)
  312. ralphm has joined
  313. Guus has left
  314. goffi has joined
  315. zinid has joined
  316. Zash has left
  317. marc has left
  318. ralphm has joined
  319. tux has left
  320. jubalh has left
  321. edhelas I'm thinking of publising vcards and avatars in a specific item of pubsub nodes
  322. marc has left
  323. daniel has left
  324. jcbrand has joined
  325. zinid has left
  326. Zash vCard4 and 84?
  327. ralphm has joined
  328. daniel has left
  329. marc has left
  330. Flow Should one send a delivery receipt if we load a message with a receipt request from MAM?
  331. Flow I tend towards 'nope'
  332. dwd has left
  333. jcbrand has left
  334. Ge0rG Flow: what about having the MAM archive sending acks?
  335. sonny has left
  336. Flow Ge0rG, hmm possibly worth considering
  337. Ge0rG Except it's not what the sender would expect
  338. lovetox Flow, not instantly, first wait if another client of yours has acked the receipt
  339. Flow Ge0rG, Is it
  340. lovetox if not you should definitly send one
  341. Flow lovetox, hu? How do you know that another client acked the receipt? Why does it matter?
  342. Ge0rG Flow: in a perfect world, mam would contain the acks as well
  343. lovetox becauise the receipt is in mam
  344. jonasw > An entity MUST NOT send an ack message when a user views messages that have been archived or stored on the client or the server (e.g., via Message Archiving (XEP-0136) [8]), only when first receiving the message.
  345. jonasw (XEP-0184)
  346. Flow Ge0rG, right, in an perfect world, but you can not count on it
  347. Flow jonasw, hmm that 'MUST' feels to strong here
  348. jonasw not my idea
  349. jonasw :)
  350. lovetox jonasw, that does not touch the case in my opinion
  351. jonasw lovetox, I agree
  352. Ge0rG I'm sending acks to archive messages, because I care about ux
  353. lovetox as i said, only if another client didnt ack the message already
  354. jonasw I think querying the MAM for catch-up counts as "first receiving"
  355. jonasw this is specifically not "user views messages that have been archived
  356. jonasw this is specifically not "user views messages that have been archived"
  357. Ge0rG jonasw: you can't know if you are the first one
  358. ralphm has joined
  359. Flow jonasw, I see a slight issue here that you may end up ack'ing the wrong message because the sender does re-use IDs
  360. jonasw Ge0rG, you know when you, as the client entity, first receive a message.
  361. jonasw Flow, that’s the senders fault
  362. Ge0rG Right
  363. Flow can you blame him for standard compliant behavior?
  364. jonasw I will always blame people who don’t use strong random numbers for message IDs :)
  365. lovetox if he wants receipts he should care about IDs
  366. jcbrand has joined
  367. Ge0rG Flow: you can blame them for incorrectly applying acks
  368. Flow Ge0rG, blame whom?
  369. Ge0rG Flow: the sending entity
  370. Flow ok, you would be a hell of a laywer
  371. Flow Note to self for XMPP 2.0: The server should always assign unique IDs to outgoing stanzas and tell the ID the client. A MAM-like mechaninsm is possibly mandatory. And message 'type' names are not named after use-cases but after their routing semantics
  372. Ge0rG Flow: I'm sure that 0184 mandates sufficient randomness
  373. Flow Ge0rG, can't find it
  374. Ge0rG Flow: I want routing semantics decoupled from message type
  375. Ge0rG I'm on mobile right now
  376. daniel has left
  377. jonasw Ge0rG, 184 does not require any entropy
  378. jonasw it only reqiures that the id attribute i sset
  379. Ge0rG Somebody should fix it then
  380. ralphm has joined
  381. jonasw #fixing-a-draft
  382. @Alacer has left
  383. @Alacer has joined
  384. jubalh has left
  385. jcbrand has left
  386. zinid has joined
  387. sonny has joined
  388. sonny has joined
  389. matlag has left
  390. la|r|ma has left
  391. Zash has left
  392. zinid has left
  393. tux has joined
  394. zinid has left
  395. tux has joined
  396. jcbrand has joined
  397. daniel has left
  398. daniel has left
  399. ralphm has joined
  400. sezuan has left
  401. @Alacer has left
  402. @Alacer has joined
  403. @Alacer has left
  404. Zash > Warning: file_get_contents("http://xmppoke:1337"): failed to open stream: No such file or directory in /var/www/html/submit.php on line 42
  405. Zash Hmm
  406. jubalh has left
  407. mimi89999 has joined
  408. daniel has left
  409. jonasw Zash, ah, iteam is working on it again?
  410. jonasw that was a known problem a few hours ago, then guus had to leave and reversed the proxy to show the static redirection again.
  411. Zash Duno, doesn't look like a redirect atm
  412. jonasw yeah
  413. jonasw I guess somebody is working on it
  414. Kev has left
  415. la|r|ma has joined
  416. la|r|ma has joined
  417. Kev has left
  418. daniel has left
  419. daniel has left
  420. daniel has left
  421. tux has left
  422. ralphm has joined
  423. Holger has left
  424. Guus working on it right now
  425. Guus should perhaps maybe work now.
  426. jonasw testing :)
  427. jonasw throwing a few domains from the public server directory into it
  428. Guus Yeah, I'm running a client and a server test too
  429. Guus ok, off to feed the kids
  430. jonasw looks good so far
  431. jonasw thanks all
  432. Guus I'll also be leaving in ~1hour
  433. Guus if we need to roll back, someone will need to tell me before then.
  434. Guus so give it a couple of tries please :)
  435. jonasw I’ll post to members@
  436. lskdjf has joined
  437. Guus but, this looks pretty good so far. Thanks for reviving it, jonasw!
  438. jonasw :)
  439. Guus jonasw: it'd be good to verify that it a) automatically deploys an updated dockerhub repo, and b) doesn't wipe all old data when it does.
  440. Guus perhaps you can invoke a change?
  441. jonasw Guus, on which repository?
  442. Guus it checks all three
  443. jonasw okay
  444. Guus every 5 minutes
  445. jonasw will push an empty commit or something
  446. Guus something that's visible, perhaps?
  447. jonasw mmm
  448. Guus so that we can check if it actually got updated
  449. jonasw seems ok
  450. Guus yeah, first results are pouring in
  451. Guus nice!
  452. jonasw we should avoid updates on the xmppoke thing itself though
  453. Guus how's that?
  454. jonasw it kills the pokers
  455. SamWhited Is this an XSF project maintained by the iteam now?
  456. jonasw Guus, build queued
  457. Guus I got to run
  458. Guus cool, tx
  459. nyco has joined
  460. daniel has left
  461. SamWhited has left
  462. la|r|ma has left
  463. jcbrand has left
  464. jonasw Guus, Bad gateway?
  465. jonasw Guus, I think the autopull went wrong
  466. jonasw or it takes waaay too long
  467. jcbrand has joined
  468. blabla has left
  469. daniel has left
  470. moparisthebest has joined
  471. mathieui yah, bad gateway
  472. jonasw blame Link Mauve?
  473. mathieui always
  474. ralphm has joined
  475. pep. Same here. Link Mauve :@
  476. Guus I manually triggered what cron does - now it runs again
  477. Guus unsure what went wrong
  478. jonasw logs?
  479. jonasw it also seems to have killed all tests which were in progress
  480. ThurahT has left
  481. daniel has left
  482. Guus yeah, upon redeploy it kills all docker instances and restart each
  483. Guus no time to look at logs - need to run now.
  484. jubalh has joined
  485. ThurahT has joined
  486. zinid has left
  487. jubalh has left
  488. jubalh has joined
  489. jubalh has left
  490. nyco has left
  491. ralphm has joined
  492. blabla has joined
  493. marc has left
  494. marc has joined
  495. jcbrand has left
  496. jubalh has joined
  497. marc has left
  498. marc has joined
  499. daniel has left
  500. Ge0rG > yeah, upon redeploy it kills all docker instances and restart each I love Docker more and more every day
  501. mathieui doesn’t it kill the containers rather than docker itself?
  502. mathieui containers are supposed to be as stateless as possible, so it makes sense to kill them on redeploy
  503. Ge0rG I wouldn't be very sad if someone killed Docker.
  504. mathieui it’s a useful tool
  505. Ge0rG It's another level of abstraction added to our already overly complex tech stack
  506. pep. Ge0rG, s/docker/container solutions/ ?
  507. Ge0rG pep.: Yeah, all of them.
  508. pep. What about VMs
  509. mathieui runc (or even containerd) itself is quite a bit less complex than the docker ecosystem
  510. ralphm has joined
  511. jonasw mathieui, the issue is that the poke processes which are in progress get killed
  512. jonasw those are stateful
  513. jonasw the best we could do is probably look into the DB and re-start all pokes which are marked as "running"
  514. mathieui a bit of a pain
  515. mathieui jonasw, but do you need the poke upgrades?
  516. moparisthebest jonasw: I prefer a stop running new jobs and wait for existing ones to finish approach
  517. moparisthebest To be fair for this who really cares
  518. moparisthebest Is that going to be updated so regularly that it matters...
  519. SamWhited How are you killing docker? You can tell it to send a signal so you can do graceful shutdown
  520. SamWhited docker kill --signal=SIGINT or something to that effect
  521. mathieui SamWhited, I guess that’s left to docker-compose
  522. mathieui it updates the compoe stack and by doing so it kills the previous container and spins a new one
  523. mathieui it updates the compose stack and by doing so it kills the previous container and spins a new one
  524. lskdjf has left
  525. lskdjf has joined
  526. SamWhited docker-compose sends a sigterm already, you just have to respect that IIRC
  527. SamWhited We use docker-compose heavily at work and everything gracefully restarts fine; I don't remember having to do anything special other than handle signals
  528. daniel has left
  529. daniel has joined
  530. daniel can I get some upvotes on HN? https://news.ycombinator.com/item?id=15892761
  531. Alex has joined
  532. daniel has left
  533. blabla has left
  534. daniel has joined
  535. tux has joined
  536. ralphm has joined
  537. jubalh has joined
  538. tux has left
  539. ralphm has left
  540. ThurahT has left
  541. ralphm has joined
  542. tux has joined
  543. Ge0rG daniel: I've heard you need to go through the "new items" page for an upvote to count properly...
  544. daniel maybe they just tell you that so you don't use your army of sock puppet
  545. Ge0rG Maybe, yes.
  546. Ge0rG But I've upvoted now
  547. daniel thanks
  548. jubalh has left
  549. Ge0rG I like how it's called a Jabber / XMPP client...
  550. daniel and not a "Conversations client, compatible with and certified by the Conversations network"?
  551. lovetox_ has joined
  552. Ge0rG Approved by the Conversations Council of Elders?
  553. Zash > avoids using GCM
  554. daniel has left
  555. la|r|ma has joined
  556. ThurahT has joined
  557. Holger has left
  558. ralphm has joined
  559. la|r|ma has left
  560. la|r|ma has joined
  561. Ge0rG has left
  562. daniel has left
  563. lovetox_ has left
  564. Ge0rG has left
  565. daniel has left
  566. ralphm has joined
  567. Alex has left
  568. SamWhited has left
  569. sonny has left
  570. sonny has joined
  571. daniel has left
  572. daniel has joined
  573. Holger has left
  574. blabla has joined
  575. moparisthebest has joined
  576. jubalh has joined
  577. ralphm has joined
  578. moparisthebest has joined
  579. Alex has joined
  580. Holger has left
  581. Tobias has left
  582. daniel has left
  583. ralphm has joined
  584. andrey.g has left
  585. Zash has left
  586. blabla has left
  587. andrey.g has joined
  588. andrey.g has left
  589. Holger has left
  590. andrey.g has joined
  591. jubalh has joined
  592. daniel has left
  593. SouL has left
  594. Ge0rG has left
  595. tux has joined
  596. Ge0rG Is it legitimate to offer a "Show password" field on MUC passwords?
  597. daniel has left
  598. zinid has left
  599. jonasw SamWhited, a graceful shutdown for poke would take up to 15 minutes
  600. zinid has left
  601. SouL Ge0rG: what are you thinking on?
  602. Ge0rG SouL: I've replaced the "Repeat passwords" fields for account config/creation with a "[X] Show password" checkbox. Now I ponder if I should add that checkbox to MUC dialogs
  603. Ge0rG MUCs that have a password
  604. SouL Ge0rG: Why not? I think you did pretty well going in that direction.
  605. Ge0rG right now, it's not possible to see a MUC password at all
  606. Ge0rG the other dialogs only allow seeing a password you just enetered, not one that has been there already
  607. SouL Just to tell you a secret, I'm more than glad that Firefox allows me to check all saved passwords :)
  608. SouL I'm fucked if someone steals my laptop though
  609. SouL But it is a feature I would really like to have
  610. daniel has left
  611. pep. SouL, you have a master password hopefully right?
  612. SouL And it makes sense, if you want to invite someone to a MUC you have been always joined but you don't remember that password.
  613. SouL pep.: I also hope
  614. SouL Haha
  615. arc has left
  616. arc has joined
  617. zinid has joined
  618. marc has left
  619. Tobias has joined
  620. jjrh has left
  621. arc has left
  622. arc has joined
  623. sonny has left
  624. sonny has joined
  625. goffi has left
  626. Alex has left
  627. Zash Can you start a new container without killing the old one? And like, redirect stuff to the new one until the old one is doen with its things
  628. pep. I don't know if docker itself can do that.
  629. pep. I mean make the port bound to a new container
  630. arc has left
  631. arc has joined
  632. Syndace has joined
  633. Syndace has joined
  634. zinid has left
  635. zinid has joined
  636. SamWhited jonasw: is that a problem?
  637. daniel has left
  638. pep. SamWhited, can you have docker wait that long for a process to come down?
  639. SamWhited pep.: I think it does by default if you use docker-compose or docker kill
  640. pep. Ok
  641. tux has left
  642. ThurahT Ge0rG: I get kicked out from xmpp@y.i since the last day or so. Says my JID is malformed and then gives me code 110. Never seen that before. Did you change something?
  643. zinid has left
  644. test has joined
  645. test has left
  646. Zash > ThurahT has left the room (Kicked: jid malformed)
  647. Zash ThurahT: I believe it's because someone has the nick "uc 🕴🏻" there, and your server doesn't like that
  648. ralphm has joined
  649. Zash So, unicode madness. The proper reaction is to lie down and cry.
  650. ThurahT haha, wat. My server is jabber.org..
  651. edhelas has left
  652. Zash Unicode Madness!
  653. ThurahT indeed..
  654. edhelas has joined
  655. ThurahT guess that is the final nail in the coffin for using j.o with the spam and all. I'll remake my bookmarks with another server.
  656. daniel has left
  657. jere has joined
  658. Ge0rG ThurahT: come to yax.im - we have World Class spam protection
  659. pep. jonasw, I get "Error: test failed." :(
  660. ThurahT will do
  661. pep. (xmpp.net)
  662. pep. Certificate score and protocol score seem to be completed. Then it continues loading, waited an hour, refreshed and "Error: Test failed."
  663. jmpman has joined
  664. marc has left
  665. edhelas has left
  666. edhelas has joined
  667. sezuan has left
  668. SamWhited has left
  669. ThurahT has left
  670. ThurahT has joined
  671. lskdjf has joined
  672. lovetox has left
  673. uc has joined
  674. matlag has left
  675. Zash has left
  676. efrit has left