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


  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


  197. marc

    Ge0rG, no

  198. Ge0rG

    marc: you should take some time to shoulder surf xmpp novices

  199. Ge0rG


  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


  300. ralphm has joined

  301. jonasw

    test takes suspiciously long, too

  302. Guus


  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


  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


  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


  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


  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


  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


  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


  444. Guus

    every 5 minutes

  445. jonasw

    will push an empty commit or something

  446. Guus

    something that's visible, perhaps?

  447. jonasw


  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


  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


  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


  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


  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


  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.


  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


  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.


  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