XSF Discussion - 2017-12-10

  1. zinid

    Yeah, and they should be square (or round, council would decide it)

  2. 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

  3. edhelas

    Ge0rG for this I'd advice to add a "background" picture, like on many other social networks

  4. Ge0rG

    And we also need a sarcasm tag!

  5. edhelas


  6. Ge0rG

    Or at least an according Emoji

  7. 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).

  8. Ge0rG

    I think we should significantly increase that, maybe to 512*512?

  9. Guus

    Ge0rG: I'm not sure about the defined size in the first place.

  10. Ge0rG

    I haven't had a look into avatars yet. Need to fix message routing and MUC first

  11. Guus

    For avatars (icons), 512 seems excessive? Full profile picture, sure, but the picture in a roster or next to a chat message?

  12. Ge0rG

    Guus: I'm sure clients will (ab)use the avatar as a profile picture if they can get away with it

  13. 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?

  14. Ge0rG

    marc: with the current text, this will be a normal manual fallback. We've talked about making PARS approval server-side

  15. marc

    Okay, manual fallback sucks :-/

  16. 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

  17. marc

    Ge0rG, but rolling out an easy-xmpp feature which has some fallback scenarios just confuses users IMO

  18. 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.

  19. marc

    Ge0rG, and that's why I'm inviting "my" users to "my" server ;)

  20. 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.

  21. Ge0rG

    marc: I'm writing protocol for the general case, and let me tell you that multi account is always a UX nightmare

  22. marc

    Ge0rG, don't get the "choose an account for every single conversation" hint

  23. 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

  24. marc

    It should require/implement server-side PARS as well

  25. 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

  26. Ge0rG

    marc: client side PARS, on the other hand, is already working for thousands of users

  27. marc

    Ge0rG, yes and I don't say that it is useless but it doesn't fit my "easy-xmpp" understanding

  28. marc

    User invitation should be always the same workflow for end-users

  29. 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

  30. Ge0rG

    marc: I agree.

  31. Ge0rG

    marc: now tell me how to solve this problem?

  32. marc

    Ge0rG, user-invitation XEP must implement server-side PARS

  33. Ge0rG

    "always use my server" is not a solution because it breaks federation and comes with significant transition cost

  34. marc

    Because we have to store an invitation token anyway

  35. marc

    Ge0rG, oh you mean this problem

  36. Ge0rG

    marc: and how are you going to roll this out to all servers?

  37. Ge0rG

    marc: I'm talking about PARS only now

  38. marc

    Solution: Public XMPP server list with high requirements regarding supported XEPs

  39. Ge0rG

    marc: that will not fix existing servers

  40. jonasw

    and existing users

  41. marc

    Ge0rG, correct

  42. Ge0rG

    marc: so it's not a solution

  43. marc

    If a server operator don't want to upgrade features we can not solve it...

  44. Ge0rG

    marc: we can easily add support for server side token generation to PARS, eg using your proposed protocol

  45. jonasw

    we can if there’s a client-side fallback

  46. marc

    The solution can not be to implement everything on client side ;)

  47. Ge0rG

    marc: except that I have a client side solution working in the 90% case.

  48. marc

    Existing users on a bad server will change to other services if "basic" features don't work

  49. jonasw

    marc, no

  50. marc

    Ge0rG, 90 % coverage is not enough for nice UX like for WhatsApp/...

  51. Ge0rG

    marc: and you propose a perfect solution that will work for maybe 20% of users, once implemented and rolled out

  52. 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

  53. marc

    Ge0rG, there are a lot of feature which require server-side support

  54. marc

    It is _not_ a solution to build workarounds on client side IMO

  55. jonasw

    Ge0rG, ha, that’s what I was going to say

  56. jonasw

    marc, I think for robustness, a protocol which can work in both cases would be neat

  57. Ge0rG

    marc: please pretty please read up the PARS thread on standards@. You are repeating arguments from a year ago

  58. marc

    Ge0rG, We don't need to repeat the discussion ;)

  59. Ge0rG

    I'm out, got some appointments to make.

  60. Ge0rG

    marc: then provide new arguments to convince me. On standards@

  61. jonasw

    good luck

  62. marc

    No, that would take too much time ;)

  63. jonasw

    marc, discussion on standards@ is vtial

  64. jonasw

    discussion here in xsf@ is transient and will get lost

  65. marc

    jonasw, to me it quite obvious that the whole XMPP thing doesn't work if we have good server support

  66. marc

    This problem needs to be fixed

  67. jonasw

    *"we don’t have good server support" you mean?

  68. jonasw

    I think we can blame MySQL

  69. jonasw

    right, Zash? ^

  70. marc

    And if server operators don't want to upgrade, users must change to better servers which have feature which a "standard" nowadays

  71. jonasw

    except that changing servers is a huge PITA

  72. marc

    jonasw, there is no other solution for some features

  73. 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"

  74. jonasw

    Ge0rG, actually, it might not be the worst thing if PARS requires server support. Prevents new people from flocking to unmaintained servers.

  75. 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.

  76. jonasw

    or they might not understand that they can even switch servers

  77. Ge0rG

    marc: ever tried to migrate your roster to a different server?

  78. marc


  79. marc

    Ge0rG, no

  80. Ge0rG

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

  81. Ge0rG


  82. Ge0rG

    And then come back and ask about enforcing server transition

  83. marc

    But if I can share pictures in a group chat I would spend some time on it ;)

  84. Ge0rG &

  85. marc

    Ge0rG, I know a lot of XMPP novices, really

  86. marc

    Ge0rG, that's why I know what sucks about XMPP and XMPP clients ;)

  87. marc

    And that's why I want an easy user invitation process

  88. marc

    Not because I want to invite some pro-users...

  89. 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?

  90. 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.

  91. Zash

    Acrynoms with shared prefixes? Meh

  92. jonasw

    csi is not csn :)

  93. Zash

    Should have just written "an active chat state" or somesuch

  94. jonasw

    also, xmpp.net reaches its resurrection

  95. Zash

    Dun dun DUN

  96. jonasw puts away the arcane scrolls of necromancy

  97. jonasw

    we might wanna import Holgers database

  98. pep.

    Wut, one second I could see Zash's avatar, and the next second it was gone. And now it's back. Conversations?!

  99. jonasw

    maybe zash left for a second?

  100. pep.

    Zash you can't do that to me

  101. Zash

    My server was restarted

  102. pep.

    Nonetheless, the client doesn't need the contact to always be online right?

  103. pep.

    Or maybe that's a feature

  104. jonasw

    I guess it’s a feature

  105. pep.

    But then I can't differentiate with people with no avatars

  106. pep.

    Or people I can't see the avatar

  107. Zash

    153 quirk probably

  108. Zash

    Can't know the avatar hash without presence

  109. pep.

    Cache until next presence?

  110. jonasw

    now I can’t stop playing with my own xmpp.net instance

  111. pep.

    jonasw: nice :)

  112. jonasw

    Holger, do you happen to know what’s needed to make xmppoke work with .onion domains?

  113. Zash

    Is there any hint of SOCKS support in there?

  114. jonasw

    it seems to have worked with .onion before, at least

  115. Zash

    That and a local Tor instance ought to do it

  116. Zash

    Ah yes, onions.lua

  117. jonasw

    ah, it assumes a SOCKS at port 9150

  118. jonasw

    let’s do that

  119. pep.

    jonasw, wouldn't it depend on the machine being able to resolve .onions? and just that

  120. 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?

  121. pep.

    Ah, socks, hmm

  122. jonasw

    now it magically works

  123. jonasw

    timeout, probably

  124. Guus

    is jabber.org unavailable?

  125. jonasw

    looking for a victim to test? feel free to target zombofant.net

  126. Guus

    no, conversations warned me that it can't connect.

  127. jonasw


  128. jonasw

    test takes suspiciously long, too

  129. Guus


  130. Guus

    sees it fail too

  131. jonasw

    > Error: Connection failed.

  132. Guus

    I've left a message for intosi, who's the only one I know administers that domain.

  133. Guus


  134. Guus

    now it's back?

  135. jonasw

    sorted out tor support in xmppoke-docker, and also tested version querying

  136. jonasw

    Guus, it’s been flaky all day

  137. jonasw

    now I realize that jdev@ is at jabber.org :)

  138. edhelas

    I'm thinking of publising vcards and avatars in a specific item of pubsub nodes

  139. Zash

    vCard4 and 84?

  140. Flow

    Should one send a delivery receipt if we load a message with a receipt request from MAM?

  141. Flow

    I tend towards 'nope'

  142. Ge0rG

    Flow: what about having the MAM archive sending acks?

  143. Flow

    Ge0rG, hmm possibly worth considering

  144. Ge0rG

    Except it's not what the sender would expect

  145. lovetox

    Flow, not instantly, first wait if another client of yours has acked the receipt

  146. Flow

    Ge0rG, Is it

  147. lovetox

    if not you should definitly send one

  148. Flow

    lovetox, hu? How do you know that another client acked the receipt? Why does it matter?

  149. Ge0rG

    Flow: in a perfect world, mam would contain the acks as well

  150. lovetox

    becauise the receipt is in mam

  151. 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.

  152. jonasw


  153. Flow

    Ge0rG, right, in an perfect world, but you can not count on it

  154. Flow

    jonasw, hmm that 'MUST' feels to strong here

  155. jonasw

    not my idea

  156. jonasw


  157. lovetox

    jonasw, that does not touch the case in my opinion

  158. jonasw

    lovetox, I agree

  159. Ge0rG

    I'm sending acks to archive messages, because I care about ux

  160. lovetox

    as i said, only if another client didnt ack the message already

  161. jonasw

    I think querying the MAM for catch-up counts as "first receiving"

  162. jonasw

    this is specifically not "user views messages that have been archived

  163. jonasw

    this is specifically not "user views messages that have been archived"

  164. Ge0rG

    jonasw: you can't know if you are the first one

  165. 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

  166. jonasw

    Ge0rG, you know when you, as the client entity, first receive a message.

  167. jonasw

    Flow, that’s the senders fault

  168. Ge0rG


  169. Flow

    can you blame him for standard compliant behavior?

  170. jonasw

    I will always blame people who don’t use strong random numbers for message IDs :)

  171. lovetox

    if he wants receipts he should care about IDs

  172. Ge0rG

    Flow: you can blame them for incorrectly applying acks

  173. Flow

    Ge0rG, blame whom?

  174. Ge0rG

    Flow: the sending entity

  175. Flow

    ok, you would be a hell of a laywer

  176. 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

  177. Ge0rG

    Flow: I'm sure that 0184 mandates sufficient randomness

  178. Flow

    Ge0rG, can't find it

  179. Ge0rG

    Flow: I want routing semantics decoupled from message type

  180. Ge0rG

    I'm on mobile right now

  181. jonasw

    Ge0rG, 184 does not require any entropy

  182. jonasw

    it only reqiures that the id attribute i sset

  183. Ge0rG

    Somebody should fix it then

  184. jonasw


  185. 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

  186. Zash


  187. jonasw

    Zash, ah, iteam is working on it again?

  188. 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.

  189. Zash

    Duno, doesn't look like a redirect atm

  190. jonasw


  191. jonasw

    I guess somebody is working on it

  192. Guus

    working on it right now

  193. Guus

    should perhaps maybe work now.

  194. jonasw

    testing :)

  195. jonasw

    throwing a few domains from the public server directory into it

  196. Guus

    Yeah, I'm running a client and a server test too

  197. Guus

    ok, off to feed the kids

  198. jonasw

    looks good so far

  199. jonasw

    thanks all

  200. Guus

    I'll also be leaving in ~1hour

  201. Guus

    if we need to roll back, someone will need to tell me before then.

  202. Guus

    so give it a couple of tries please :)

  203. jonasw

    I’ll post to members@

  204. Guus

    but, this looks pretty good so far. Thanks for reviving it, jonasw!

  205. jonasw


  206. 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.

  207. Guus

    perhaps you can invoke a change?

  208. jonasw

    Guus, on which repository?

  209. Guus

    it checks all three

  210. jonasw


  211. Guus

    every 5 minutes

  212. jonasw

    will push an empty commit or something

  213. Guus

    something that's visible, perhaps?

  214. jonasw


  215. Guus

    so that we can check if it actually got updated

  216. jonasw

    seems ok

  217. Guus

    yeah, first results are pouring in

  218. Guus


  219. jonasw

    we should avoid updates on the xmppoke thing itself though

  220. Guus

    how's that?

  221. jonasw

    it kills the pokers

  222. SamWhited

    Is this an XSF project maintained by the iteam now?

  223. jonasw

    Guus, build queued

  224. Guus

    I got to run

  225. Guus

    cool, tx

  226. jonasw

    Guus, Bad gateway?

  227. jonasw

    Guus, I think the autopull went wrong

  228. jonasw

    or it takes waaay too long

  229. mathieui

    yah, bad gateway

  230. jonasw

    blame Link Mauve?

  231. mathieui


  232. pep.

    Same here. Link Mauve :@

  233. Guus

    I manually triggered what cron does - now it runs again

  234. Guus

    unsure what went wrong

  235. jonasw


  236. jonasw

    it also seems to have killed all tests which were in progress

  237. Guus

    yeah, upon redeploy it kills all docker instances and restart each

  238. Guus

    no time to look at logs - need to run now.

  239. Ge0rG

    > yeah, upon redeploy it kills all docker instances and restart each I love Docker more and more every day

  240. mathieui

    doesn’t it kill the containers rather than docker itself?

  241. mathieui

    containers are supposed to be as stateless as possible, so it makes sense to kill them on redeploy

  242. Ge0rG

    I wouldn't be very sad if someone killed Docker.

  243. mathieui

    it’s a useful tool

  244. Ge0rG

    It's another level of abstraction added to our already overly complex tech stack

  245. pep.

    Ge0rG, s/docker/container solutions/ ?

  246. Ge0rG

    pep.: Yeah, all of them.

  247. pep.

    What about VMs

  248. mathieui

    runc (or even containerd) itself is quite a bit less complex than the docker ecosystem

  249. jonasw

    mathieui, the issue is that the poke processes which are in progress get killed

  250. jonasw

    those are stateful

  251. jonasw

    the best we could do is probably look into the DB and re-start all pokes which are marked as "running"

  252. mathieui

    a bit of a pain

  253. mathieui

    jonasw, but do you need the poke upgrades?

  254. moparisthebest

    jonasw: I prefer a stop running new jobs and wait for existing ones to finish approach

  255. moparisthebest

    To be fair for this who really cares

  256. moparisthebest

    Is that going to be updated so regularly that it matters...

  257. SamWhited

    How are you killing docker? You can tell it to send a signal so you can do graceful shutdown

  258. SamWhited

    docker kill --signal=SIGINT or something to that effect

  259. mathieui

    SamWhited, I guess that’s left to docker-compose

  260. mathieui

    it updates the compoe stack and by doing so it kills the previous container and spins a new one

  261. mathieui

    it updates the compose stack and by doing so it kills the previous container and spins a new one

  262. SamWhited

    docker-compose sends a sigterm already, you just have to respect that IIRC

  263. 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

  264. daniel

    can I get some upvotes on HN? https://news.ycombinator.com/item?id=15892761

  265. Ge0rG

    daniel: I've heard you need to go through the "new items" page for an upvote to count properly...

  266. daniel

    maybe they just tell you that so you don't use your army of sock puppet

  267. Ge0rG

    Maybe, yes.

  268. Ge0rG

    But I've upvoted now

  269. daniel


  270. Ge0rG

    I like how it's called a Jabber / XMPP client...

  271. daniel

    and not a "Conversations client, compatible with and certified by the Conversations network"?

  272. Ge0rG

    Approved by the Conversations Council of Elders?

  273. Zash

    > avoids using GCM

  274. Ge0rG

    Is it legitimate to offer a "Show password" field on MUC passwords?

  275. jonasw

    SamWhited, a graceful shutdown for poke would take up to 15 minutes

  276. SouL

    Ge0rG: what are you thinking on?

  277. 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

  278. Ge0rG

    MUCs that have a password

  279. SouL

    Ge0rG: Why not? I think you did pretty well going in that direction.

  280. Ge0rG

    right now, it's not possible to see a MUC password at all

  281. Ge0rG

    the other dialogs only allow seeing a password you just enetered, not one that has been there already

  282. SouL

    Just to tell you a secret, I'm more than glad that Firefox allows me to check all saved passwords :)

  283. SouL

    I'm fucked if someone steals my laptop though

  284. SouL

    But it is a feature I would really like to have

  285. pep.

    SouL, you have a master password hopefully right?

  286. 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.

  287. SouL

    pep.: I also hope

  288. SouL


  289. 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

  290. pep.

    I don't know if docker itself can do that.

  291. pep.

    I mean make the port bound to a new container

  292. SamWhited

    jonasw: is that a problem?

  293. pep.

    SamWhited, can you have docker wait that long for a process to come down?

  294. SamWhited

    pep.: I think it does by default if you use docker-compose or docker kill

  295. pep.


  296. 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?

  297. Zash

    > ThurahT has left the room (Kicked: jid malformed)

  298. Zash

    ThurahT: I believe it's because someone has the nick "uc 🕴🏻" there, and your server doesn't like that

  299. Zash

    So, unicode madness. The proper reaction is to lie down and cry.

  300. ThurahT

    haha, wat. My server is jabber.org..

  301. Zash

    Unicode Madness!

  302. ThurahT


  303. 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.

  304. Ge0rG

    ThurahT: come to yax.im - we have World Class spam protection

  305. pep.

    jonasw, I get "Error: test failed." :(

  306. ThurahT

    will do

  307. pep.


  308. pep.

    Certificate score and protocol score seem to be completed. Then it continues loading, waited an hour, refreshed and "Error: Test failed."