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