XSF Discussion - 2017-12-08

  1. arc has left
  2. arc has joined
  3. sonny has joined
  4. arc has left
  5. lskdjf has joined
  6. jjrh has left
  7. goffi has left
  8. arc has joined
  9. jere has joined
  10. la|r|ma has left
  11. jere has left
  12. jere has joined
  13. zinid has joined
  14. zinid has left
  15. arc has left
  16. tux has left
  17. tux has joined
  18. Tobias has joined
  19. arc has joined
  20. Zash has left
  21. jere has left
  22. jere has joined
  23. lskdjf has joined
  24. Tobias has joined
  25. jjrh has left
  26. zinid has joined
  27. zinid has left
  28. stefandxm has left
  29. stefandxm has joined
  30. stefandxm has left
  31. stefandxm has joined
  32. @Alacer has left
  33. @Alacer has joined
  34. stefandxm has left
  35. stefandxm has joined
  36. jmpman has joined
  37. jmpman has joined
  38. jmpman has left
  39. jmpman has joined
  40. zinid has joined
  41. stefandxm has left
  42. efrit has joined
  43. zinid has left
  44. stefandxm has left
  45. stefandxm has joined
  46. la|r|ma has left
  47. arc has left
  48. arc has joined
  49. ralphm has joined
  50. la|r|ma has left
  51. la|r|ma has joined
  52. la|r|ma has joined
  53. efrit has left
  54. la|r|ma has left
  55. la|r|ma has left
  56. la|r|ma has joined
  57. la|r|ma has left
  58. la|r|ma has left
  59. la|r|ma has joined
  60. la|r|ma has left
  61. @Alacer has left
  62. @Alacer has joined
  63. zinid has joined
  64. 0000 has left
  65. zinid has left
  66. la|r|ma has left
  67. zinid has joined
  68. zinid has left
  69. 0000 has joined
  70. uc has joined
  71. la|r|ma has joined
  72. uc has joined
  73. zinid has joined
  74. @Alacer has left
  75. @Alacer has joined
  76. SamWhited has left
  77. marc has joined
  78. ralphm has left
  79. ralphm has joined
  80. moparisthebest has joined
  81. ralphm has left
  82. sonny has joined
  83. daniel has left
  84. ralphm has joined
  85. Guus has left
  86. marc Anyone an idea how we can make "xmpp:?message;body=BODY" XMPP URIs legal? It seems that some RFC doesn't allow empty JID in XMPP URI...
  87. ralphm has left
  88. ralphm has joined
  89. daniel has left
  90. ralphm has left
  91. ralphm has joined
  92. jonasw marc, what’d you use them for?
  93. marc jonasw, share a message
  94. marc Do you know these social share buttons on YouTube, Wordpress etc?
  95. marc That would be a use case
  96. jonasw ah, I see
  97. marc You click on it, the XMPP client pops up and let you decide the contact you want to share the message with
  98. jonasw if the RFC doesn’t allow for it, we need to extend the RFC I guess
  99. ralphm has left
  100. jonasw although I’m not sure if the URI RFC allows it :/
  101. ralphm has joined
  102. marc It does
  103. marc At least I'm pretty sure
  104. jonasw implement it, the RFC can follow :)
  105. marc I'll double check if that possible in general URIs
  106. marc jonasw, I have an implementation for Conversations
  107. marc It needs some restructuring but PoC works fine
  108. jonasw python urllib at least accepts xmpp:?
  109. ralphm has joined
  110. jonasw which RFC specifies xmpp: again?
  111. marc jonasw, https://tools.ietf.org/html/rfc3986#section-3 "The scheme and path components are required, though the path may be empty (no characters)."
  112. marc https://tools.ietf.org/html/rfc5122#section-2.2
  113. marc So URIs allow it
  114. marc We need to change XMPP URI RFC :)
  115. marc Of course, we could use an ugly hack like "xmpp:share?message;body=BODY"
  116. marc But I don't like it
  117. jonasw I think it allows it
  118. jonasw but I may be mistaken
  119. zinid has left
  120. jonasw the rule we’re expanding in this case is: xmppiri = "xmpp" ":" ihierxmpp, ihierxmpp = ipathxmpp, ipathxmpp = ihost
  121. jonasw ihost is defined in: https://tools.ietf.org/html/rfc3987#section-2.2
  122. jonasw as: ihost = *( iunreserved / pct-encoded / sub-delims )
  123. jonasw the asterisk is defined in: https://tools.ietf.org/html/rfc2234
  124. jonasw as: The operator "*" preceding an element indicates repetition. The full form is: <a>*<b>element where <a> and <b> are optional decimal values, indicating at least <a> and at most <b> occurrences of element. Default values are 0 and infinity so that *<element> allows any number, including zero; 1*<element> requires at least one; 3*3<element> allows exactly 3 and 1*2<element> allows one or two.
  125. ralphm has joined
  126. jonasw this means that *( foo ) is zero or more of foo
  127. jonasw in this case it means that ihost can be empty
  128. jonasw thus it is legal to have an empty JID *as per the grammar*
  129. jonasw I haven’t checked the text yet :)
  130. jonasw the same holds for the URI interpretation, but without the leading "i"
  131. marc Mhm okay
  132. jonasw it might be an oversight that the grammar allows it, but it’s useful in this case :)
  133. marc Maybe I need to read this document thoroughly, there is also something like "xmpp://guest@example.com/support@example.com?message"
  134. jonasw yeah
  135. ralphm has left
  136. ralphm has joined
  137. ralphm has left
  138. ralphm has joined
  139. ralphm has left
  140. ralphm has joined
  141. stefandxm has left
  142. Ge0rG marc: I've been pondering about the invitation workflow some more, and I think it should go like this: 1. you request an invitation token from your server via ad-hoc 2. you send a url of xmpp:you@yourserver?roster;invitation=token out-of-band 3a. the invitee performs IBR with the invitation token 3b. the invitee already has an account and performs PARS with the invitation token
  143. daniel has left
  144. daniel has left
  145. marc Ge0rG, what is you@yourserver? The JID of the inviter?
  146. Ge0rG marc: correct
  147. lskdjf has joined
  148. @Alacer has left
  149. @Alacer has joined
  150. marc Ge0rG, the client still must provide the possiblity to create an account even if you already have one
  151. Ge0rG marc: in theory, yes. But I'm pretty sure the power users will figure it out anyway, and the regular users will only get confused
  152. marc Ge0rG, if you already have one you'll probably know what to do if the client provides you a dialog so it shouldn't be a problem, right?
  153. jonasw marc, FWIW, if you really want that feature, I’d hide it at the bottom of the screen
  154. jonasw like websites hide the "continue without" button when asking for your phone number :)
  155. marc jonasw, maybe I want to give a user the possibility to join _my_ server
  156. marc I think that feature is not unreasonable
  157. jonasw marc, I doubt that many users care a lot of about that.
  158. Ge0rG the default flow should be as easy as possible.
  159. marc yes, the default user has no account :P
  160. marc -> the default user will not be confronted with a dialog
  161. marc Ge0rG, I'm not sure about the ?roster action
  162. Ge0rG marc: I don't care about the action too much
  163. Ge0rG marc: but there will be a dialog, either account creation or add-contact
  164. jonasw s/roster/invite/?
  165. marc Ge0rG, Yes, if you already have an account there should be an "add-contact" dialog with an option to create an account
  166. stefandxm has joined
  167. marc (instead of just use an existing account)
  168. daniel > you send a url of xmpp:you@yourserver?roster;invitation=token out-of-band shouldn't that be xmpp://you@yourserver or something
  169. Ge0rG marc: if the client supports multiple accounts. which is arguably a power-user feature that makes UX complicated
  170. jonasw daniel, are you asking because of the semantic difference between xmpp:// and xmpp:?
  171. daniel jonasw, yes
  172. Ge0rG daniel: no, :// would be an account reference, : is a contact reference
  173. marc daniel, no
  174. marc I had the same idea
  175. marc but the authority is to indicate the account to use
  176. daniel oh i thought you was I
  177. daniel like you the proposed username for me
  178. Ge0rG daniel: you could do something like xmpp://proposed_invitee_jid@server/inviter@server
  179. marc Ge0rG, why does it lead to a complicated UI? Just a small button "Create account" in the bottom left/right corner
  180. daniel Ge0rG, yeah i thought that's what this thing was trying to do. never mind
  181. Ge0rG marc: the complicated UI arises when you have multiple accounts
  182. Ge0rG marc: now you need a notion of a default account, or ask the user on every interaction which account to use
  183. daniel marc, have you considered what communication method I would use to send you the url?
  184. daniel becasue gmail for example doesn't make xmpp uris clickable
  185. daniel neither does the sms app
  186. marc Ge0rG, you already have to ask the user what account to use
  187. marc daniel, we use an invitation url
  188. Ge0rG daniel: I would love to anchor that onto the easy-xmpp-invite mechanism
  189. Steve Kille has left
  190. Steve Kille has left
  191. daniel marc, like an https url?
  192. marc daniel, yes
  193. Ge0rG marc: that's exactly my point, it's a UX nightmare.
  194. daniel why are you discussing xmpp uri schemes then?
  195. marc daniel, that's an other topic ;)
  196. Ge0rG it's all interrelated.
  197. daniel only that xmpp uris are mostly worthless
  198. daniel when it comes to easy onboarding
  199. marc Yes
  200. edhelas was difficult to figure out those xmpp uris as well for me
  201. Ge0rG daniel: right, so I've made easy-xmpp-invitation.
  202. Ge0rG daniel: which allows to bridge xmpp: URIs over https.
  203. daniel edhelas, it's not that they are difficult. but you can't click them
  204. jonasw daniel, you can make any URL clickable on a website -> win
  205. Ge0rG jonasw: but it won't magically work.
  206. marc Ge0rG, I don't get what's the problem with multiple accounts. We already have clients that support multiple accounts.
  207. marc And there is almost no additional work for the UI
  208. Ge0rG marc: I'm not saying that implementing multiple accounts is a problem, I'm saying that having multiple accounts on the same client is a UX nightmare
  209. Ge0rG marc: imagine a user accidentally clicking the "create account" button and ending up with two accounts - one for all their friends and one for you
  210. Ge0rG and users have very large fingers.
  211. marc Ge0rG, yes, that needs to be solved by the UI nicely :D
  212. stefandxm has left
  213. marc That's why the preferred option is to add the contact via PARS if an account is available
  214. Steve Kille has joined
  215. marc But creating a XEP just for user invitation to a server if the user doesn't already have an account limits the possibilities...
  216. tim@boese-ban.de has joined
  217. Ge0rG marc: right, which is why the whole thing is also technically a bit more complex
  218. marc Ge0rG, my problem at the moment is that I'm not sure how to integrate both XEPs properly
  219. marc In a way that both do not depend on each other and can be implemented independetly
  220. Ge0rG marc: you need to have four specifications: - token generation (PARS uses a client-side approach, you go with ad-hoc. specify that) - token transmission (basically a new xmpp: URI parameter) - use of the token in account creation (IBR payload / data forms) - use of the token in PARS (just reference PARS and say that the token must be usable as `preauth=` for PARS as well)
  221. marc Ge0rG, yes, but the tokens need to be the same if both is used
  222. Ge0rG the server needs to store the token in some kind of table anyway, where it will also contain the inviter's JID
  223. Ge0rG marc: I think that re-using this token for server-side PARS shouldn't hurt
  224. Ge0rG marc: so your specification means a server must implement PARS
  225. Ge0rG marc: or, alternatively, you need to add two tokens to the URL
  226. Ge0rG Actually, I would be okay with extending PARS accordingly.
  227. Ge0rG So that it covers both use cases.
  228. marc two token keys with the same token, like invite=TOKEN;preauth=TOKEN ?
  229. marc Such that the clients know that both is supported?
  230. Ge0rG marc: yes, like that.
  231. ralphm has left
  232. Ge0rG marc: or maybe invite_and_preauth=TOKEN ;)
  233. stefandxm has joined
  234. Ge0rG I like short URIs
  235. marc Ge0rG, No!
  236. marc :D
  237. Ge0rG marc: I would go for `invite=TOKEN` and "A server offering this feature MUST also accept the token as a <preauth token> for an inbound roster subscription to the inviter."
  238. daniel has left
  239. valo has left
  240. valo has joined
  241. marc So implementing user-invitation requires implementation of PARS, right?
  242. Ge0rG marc: not technically, but if you want to provide a good UX then yes
  243. marc Ge0rG, Yes, for nice UX I would prefer it this way
  244. marc Ge0rG, your statement sounds like a requirement
  245. uc has joined
  246. Ge0rG marc: you could go with two separate token parameters, then you have explicit separation between PARS and IBR. But then who is responsible for adding PARS to the URI? The server on ad-hoc? The inviter's client?
  247. marc Ge0rG, the server if it supports PARS?
  248. Ge0rG marc: in the ad-hoc response?
  249. jonasw Ge0rG, for breveity, the URI could also be ?invite=TOKEN;preauth=, with the empty preauth signifying that the token shall be re-used
  250. Ge0rG jonasw: then you are breaking existing PARS clients :P
  251. jonasw then turn it the other way round :)
  252. jonasw preauth=TOKEN;invite=
  253. Ge0rG jonasw: the more I think about it, the more I want to merge both functions into one XEP
  254. jonasw I agree
  255. marc Ge0rG, yes, in the ad-hoc response
  256. marc Ge0rG, are there any PARS clients out there? :D
  257. Ge0rG has left
  258. Ge0rG marc: there is yaxim
  259. daniel has left
  260. marc Ge0rG, ah okay
  261. jonasw it’s on the to-do for jabbercat
  262. marc Ge0rG, well, I like your idea of combining both "features" but they should not be depend on each other IMO
  263. Ge0rG marc: that depends on your goal
  264. Ge0rG marc: if your goal is to make as little as possible, then you are right. If your goal is to provide a just-works™ onboarding experience, you need both.
  265. marc The combination of both would make on-boarding really nice
  266. daniel has left
  267. marc Ge0rG, of course, providing both should be recommended for public servers
  268. Ge0rG marc: I'm all in for small self-contained XEPs. But if you separate these two, you have a bunch of additional client-side logic to add to compensate for the lack
  269. Ge0rG on the inviter's client: "oh, ad-hoc didn't give me a PARS token. I need to add one to the URI myself. Wait, the https:// URI is not a scheme I know, I can't do that!?"
  270. Ge0rG on the invitee's client, I need to cover all four combinations of features
  271. Ge0rG none / invite / pars / invite+pars
  272. marc Ge0rG, no, the server just adds the PARS token and returns it
  273. Ge0rG marc: but the server doesn't support PARS, only the client.
  274. Ge0rG I've designed PARS as a client-only protocol because server developers are lazy.
  275. marc Ge0rG, ah okay, didn't thought about that use case
  276. Ge0rG And server operators are even lazier.
  277. jonasw yeah, server developers aren’t that lazy
  278. marc Ge0rG, that's a good point... hm...
  279. Ge0rG marc: you implement your nice new server-side XEP. Then it takes weeks to months for it to get merged upstream. Then you need to wait for the next server software release. Then that release needs to be distro-packaged. Then you realize that most server operators never upgrade.
  280. marc Ge0rG, well, that's true for all server-side XEPs
  281. Ge0rG marc: true
  282. marc Ge0rG, should be implement everything on the client side?
  283. Ge0rG marc: now you know why PARS can be implemented 100% client-side
  284. marc s/be/we
  285. jonasw Ge0rG, I think it might be not /that/ bad
  286. Ge0rG marc: Daniel's compliance tester is a good thing to make server operators aware.
  287. jonasw we’ve seen quite quick adoption of things since conversations compliance checker
  288. jonasw right
  289. Ge0rG jonasw: especially private PEP.
  290. jonasw so if somebody builds a prosody module which does that, even if it only supports things in-memory, that’ll already be a major plus
  291. jonasw Ge0rG, yes, we have. A lot of work is going into that :)
  292. Ge0rG you can't force server developers to do work by showing a red square on some website
  293. jonasw but operators
  294. marc Ge0rG, to solve this issue we need an "official" public server list on the (xmpp.org?) website
  295. jonasw to solve that problem we need massive funding for developers.
  296. marc which shows only servers with a special set of XEPs
  297. zinid has left
  298. Ge0rG jonasw: how many servers are there in the compliance checker? ~120? yax.im has >1000 of s2s connections.
  299. Ge0rG marc: we can't even come up with that official set of XEPs.
  300. daniel Ge0rG: divide that number by 4
  301. daniel Because in and out and conferences
  302. Ge0rG marc: but yes, we need an official compliance checker, and maybe some kind of Badge Of Compliance that we can issue. Do you volunteer?
  303. Ge0rG daniel: `Total: 1112 outgoing, 1079 incoming connections` - not sure how many MUCs there are, but cant' imagine it's 50%
  304. marc Ge0rG, let me first finish my URI handling in Conversations and the user-invitation XEP ;)
  305. jonasw Ge0rG, depends on what you want to check, the aioxmpp end-to-end test suite might be a good start :)
  306. marc Ge0rG, but I think that's really important
  307. Ge0rG marc: what's important?
  308. marc Ge0rG, some official server list
  309. Ge0rG marc: xmpp.net had a semi-official one.
  310. Ge0rG but now it's down and needs work to bring up again.
  311. jonasw yeah, about that xmpp.net thing, Kev, I’m still hoping for your Dockerfile :)
  312. marc if you have created an account on a server which doesn't support, let's say HTTP upload, and file transfer in group chats doesn work this user will be annoyed and probably will never use / recommand XMPP
  313. Kev jonasw: Let me sort that out now.
  314. jonasw Kev, that’d be lovely
  315. jonasw I’m tempted to sink my weekend into getting xmpp.net up&running again
  316. Ge0rG !praise jonasw
  317. jonasw (and then people wonder why jabbercat isn’t making progress)
  318. Guus !praise jonasw
  319. jonasw hold yer horser
  320. jonasw save the praise for when I’m done
  321. jonasw I might easily get fed up by PHP
  322. Kev What is jabbercat, BTW?
  323. Guus (by the way, why isn't jabbercat making progress?)
  324. jonasw Kev, https://github.com/jabbercat/jabbercat, TL;DR: new Qt5 Desktop Client
  325. Kev Because we don't have a Qt5 Desktop client already? :)
  326. Ge0rG it's a very promising early alpha
  327. marc Ge0rG, to speed things up "we" should decide how we implement PARS and user-invitation
  328. jonasw Kev, frankly, when I started, I didn’t know / forgot about Swift & co.
  329. Ge0rG The Swift bug tracking situation is not optimal. I've submitted a bunch of things and I have no clue whether they got fixed or not.
  330. Ge0rG (except for the wontfix ones)
  331. Ge0rG marc: let me help you with that. We integrate account creation into PARS.
  332. marc Ge0rG, okay, and what's the protocol flow then?
  333. Ge0rG marc: ad-hoc -> xmpp: URI with optional https: URI -> out-of-band -> IBR/PARS request
  334. Guus has left
  335. daniel has left
  336. marc Ge0rG, so the server generates / appends an additional PARS token if enabled?
  337. Ge0rG marc: if the server doesn't provide an https: URI, the client can either pass on xmpp: or use its own landing page (eg. https://yax.im/i/)
  338. Ge0rG marc: there is no "if enabled"
  339. Ge0rG and there is only one token, that can be used for both
  340. Ge0rG No, that won't work for closed-registration servers.
  341. marc Yeah, that's somehow my problem ;)
  342. Kev Ge0rG: Nothing is optimal :)
  343. jonasw Ge0rG, why?
  344. Ge0rG jonasw: the xmpp: URI needs an indicator whether registration is allowed.
  345. jonasw Ge0rG, ;allow-register?
  346. marc Because that means that somebody may propose just an other XEP for it...
  347. Ge0rG we could go with `xmpp://server/inviter@server;preauth=TOKEN` - `server` is explicitly telling us the domain where to register, the inviter JID is present and a token that can be used for either.
  348. Ge0rG But that will break most current clients that support xmpp:
  349. Ge0rG should we provide means for the server to specify a different domain from the inviter's?
  350. jonasw Ge0rG, will it though?
  351. marc Ge0rG, yes we should, I also had this idea :)
  352. Ge0rG jonasw: when you open an xmpp://foo.bar/user@foo.bar link, I'm pretty sure unexpected things will happen.
  353. marc yes, I think the XmppUri parser in Conversations is broken
  354. jonasw I’m pretty sure I’ll get "unknown protocol" because I don’t have an application which supports XMPP URIs at all
  355. Ge0rG the URI parser on android is broken as well
  356. marc At least it doesn't support the authority part properly AFAIK
  357. Ge0rG What about: > If the server allows In-Band-Registration with the preauth token, it SHOULD add an `ibr` parameter. If the IBR domain is different from the inviter's service domain, the server should set the value of the `ibr` parameter to the domain name.
  358. Ge0rG So we would end up with: `xmpp:georg@legacy.yax.im?preauth=TOKEN;ibr=yax.im`
  359. marc Ge0rG, should we really avoid using XMPP URI properly just because some clients don't implement the parser properly?
  360. Guus has left
  361. Ge0rG marc: we are using the URI properly.
  362. Ge0rG marc: the primary goal of the URI is to add a contact, not to register with the server
  363. jonasw are we? wouldn’t xmpp://yax.im/georg@legacy.yax.im be more correct?
  364. marc What about xmpp://server/inviter@server;preauth=token` then?
  365. Ge0rG See above.
  366. marc I think jonasw is right
  367. Guus has left
  368. Ge0rG marc: so your goal is to force the invitee to register with your server?
  369. marc Ge0rG, yes, at least it would be nice if we have an option for this use case
  370. Kev jonasw: How do you want this tarball?
  371. marc Ge0rG, because I'm pretty sure my server has nice XEPs enabled ;)
  372. jonasw Kev, deep fried
  373. jonasw Kev, mailto:jonas@wielicki.name
  374. Ge0rG marc: maybe we have different goals, then? I want to give out a link that allows the receiver to add me as a contact, and to create an account on the way if required
  375. jonasw I just wish this was all working before end of year :D
  376. zinid has left
  377. Ge0rG marc: if you want to "entice" the receiver to re-register on a different server, I don't agree.
  378. Kev jonasw: This is stuff for running up a symfony-based PHP thing, so you might want to trim some of the bits out - e.g. I have no idea if the frontend needs to install depedencies with composer. There might or might not need to be crontasks, trim that out if not, and you might or might not need to populate an environment file of some sort.
  379. Ge0rG marc: but in that case, the xmpp://server/inviter@server would be semantically correct.
  380. jonasw Kev, thank you very much
  381. marc Ge0rG, don't get me wrong, my intention is to make easy onboarding....
  382. jonasw gotta head out now for lunch, will take a look later :)
  383. Ge0rG marc: right. And onboarding without having to create an account is easier :P
  384. jonasw FWIW, marc, I think we shouldn’t encourage non-power users to have multiple accounts.
  385. Ge0rG what jonasw said.
  386. jonasw it should be there if they need and want it, but we shouldn’t make it the default path for the unthinking chicken installing debian :)
  387. jonasw (hitting enter / the big button on each step)
  388. jonasw (this is not to insult our users, just making a reference to the old joke that even a chicken can install debian by simply hitting on the Enter key repeatedly)
  389. stefandxm has left
  390. jonasw (and I think that it should be that easy to use XMPP)
  391. marc I agree, but to me it looks like we miss some useful feature in the XEP then
  392. Ge0rG marc: what would that useful feature be?
  393. marc Ge0rG, somebody is on a shitty server? :D
  394. Ge0rG marc: this is not a feature of the XEP
  395. marc well, it's user invitation
  396. Ge0rG marc: what about having a "server quality index" display in all clients, that can estimate how good the current server is, and how good the proposed one? :P
  397. Ge0rG marc: well. You can have the "Create new account on [ibr server]" button in the add-contact UI; and then you write into your invitation mail to click that button :P
  398. marc Ge0rG, if we don't have this feature there is no way to invite a user to a non-public server
  399. Ge0rG marc: my point is, what if you are on a shitty server and I'm not?
  400. Ge0rG marc: by non-public you mean non-federated?
  401. marc Ge0rG, no, just a server where only registered users can invite somebody
  402. arc has left
  403. lumi has joined
  404. arc has joined
  405. marc Ge0rG, I think there are some reasons to join a specific server even if an user has already an account, privacy/trust etc.
  406. Ge0rG marc: to invite a user to a non-federated server, the correct URI would be indeed `xmpp://server/inviter@server?ibr;preauth=TOKEN`
  407. marc This wouldn't be possible and IMO that's not good if we have the chance the include this
  408. marc Ge0rG, non-federated server is not the correct term
  409. marc Just because a server doesn't allow public registration it can still be federated...
  410. Ge0rG marc: if it allows federation, there is no need to force non-power-users to create a second account
  411. marc Ge0rG, even if the user is a "power-user", how to easily invite the user? via a web-interface / shell just because the XEP doesn't support this feature?
  412. jonasw I think you two are misunderstanding eaxh other
  413. marc :D
  414. jonasw Ge0rG wants to keep the account creation, but not as default
  415. jonasw and away
  416. marc Well, I'm fine with that :)
  417. marc It shouldn't be the default but it should be _possible_
  418. marc And, maybe that's the controversal part (?!), PARS should be optional
  419. marc Hm, maybe that's not too important
  420. marc I don't know
  421. ralphm has joined
  422. Ge0rG marc: why do you think PARS should be optional?
  423. marc Ge0rG, just thought about it
  424. marc Doesn't make sense
  425. Ge0rG marc: :)
  426. marc :)
  427. marc Okay, sounds good to me
  428. Ge0rG marc: anticipated UI: +-----------------------+ | Invitation from Georg | | | | JID: [georg@yax.im ] | | Name: [Georg ] | | | | [ ADD CONTACT ] | | | | [create yax.im accnt] | +-----------------------+
  429. Ge0rG marc: the first button is prominent, the second button is toned down, like "skip registration" would be
  430. marc Ge0rG, +1
  431. Flow Ge0rG, so JID and Name are editable text fields?
  432. Ge0rG Flow: the JID is visible but not editable, the name is editable
  433. Ge0rG Flow: one might want to add a roster group selector as well.
  434. Flow Hmm, how about "Invitation from Georg (georg@yaxim)" then?
  435. marc Ge0rG, if we agree on the possiblity of predefines usernames (optional) we're almost done :D
  436. Ge0rG marc: please don't.
  437. Flow and why is there a [create yax.im account] button?
  438. Ge0rG Flow: what's wrong with the above? You can reuse your regular "add contact" dialog and just disable JID editing
  439. marc Ge0rG, but it allows me as admin to create an account for an user
  440. marc As I said, optional, server-side option, maybe for admins only etc.
  441. marc Not useful for public servers
  442. Flow Ge0rG, ok, if that is the idea. But I would proably go for a specialized UI
  443. Ge0rG marc: if you already created an account, you should use xmpp://user@server?preauth=TOKEN
  444. Ge0rG Flow: [create yax.im account] is for power-users who want to have an account on the same server as the inviter.
  445. marc Ge0rG, well the user still has to specify the password
  446. marc So ibr is still correct I think
  447. Ge0rG marc: I think this is a completely different use case.
  448. Flow Ge0rG, but UX usually means to hide operating elements for power useres
  449. Ge0rG Flow: tell that to marc
  450. Flow will do
  451. marc :D
  452. Flow good thing a protocol can't require how the UI looks like
  453. Ge0rG Flow: actually that's a bad thing, in most cases.
  454. Flow Ge0rG, require or suggest? ;)
  455. Ge0rG Except when protocol designers try to create a UI :P
  456. Ge0rG But yeah, I think that hiding the account creation behind an "Advanced..." button would be good.
  457. stefandxm has joined
  458. marc Ge0rG, sounds good
  459. Ge0rG marc: we really do need a way to "export" an account to a new device, or to one-click register, but I think this is a (slightly) different use case
  460. @Alacer has left
  461. marc Ge0rG, just let me know what's the big difference between "you have the option to create an account or add the contact to your roster" and "you have the option to create an account with full JID or add the contact to your roster"?
  462. Ge0rG marc: what you are looking for is, as an admin, to pre-create an account and give the user enough info to just configure a password.
  463. marc Ge0rG, yes
  464. Ge0rG marc: what I'm looking for is to add a contact, and to create a user-defined account if required.
  465. marc Ge0rG, do you really think it's worth making an extra XEP for that?
  466. Ge0rG marc: if you pre-created an account, you want your invitee to use that.
  467. Ge0rG marc: I only want to give the invitee the option to create an account themselves
  468. marc Ge0rG, what's the down-side of allowing this optional feature?
  469. pep. has left
  470. Ge0rG marc: because this optional feature must be implemented by all clients
  471. marc okay, that's a reason
  472. Ge0rG marc: every time you add an option to a protocol, you double the number of possible situations
  473. marc But the code is very small
  474. daniel has left
  475. marc Ge0rG, I know I've implemented it in conversations
  476. marc You just have to check if that's a full JID or just the server name
  477. Ge0rG marc: so with optional inviter name, optional invitee JID, optional https:// URL, and the option to already have an account we are at sixteen different cases already.
  478. marc In the latter case you have to fix the server name in the JID text entry
  479. Ge0rG marc: I see two different, but related use cases: 1. you want to onboard someone to a pre-registered account on your server. Use `xmpp://user@server?preauth=TOKEN` 2. you want to add a contact. Use PARS with an `ibr` option.
  480. Ge0rG marc: both options can share wire protocol
  481. Ge0rG marc: both use cases can share wire protocol
  482. marc yes
  483. Ge0rG marc: and I think they also can share an XEP
  484. Guus has left
  485. marc Ge0rG, yes, me too that's why I'm so stubborn about it :D
  486. daniel has left
  487. daniel has left
  488. marc has left
  489. Ge0rG marc: it just doesn't make sense to map both use cases onto the same UI
  490. marc Ge0rG, on what side? inviter, invitee, both?
  491. Ge0rG marc: invitee
  492. marc Ge0rG, I'm fine with that
  493. Ge0rG marc: for the inviter, the admin use case can be mapped to some ad-hoc command without explicit client-side UI
  494. Ge0rG the user-inviting-user case should have a "Create invitation" UI
  495. marc Ge0rG, My demo showed the admin version
  496. marc Ge0rG, just imagine that a normal user would get the qr code directly
  497. Ge0rG marc: it's nice that you added the admin version into Conversatios, but that's quite some overkill
  498. marc Without the possibility to choose a username
  499. marc Ge0rG, actually that's all done automatically
  500. marc Because the server responds a form with the possiblity to choose a username
  501. marc There is no additional logic for this admin feature
  502. marc Since the UI is generated automatically by the form
  503. marc So I don't think that's overkill
  504. marc It's like generateUserInput(form);
  505. Ge0rG marc: okay, so if you are an admin, you get a data form for username / display name?
  506. marc Ge0rG, exactly
  507. Ge0rG marc: I think there is no need to XEPify that.
  508. marc username might still be optional but you get the possibility
  509. Ge0rG marc: we should XEPify the ad-hoc command name. And to a normal user, it should return a PARS;ibr link.
  510. marc Ge0rG, maybe not, but it would prevent user/admin defined behaviour...
  511. Ge0rG marc: if you are an admin, it might return a PARS;ibr link or a data form asking for a username
  512. marc Yes
  513. marc That's my idea
  514. Guus has left
  515. Ge0rG marc: if you leave out the username, it will return a PARS;ibr link. If you enter one, it will return an onboarding link of `xmpp://user@server;preauth=TOKEN`
  516. marc Ge0rG, looks good to me
  517. Ge0rG marc: so what needs to be XEPified is: ad-hoc command name; URI formats for both use cases; (approximate) client behavior for both use cases; wire-format for IBR
  518. Ge0rG +; dependency on PARS
  519. Ge0rG marc: what I really like about the admin use-case is that it finally allows to register on a server using a one-time-token
  520. marc Ge0rG, yes!
  521. Ge0rG There used to be an Easy_Account_Creation page on the wiki
  522. pep. Finally caught up with all your messages! Good to know you're getting somewhere :)
  523. marc :D
  524. marc I think we should re-use ?register action, right?
  525. ralphm has joined
  526. pep. iiuc, that means as a server admin I'll be able to issue registration tokens right? and have IBR wait for that token
  527. marc pep., yes
  528. Ge0rG marc: you mean https://xmpp.org/registrar/querytypes.html#register
  529. marc Yes
  530. Ge0rG marc: do you want me to write the XEP?
  531. pep. Obviously as a server admin I should be able to allow more people to issue tokens. Allowing everybody to issue these is not really smart though, right?
  532. jubalh has joined
  533. marc Ge0rG, we can work together on it
  534. marc pep., You can specify a set of people which are allowed to generate tokens or something like that
  535. pep. yeah
  536. marc But that really depends on your service
  537. Ge0rG pep.: you could disable generic IBR and use this mechanism to allow all your users to invite other users.
  538. marc exactly
  539. moparisthebest has joined
  540. pep. Ge0rG, I guess I could. Or have a blacklist rather than whitelist
  541. Ge0rG pep.: how is that supposed to work?
  542. arc has left
  543. arc has joined
  544. Ge0rG marc: there is also https://xmpp.org/extensions/attic/xep-0235-0.3.html
  545. marc Ge0rG, if you're fine with token expiration I think an other topic which need to be disucussed is how we handle/limit the number of invitations
  546. pep. Maybe it's not worth it, I have never been target of spam so you know better. But if a spammer gets one than it's similar to open IBR again
  547. Ge0rG Eh, https://xmpp.org/extensions/xep-0235.html
  548. Ge0rG marc: I think that is absolutely out-of-scope
  549. pep. They'd be able to generate tokens etc.
  550. pep. You can traceback where it came from though
  551. moparisthebest has joined
  552. marc Ge0rG, we should at least define an error for that
  553. Ge0rG pep.: right, one could easily kick the spammer and all of their friends.
  554. marc Ge0rG, nothing is more annyoing to a user if you get something like "doesn't work at the moment, try again later!"
  555. Ge0rG marc: I'm sure we can re-use existing IBR errors
  556. marc Ge0rG, I mean for token/invitation generation
  557. Ge0rG And there is https://xmpp.org/extensions/inbox/user-auth.html
  558. Ge0rG marc: the ad-hoc command should always return a token, just maybe not with an `ibr` tag.
  559. marc Ge0rG, that would be confusing ;)
  560. Ge0rG marc: to whom?
  561. Ge0rG marc: the default use case is to generate a PARS uri
  562. Ge0rG marc: if you are talking of the admin use case, yes, it should return an error.
  563. marc sometimes you have the ability to create an account sometime not?
  564. marc +s
  565. Ge0rG marc: for the user use case, the server generates a PARS or a PARS;ibr link
  566. Ge0rG marc: depending on whether user-initiated account creation is allowed on the server.
  567. Ge0rG marc: a non-ibr PARS link will mean that the invitee's client is responsible for account creation
  568. marc Ge0rG, just thought about the case where an inviter creates too much PARS;ibr tokens
  569. marc Maybe you want some policy to limit the number of PARS;ibr tokens
  570. Ge0rG marc: maybe. But there is no need to expose that to the inviter's client
  571. stefandxm has left
  572. marc (1) Marc invites somebody without account -> server generates PARS;ibr -> nice (2) Marc invites somebody without account -> server generates PARS only -> invitee and Marc are confused
  573. marc Ge0rG, maybe I don't get your idea but this is how I understood your approach
  574. Ge0rG marc: (2) Marc invites somebody without account -> server generates PARS only -> invitee opens link in yaxim and registers on yax.im -> nice
  575. ralphm has joined
  576. marc Ge0rG, sounds like a bad idea to me... not every client provides a xmpp server?
  577. Ge0rG marc: no, but the ones implementing PARS do :P
  578. jonasw for now
  579. marc Ge0rG, Does PARS require a client software to provide a xmpp server?
  580. Ge0rG marc: actually, I forgot to add that part to the XEP
  581. marc Ge0rG, :p
  582. Ge0rG marc: but yes, I think that a client implementing PARS needs to have a sensible user-onboarding flow that does not depend on the invitee.
  583. jonasw Ge0rG, so jabbercat better doesn’t implement PARS
  584. Ge0rG marc: it doesn't mean the client developer must run an IBR server, they can provide a list of public servers instead
  585. jonasw (I won’t get into the business of running a public server.)
  586. jonasw ah well
  587. Ge0rG jonasw: you can SRV-link jabbercat.im to the yaxim server :P
  588. marc :>
  589. marc Ge0rG, okay, I think I'm okay with your idea
  590. jonasw Ge0rG, will do
  591. Ge0rG jonasw: I'm pretty sure I can handle the additional load
  592. Ge0rG jonasw: btw, did you buy out jabber.cat already? :P
  593. jonasw no, won’t
  594. jonasw too politically unstable that TLD ;-)
  595. Ge0rG Heh.
  596. Ge0rG Still better than .io
  597. marc Although it may be very confusing if that happens to invitees who sit next to each, for example ^^
  598. jonasw does im have DNSSEC by now?
  599. Ge0rG jonasw: nope
  600. jonasw m(
  601. Ge0rG marc: why so?
  602. marc Ge0rG, because they don't get the same dialog
  603. marc Ge0rG, invitee A an create an account on the server and invitee B can choose some public server
  604. jonasw Ge0rG, but then I want private+persistent PEP on jabbercat.im!
  605. Ge0rG jonasw: please star & comment on https://prosody.im/issues/485
  606. jonasw I won’t comment, Zash hates that
  607. jonasw (rightfully so)
  608. jonasw > PEP with permanent storage is now in mod_pep_plus and should be working. Thanks to Link Mauve!
  609. pep. Yeah, that's in trunk
  610. Ge0rG > Is this feature usable with 0.10? *crickets*
  611. pep. 0.10, pff :)
  612. edhelas just to give you ideas, in Movim I've implemented an invitation system for MUC that generate a unique link https://nl.movim.eu/?login/GA1dbdSB
  613. edhelas once the user login it automatically ask him to add the MUC to the bookmarks and join
  614. edhelas it's a bit like Discords in doing
  615. Ge0rG edhelas: web-based stuff is easier
  616. edhelas yup
  617. jonasw I want that MUC invite integration thing
  618. Ge0rG edhelas: can you make it work with PARS and easy-xmpp-invitation? :P
  619. edhelas dunno
  620. Ge0rG "Timothée Jaussoinhat Sie eingeladen, einen Chatraum zu bet..." - the UI is cut off.
  621. Guus That's what you get for inventing such long words in your language!
  622. Guus shees, you're almost as bad as the Finnish!
  623. edhelas there's never enough place to display german messages
  624. pep. it's also cut off in english
  625. Guus oh. :)
  626. jonasw Guus, don’t insult the finnish
  627. Ge0rG edhelas: which is why German is a good UI testing language.
  628. jonasw they’ve got the most amazing language on this continent
  629. jonasw yeah, long words and long sentences :)
  630. jonasw and umlauts!
  631. edhelas they beat all of us at the Scrabble
  632. Guus has left
  633. pep. edhelas, where is that in the UI btw? Where do I generate that
  634. Ge0rG My favorite was a bug report by a user that my app was lacking a button. It took me a looong while to find out that on some Android version, the OS developers removed text-wrapping from buttons, and the "OK" button was outside of the dialog
  635. Guus jonasw: I'm always laughing at subtitles Finnish tv, where one of the lines (Swedish), has words, and the other line (Finnish) has _a word_.
  636. jonasw :)
  637. jonasw that’s how amazing it is!
  638. edhelas pep. in a chatroom, click Menu > Invite
  639. pep. nice
  640. Ge0rG https://stackoverflow.com/questions/26708976/alert-dialog-buttons-problems-in-android-l - this one, except that in my app, the button was completely gone!
  641. ralphm has joined
  642. uc has joined
  643. uc has joined
  644. Guus has left
  645. valo has left
  646. valo has joined
  647. uc has joined
  648. sezuan has joined
  649. uc has joined
  650. lskdjf has joined
  651. lskdjf has joined
  652. sezuan has left
  653. sezuan has joined
  654. sezuan has left
  655. valo has left
  656. valo has joined
  657. Ge0rG Should the ad-hoc command node be a human-readable short string or a unique identifier / URL?
  658. jonasw the latter
  659. jonasw there’s a separate name field thing
  660. Guus has left
  661. jonasw cf. https://xmpp.org/extensions/xep-0050.html#retrieve
  662. Ge0rG prosody is using URLs as node names, the XEP is using short identifiers.
  663. Ge0rG I'm not talking about the 'name' field but about 'node'
  664. jonasw URLs is probably safest
  665. jonasw me too
  666. Alex has joined
  667. sezuan has joined
  668. Ge0rG > Service Discovery requires that all 'node' values be unique within a given JID. This document requires that the 'node' value used in <command/> exactly match the value used in the <item/> element. It is the responsibility of the responder implementation to ensure each command's node is unique for their JID. So short identifiers are valid as well, unless you support plugins that add more nodes.
  669. debacle has joined
  670. jonasw yup
  671. Ge0rG So for the sake of implementing an invitation ad-hoc-command, it should be a URL as well? Hmhm.
  672. jonasw one could probably re-use the URI the XEP will allocate
  673. Ge0rG you mean the XEP html URI?
  674. jonasw no
  675. jonasw urn:xmpp:fancy-invite-xep:0:fnord
  676. jonasw urn:xmpp:fancy-invite-xep:0:command
  677. Ge0rG ah, yes.
  678. Guus has left
  679. daniel has joined
  680. valo has left
  681. valo has joined
  682. marc Ge0rG, are you writing the XEP atm?
  683. daniel has left
  684. daniel has joined
  685. stefandxm has joined
  686. Ge0rG marc: not yet. Should I?
  687. daniel has joined
  688. marc Ge0rG, Just asking because your question regarding ad-hoc command
  689. pep. has left
  690. pep. has left
  691. nyco has left
  692. pep. has left
  693. daniel has left
  694. daniel has joined
  695. uc has joined
  696. uc has joined
  697. sonny has left
  698. Ge0rG marc: I was looking into what's needed to write that XEP
  699. stefandxm has left
  700. daniel has left
  701. daniel has joined
  702. daniel has left
  703. daniel has joined
  704. marc has left
  705. nyco has joined
  706. Ge0rG found another onboarding bug in yaxim: if you open yaxim with an xmpp: Intent, and you don't have an account yet, it will error out.
  707. nyco has left
  708. nyco has joined
  709. la|r|ma has joined
  710. jonasw fix things!
  711. la|r|ma has joined
  712. Ge0rG Fixed. Looks good.
  713. la|r|ma has joined
  714. Ge0rG Meh. Why is there no non-shady barcode scanner app that works in portrait mode?
  715. jonasw mine switches; is that important?
  716. Ge0rG yes, if you want to screen-record.
  717. Ge0rG especially since the launcher locks to portrait mode.
  718. pep. Ge0rG, marc, what are you going for in the end, improving PARS to include that use case, or another XEP?
  719. Alex has left
  720. tim@boese-ban.de has joined
  721. Ge0rG pep.: probably both
  722. pep. I'm filing a bug against dino for IBR and PARS
  723. marc pep., you mean regular IBR?
  724. Steve Kille has left
  725. Steve Kille has joined
  726. pitchum has joined
  727. pep. 0077 yeah, at least, they don't have it apparently, from the quick search I did
  728. pitchum has left
  729. Ge0rG marc: https://op-co.de/tmp/easy-onboarding.mp4 (2.5MB)
  730. Ge0rG marc: https://op-co.de/tmp/easy-onboarding.mp4 (2.5MB; broken IPv6)
  731. nyco has left
  732. daniel has left
  733. moparisthebest has left
  734. moparisthebest has left
  735. moparisthebest has joined
  736. marc Ge0rG, nice!
  737. marc You already have a "parkedtextview"
  738. nyco has joined
  739. pep. Ge0rG, I feel that "Register a new account" check might be one check too many
  740. marc I searched one for Conversations
  741. marc pep., Indeed
  742. pep. Ge0rG, mind you I don't want to force the account creation on that server
  743. pep. Just talking UX wise
  744. Ge0rG marc: what's a parkedtextview?
  745. Ge0rG pep.: the usual approach is two buttons: "[login] [create]"
  746. marc A textview where you have a fixed text at the end (e.g. @example.com)
  747. Ge0rG marc: it's not parked, it's smart.
  748. Ge0rG marc: wait, I'll show you.
  749. marc Ge0rG, I found a textview on GitHub that promised to do that and it was called "ParkedTextView"
  750. marc I don't know if that's the correct term :D
  751. Ge0rG marc: https://op-co.de/tmp/autocomplete-jid.mp4
  752. Ge0rG marc: https://github.com/pfleidi/yaxim/blob/master/src/org/yaxim/androidclient/widget/AutoCompleteJidEdit.java
  753. Ge0rG marc: and if you tap into the hostname part, it will make it editable as well.
  754. pep. Ge0rG, who do I pay to appear in your server list?
  755. marc Ge0rG, that's nice! It is also possible to fix the domain part?
  756. Ge0rG pep.: PR against https://github.com/pfleidi/yaxim/blob/master/res/values/servers.xml
  757. Ge0rG marc: nope, not supported yet
  758. marc pep., In a perfect world this server list would be download from a server list provided by XSF or something like that
  759. marc +ed
  760. mathieui marc, in a perfect world we would have no need for xmpp
  761. pep. Ge0rG, k
  762. pep. mathieui, you mean everybody would be using WhatsApp?
  763. Ge0rG pep.: the former source is this: `curl -s http://xmpp.net/services.xml | xml2 | awk -F= '/@jid=/ { print "\t\t<item>" $2 "</item>" }' | sort -n`
  764. pep. Ge0rG, and then you tested for IBR?
  765. Ge0rG pep.: no.
  766. marc Ge0rG, easy onboarding!!1! :D
  767. Ge0rG pep.: it's a generic public-server list for JID auto-completion, I don't have IBR flags.
  768. pep. I'm curious what would get included in the list
  769. marc We really need a good server list... :D
  770. Ge0rG marc: we need a list with meta-data, like hosting country, privacy regulations, ToS-TLDR, reliability, and of course a fancy logo.
  771. Ge0rG The logo is the most important part, people don't care about the others.
  772. marc Ge0rG, if meta-data includes XEPs, yes
  773. SouL +1 for the logo
  774. pep. Ge0rG, agreed, a server-list like that would be nice
  775. Ge0rG marc: there was some discussion on standards@ regarding that.
  776. Ge0rG Probably around a year ago
  777. Guus has left
  778. marc Yes, we need a badge and a list for public server which support all XEPs required for mobile devices, HTTP upload, OMEMO, etc.
  779. Ge0rG marc: you just volunteered.
  780. sonny has left
  781. pep. marc, OMEMO is a client-side thing
  782. pep. well, PEP ~
  783. jmpman has joined
  784. marc pep., No, it needs PEP
  785. pep. Sure
  786. Ge0rG The PARS proposal that daniel made also needs PEP. Private PEP
  787. marc Ge0rG, what's that?
  788. marc I mean the PARS proposal
  789. Ge0rG marc: current PARS requires the client to handle token generation and approval. Daniel suggested to make a private-PEP entry storing a HMAC key, so that the server can validate ingress tokens
  790. pep. I'm not sure I understand how that would work
  791. jonasw Ge0rG, your broken IPv6 is annoying
  792. jonasw mpv is now at more than a minute for trying to connect to your server
  793. jonasw can you please remove the AAAA records
  794. daniel Ge0rG, will it also be able to validate pokemon go tokens?
  795. pep. jonasw, yeah same, I resorted for wget / mpv instead :/
  796. nyco has left
  797. pep. jonasw, yeah same, I resorted to wget / mpv instead :/
  798. jonasw finally
  799. jonasw oh no
  800. jonasw ah yes
  801. Guus has left
  802. Guus has joined
  803. stefandxm has joined
  804. jonasw Ge0rG, hm, somehow the firs t screen seems cluttered
  805. jonasw is it possible to show *only* the dialogue without the othert suff in the background?
  806. jonasw is it possible to show *only* the dialogue without the other stuff in the background?
  807. Ge0rG jonasw: you will find bliss in RFC 6555
  808. pep. happy eyeball?
  809. jonasw Ge0rG, yeah, but I can’t make that magically happen
  810. pep. heh
  811. Ge0rG jonasw: the first screen of yaxim? the account creation one?
  812. jonasw yes
  813. Ge0rG jonasw: do what I would do. https://github.com/dino/dino/issues/208
  814. jonasw that is, make the dialogue full screen. what’s that called in android?
  815. jonasw Ge0rG, I don’t even know which component is at fault here
  816. jmpman has joined
  817. jonasw is it glibc for not doing this on connect(2)? is it mpv for not opening separate connections by itself? is it maybe even youtube-dl? I have no idea.
  818. Ge0rG jonasw: probably it's mpv
  819. Ge0rG youtube-dl -4, --force-ipv4 Make all connections via IPv4
  820. jonasw mpv didn’t accept -4
  821. jonasw also, ECHAN
  822. Ge0rG has left
  823. daniel has left
  824. Guus has left
  825. Tobias has joined
  826. stefandxm has left
  827. daniel has left
  828. Guus has joined
  829. daniel has left
  830. nyco has joined
  831. daniel has left
  832. daniel has left
  833. daniel has left
  834. Guus has left
  835. ralphm has joined
  836. Alex has joined
  837. zinid has left
  838. nyco has left
  839. jmpman has joined
  840. nyco has joined
  841. jmpman has joined
  842. Alex has left
  843. Alex has joined
  844. Alex has left
  845. Guus has left
  846. tux has left
  847. jmpman has left
  848. jmpman has joined
  849. Tobias has left
  850. Tobias has joined
  851. Ge0rG has left
  852. sonny has joined
  853. Steve Kille has left
  854. Steve Kille has left
  855. Steve Kille has joined
  856. stefandxm has joined
  857. zinid has left
  858. lumi has left
  859. stefandxm has left
  860. ralphm has joined
  861. Ge0rG has joined
  862. sonny has left
  863. sonny has joined
  864. Guus has left
  865. daniel has left
  866. mathieui https://gateway.ipfs.io/ipns/QmSgwwdejjsizQnKffKo6e84vfvBWCH5tnGpAwLPJVvhby/ if any german people are available, it may be interesting
  867. ralphm has left
  868. Ge0rG has left
  869. debacle has left
  870. daniel has left
  871. Alex has joined
  872. ralphm has joined
  873. zinid ipfs never works 😉
  874. Guus has left
  875. jubalh has left
  876. marc has left
  877. Ge0rG has left
  878. zinid has left
  879. waqas has joined
  880. ralphm has joined
  881. jmpman has joined
  882. jmpman has joined
  883. Ge0rG has left
  884. Ge0rG has left
  885. waqas has left
  886. Ge0rG has left
  887. jjrh has left
  888. Ge0rG has left
  889. Ge0rG has left
  890. Ge0rG has left
  891. ralphm has joined
  892. daniel has left
  893. jubalh has joined
  894. jubalh has left
  895. jjrh has left
  896. jjrh has left
  897. daniel has left
  898. jjrh has left
  899. Ge0rG has left
  900. Ge0rG has left
  901. ralphm has joined
  902. stefandxm has joined
  903. @Alacer has left
  904. Holger has left
  905. @Alacer has joined
  906. uc has left
  907. zinid has left
  908. SamWhited has left
  909. ralphm has joined
  910. stefandxm has left
  911. mimi89999 has joined
  912. lumi has joined
  913. ralphm has left
  914. ralphm has joined
  915. waqas has joined
  916. waqas has left
  917. jubalh has joined
  918. ralphm has left
  919. ralphm has joined
  920. Alex has left
  921. valo has left
  922. ralphm has left
  923. valo has joined
  924. ralphm has joined
  925. jubalh has joined
  926. Guus has left
  927. ralphm has left
  928. ralphm has joined
  929. Guus has left
  930. ralphm has left
  931. la|r|ma has joined
  932. zinid has left
  933. Alex has joined
  934. daniel has left
  935. ralphm has joined
  936. Alex he guys, lets start the member meeting in 2 minutes
  937. Zash Feels like we just had this, with the board/council not too long ago :)
  938. Alex bangs the gavel
  939. Alex here is our Agenda for today: https://wiki.xmpp.org/web/Meeting-Minutes-2017-12-08
  940. mathieui Alex, it’s supposed to be at 20:00 UTC ?
  941. mathieui it’s 19:00 right now
  942. Alex then I put it wrong in teh Cal ;-)
  943. mathieui right, wiki says 19:00 but latest members mailing says 20:00
  944. Zash 19:05 even!
  945. Alex lets do it now, as I have to leave soon, when there are no concerns
  946. Ge0rG What if there are members wanting to vote at 20:00?
  947. SamWhited Does anyone ever actually want to vote in the meeting? It doesn't matter, let's just do it now while Alex is here.
  948. stefandxm has joined
  949. Zash If you wanna be Procedurally Correct, then the time in the announcement is probably the best. And since it is later, it's also probably safer.
  950. Zash SamWhited: Last minute proxy-bot-votes happen tho
  951. Zash Altho if the original original announcement said yesterday then everyone should have voted already, so ..
  952. SamWhited Does it ever actually come down to one or two votes then? Why try to fix it until it's a problem?
  953. Alex SamWhited agreed, lets continue
  954. Zash Go for it
  955. Alex 1) Call for Quorum
  956. Alex as you can see 34 members voted via memberbot, so we have a quorum
  957. Alex 2) Items Subject to a Vote, new and returning members, you can see the lists of applicants here: https://wiki.xmpp.org/web/Membership_Applications_Q4_2017
  958. Alex 3) Opportunity for XSF Members to Vote in the Meeting
  959. Alex anybody here who wants to vote now?
  960. Alex memberbot would be still up for that
  961. Alex ok, will start working on the results then
  962. Zash In case anyone had wanted to, but showed up at the announced time, then it'd be a bit weird.
  963. ralphm has joined
  964. mathieui Zash, well, initial voting time has already passed, and we have to resolve conflicts only if a number of people significant enough to change results take issue with that
  965. jjrh has left
  966. jjrh has left
  967. Alex 4) Announcement of Voting Results
  968. Alex when you reload the page at: https://wiki.xmpp.org/web/Meeting-Minutes-2017-12-08#Announcement_of_Voting_Results you can see the results
  969. Alex all new and returning members are accepted
  970. Ge0rG Congratulations, everybody!
  971. Ge0rG 🎆
  972. mathieui Congratulations to all returning members and pep.
  973. Alex 5) Any Other Business?
  974. Alex looks like there is none
  975. Alex 6) Formal Adjournment
  976. Alex I motion that we adjourn
  977. mathieui seconded
  978. Alex bangs the gavel
  979. Alex thanks guys
  980. SamWhited Thanks alex; and congrats all!
  981. mathieui thanks for the work, as always, Alex
  982. SamWhited Ge0rG: In most text fields on my machine I can tell what that was… in Android I can tell what that was… in my console:
  983. SamWhited https://i.imgur.com/3jykNf1.png
  984. pep. I'm interested in hearing about the 4 No votes, ping me in private if you want to talk about it
  985. Alex and sorry about the time confustion. I work in too many different timezones these days ;-)
  986. Alex pep.: maybe related to the short application, at least this is some kind of pattern I have seen in the past
  987. jjrh has left
  988. jjrh has left
  989. pep. Ok
  990. Ge0rG SamWhited: what kind of console is that? Maybe you need Smiley Hugification™
  991. zinid has left
  992. jjrh has left
  993. SamWhited Ge0rG: mcabber on xfce4-term (which is weird, I realized I wasn't actually sure since I don't use xfce4 anymore, but apparently I left the terminal installed)…
  994. Ge0rG weird indeed.
  995. lovetox pep. i like you, just wanted to put it out there.
  996. daniel has left
  997. pep. lovetox: 😘
  998. xnyhps has left
  999. stefandxm has left
  1000. xnyhps has joined
  1001. SamWhited has left
  1002. Guus has left
  1003. ralphm has joined
  1004. stefandxm has joined
  1005. jjrh has left
  1006. daniel has left
  1007. jjrh has left
  1008. ralphm has left
  1009. jabberatdemo has joined
  1010. jabberatdemo has left
  1011. SouL Congratulations everyone, and also pep. !
  1012. ralphm has joined
  1013. Alex has left
  1014. Tobias has joined
  1015. Tobias has joined
  1016. jubalh has joined
  1017. sonny has left
  1018. sonny has joined
  1019. sonny has left
  1020. sonny has joined
  1021. ralphm has joined
  1022. Ge0rG has joined
  1023. Ge0rG has left
  1024. jubalh has left
  1025. daniel has left
  1026. daniel has left
  1027. Zash Bunneh: draft uta-email-deep
  1028. Bunneh Zash: "Cleartext Considered Obsolete: Use of TLS for Email Submission and Access", Keith Moore, Chris Newman, 2017-12-06, https://tools.ietf.org/html/draft-ietf-uta-email-deep-12.txt
  1029. nyco has left
  1030. Zash 2014 called, or something
  1031. la|r|ma has left
  1032. nyco has joined
  1033. ralphm has joined
  1034. la|r|ma has joined
  1035. Ge0rG Zash: it was 2014 for Jabber, and that was already a decade late
  1036. Zash Better late than never?
  1037. Ge0rG Yeah, right
  1038. Ge0rG Oh, that rfc is for MUA access to servers. They are really a decade late
  1039. daniel has left
  1040. uc has joined
  1041. Ge0rG has left
  1042. moparisthebest interesting they chose the term 'Implicit TLS'
  1043. moparisthebest we settled on 'Direct TLS' for 368
  1044. moparisthebest but I'm excited we are back to doing that for mail, I mean I have been, because it lets me multiplex on SNI and use 443 for imap+smtp+pop
  1045. moparisthebest but I'm excited it's going back to recommended status :)
  1046. zinid has left
  1047. moparisthebest if that reaches draft can we bring back implicit 5223 also ? :D
  1048. Guus has left
  1049. Lance has joined
  1050. ralphm has joined
  1051. vanitasvitae has left
  1052. vanitasvitae has joined
  1053. vanitasvitae has left
  1054. vanitasvitae has joined
  1055. Guus has left
  1056. Lance has joined
  1057. daniel has left
  1058. jjrh has left
  1059. jjrh has left
  1060. SamWhited has left
  1061. moparisthebest has joined
  1062. jjrh has left
  1063. daniel has left
  1064. sonny has left
  1065. sonny has joined
  1066. sonny has left
  1067. sonny has joined
  1068. daniel has left
  1069. sonny has left
  1070. sonny has joined
  1071. Lance has joined
  1072. jubalh has left
  1073. jjrh has left
  1074. daniel has left
  1075. stefandxm has left