XSF Discussion - 2017-12-08


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

  2. jonasw

    marc, what’d you use them for?

  3. marc

    jonasw, share a message

  4. marc

    Do you know these social share buttons on YouTube, Wordpress etc?

  5. marc

    That would be a use case

  6. jonasw

    ah, I see

  7. marc

    You click on it, the XMPP client pops up and let you decide the contact you want to share the message with

  8. jonasw

    if the RFC doesn’t allow for it, we need to extend the RFC I guess

  9. jonasw

    although I’m not sure if the URI RFC allows it :/

  10. marc

    It does

  11. marc

    At least I'm pretty sure

  12. jonasw

    implement it, the RFC can follow :)

  13. marc

    I'll double check if that possible in general URIs

  14. marc

    jonasw, I have an implementation for Conversations

  15. marc

    It needs some restructuring but PoC works fine

  16. jonasw

    python urllib at least accepts xmpp:?

  17. jonasw

    which RFC specifies xmpp: again?

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

  19. marc

    https://tools.ietf.org/html/rfc5122#section-2.2

  20. marc

    So URIs allow it

  21. marc

    We need to change XMPP URI RFC :)

  22. marc

    Of course, we could use an ugly hack like "xmpp:share?message;body=BODY"

  23. marc

    But I don't like it

  24. jonasw

    I think it allows it

  25. jonasw

    but I may be mistaken

  26. jonasw

    the rule we’re expanding in this case is: xmppiri = "xmpp" ":" ihierxmpp, ihierxmpp = ipathxmpp, ipathxmpp = ihost

  27. jonasw

    ihost is defined in: https://tools.ietf.org/html/rfc3987#section-2.2

  28. jonasw

    as: ihost = *( iunreserved / pct-encoded / sub-delims )

  29. jonasw

    the asterisk is defined in: https://tools.ietf.org/html/rfc2234

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

  31. jonasw

    this means that *( foo ) is zero or more of foo

  32. jonasw

    in this case it means that ihost can be empty

  33. jonasw

    thus it is legal to have an empty JID *as per the grammar*

  34. jonasw

    I haven’t checked the text yet :)

  35. jonasw

    the same holds for the URI interpretation, but without the leading "i"

  36. marc

    Mhm okay

  37. jonasw

    it might be an oversight that the grammar allows it, but it’s useful in this case :)

  38. marc

    Maybe I need to read this document thoroughly, there is also something like "xmpp://guest@example.com/support@example.com?message"

  39. jonasw

    yeah

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

  41. marc

    Ge0rG, what is you@yourserver? The JID of the inviter?

  42. Ge0rG

    marc: correct

  43. marc

    Ge0rG, the client still must provide the possiblity to create an account even if you already have one

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

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

  46. jonasw

    marc, FWIW, if you really want that feature, I’d hide it at the bottom of the screen

  47. jonasw

    like websites hide the "continue without" button when asking for your phone number :)

  48. marc

    jonasw, maybe I want to give a user the possibility to join _my_ server

  49. marc

    I think that feature is not unreasonable

  50. jonasw

    marc, I doubt that many users care a lot of about that.

  51. Ge0rG

    the default flow should be as easy as possible.

  52. marc

    yes, the default user has no account :P

  53. marc

    -> the default user will not be confronted with a dialog

  54. marc

    Ge0rG, I'm not sure about the ?roster action

  55. Ge0rG

    marc: I don't care about the action too much

  56. Ge0rG

    marc: but there will be a dialog, either account creation or add-contact

  57. jonasw

    s/roster/invite/?

  58. marc

    Ge0rG, Yes, if you already have an account there should be an "add-contact" dialog with an option to create an account

  59. marc

    (instead of just use an existing account)

  60. daniel

    > you send a url of xmpp:you@yourserver?roster;invitation=token out-of-band shouldn't that be xmpp://you@yourserver or something

  61. Ge0rG

    marc: if the client supports multiple accounts. which is arguably a power-user feature that makes UX complicated

  62. jonasw

    daniel, are you asking because of the semantic difference between xmpp:// and xmpp:?

  63. daniel

    jonasw, yes

  64. Ge0rG

    daniel: no, :// would be an account reference, : is a contact reference

  65. marc

    daniel, no

  66. marc

    I had the same idea

  67. marc

    but the authority is to indicate the account to use

  68. daniel

    oh i thought you was I

  69. daniel

    like you the proposed username for me

  70. Ge0rG

    daniel: you could do something like xmpp://proposed_invitee_jid@server/inviter@server

  71. marc

    Ge0rG, why does it lead to a complicated UI? Just a small button "Create account" in the bottom left/right corner

  72. daniel

    Ge0rG, yeah i thought that's what this thing was trying to do. never mind

  73. Ge0rG

    marc: the complicated UI arises when you have multiple accounts

  74. Ge0rG

    marc: now you need a notion of a default account, or ask the user on every interaction which account to use

  75. daniel

    marc, have you considered what communication method I would use to send you the url?

  76. daniel

    becasue gmail for example doesn't make xmpp uris clickable

  77. daniel

    neither does the sms app

  78. marc

    Ge0rG, you already have to ask the user what account to use

  79. marc

    daniel, we use an invitation url

  80. Ge0rG

    daniel: I would love to anchor that onto the easy-xmpp-invite mechanism

  81. daniel

    marc, like an https url?

  82. marc

    daniel, yes

  83. Ge0rG

    marc: that's exactly my point, it's a UX nightmare.

  84. daniel

    why are you discussing xmpp uri schemes then?

  85. marc

    daniel, that's an other topic ;)

  86. Ge0rG

    it's all interrelated.

  87. daniel

    only that xmpp uris are mostly worthless

  88. daniel

    when it comes to easy onboarding

  89. marc

    Yes

  90. edhelas

    was difficult to figure out those xmpp uris as well for me

  91. Ge0rG

    daniel: right, so I've made easy-xmpp-invitation.

  92. Ge0rG

    daniel: which allows to bridge xmpp: URIs over https.

  93. daniel

    edhelas, it's not that they are difficult. but you can't click them

  94. jonasw

    daniel, you can make any URL clickable on a website -> win

  95. Ge0rG

    jonasw: but it won't magically work.

  96. marc

    Ge0rG, I don't get what's the problem with multiple accounts. We already have clients that support multiple accounts.

  97. marc

    And there is almost no additional work for the UI

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

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

  100. Ge0rG

    and users have very large fingers.

  101. marc

    Ge0rG, yes, that needs to be solved by the UI nicely :D

  102. marc

    That's why the preferred option is to add the contact via PARS if an account is available

  103. marc

    But creating a XEP just for user invitation to a server if the user doesn't already have an account limits the possibilities...

  104. Ge0rG

    marc: right, which is why the whole thing is also technically a bit more complex

  105. marc

    Ge0rG, my problem at the moment is that I'm not sure how to integrate both XEPs properly

  106. marc

    In a way that both do not depend on each other and can be implemented independetly

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

  108. marc

    Ge0rG, yes, but the tokens need to be the same if both is used

  109. Ge0rG

    the server needs to store the token in some kind of table anyway, where it will also contain the inviter's JID

  110. Ge0rG

    marc: I think that re-using this token for server-side PARS shouldn't hurt

  111. Ge0rG

    marc: so your specification means a server must implement PARS

  112. Ge0rG

    marc: or, alternatively, you need to add two tokens to the URL

  113. Ge0rG

    Actually, I would be okay with extending PARS accordingly.

  114. Ge0rG

    So that it covers both use cases.

  115. marc

    two token keys with the same token, like invite=TOKEN;preauth=TOKEN ?

  116. marc

    Such that the clients know that both is supported?

  117. Ge0rG

    marc: yes, like that.

  118. Ge0rG

    marc: or maybe invite_and_preauth=TOKEN ;)

  119. Ge0rG

    I like short URIs

  120. marc

    Ge0rG, No!

  121. marc

    :D

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

  123. marc

    So implementing user-invitation requires implementation of PARS, right?

  124. Ge0rG

    marc: not technically, but if you want to provide a good UX then yes

  125. marc

    Ge0rG, Yes, for nice UX I would prefer it this way

  126. marc

    Ge0rG, your statement sounds like a requirement

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

  128. marc

    Ge0rG, the server if it supports PARS?

  129. Ge0rG

    marc: in the ad-hoc response?

  130. jonasw

    Ge0rG, for breveity, the URI could also be ?invite=TOKEN;preauth=, with the empty preauth signifying that the token shall be re-used

  131. Ge0rG

    jonasw: then you are breaking existing PARS clients :P

  132. jonasw

    then turn it the other way round :)

  133. jonasw

    preauth=TOKEN;invite=

  134. Ge0rG

    jonasw: the more I think about it, the more I want to merge both functions into one XEP

  135. jonasw

    I agree

  136. marc

    Ge0rG, yes, in the ad-hoc response

  137. marc

    Ge0rG, are there any PARS clients out there? :D

  138. Ge0rG

    marc: there is yaxim

  139. marc

    Ge0rG, ah okay

  140. jonasw

    it’s on the to-do for jabbercat

  141. marc

    Ge0rG, well, I like your idea of combining both "features" but they should not be depend on each other IMO

  142. Ge0rG

    marc: that depends on your goal

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

  144. marc

    The combination of both would make on-boarding really nice

  145. marc

    Ge0rG, of course, providing both should be recommended for public servers

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

  147. 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!?"

  148. Ge0rG

    on the invitee's client, I need to cover all four combinations of features

  149. Ge0rG

    none / invite / pars / invite+pars

  150. marc

    Ge0rG, no, the server just adds the PARS token and returns it

  151. Ge0rG

    marc: but the server doesn't support PARS, only the client.

  152. Ge0rG

    I've designed PARS as a client-only protocol because server developers are lazy.

  153. marc

    Ge0rG, ah okay, didn't thought about that use case

  154. Ge0rG

    And server operators are even lazier.

  155. jonasw

    yeah, server developers aren’t that lazy

  156. marc

    Ge0rG, that's a good point... hm...

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

  158. marc

    Ge0rG, well, that's true for all server-side XEPs

  159. Ge0rG

    marc: true

  160. marc

    Ge0rG, should be implement everything on the client side?

  161. Ge0rG

    marc: now you know why PARS can be implemented 100% client-side

  162. marc

    s/be/we

  163. jonasw

    Ge0rG, I think it might be not /that/ bad

  164. Ge0rG

    marc: Daniel's compliance tester is a good thing to make server operators aware.

  165. jonasw

    we’ve seen quite quick adoption of things since conversations compliance checker

  166. jonasw

    right

  167. Ge0rG

    jonasw: especially private PEP.

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

  169. jonasw

    Ge0rG, yes, we have. A lot of work is going into that :)

  170. Ge0rG

    you can't force server developers to do work by showing a red square on some website

  171. jonasw

    but operators

  172. marc

    Ge0rG, to solve this issue we need an "official" public server list on the (xmpp.org?) website

  173. jonasw

    to solve that problem we need massive funding for developers.

  174. marc

    which shows only servers with a special set of XEPs

  175. Ge0rG

    jonasw: how many servers are there in the compliance checker? ~120? yax.im has >1000 of s2s connections.

  176. Ge0rG

    marc: we can't even come up with that official set of XEPs.

  177. daniel

    Ge0rG: divide that number by 4

  178. daniel

    Because in and out and conferences

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

  180. Ge0rG

    daniel: `Total: 1112 outgoing, 1079 incoming connections` - not sure how many MUCs there are, but cant' imagine it's 50%

  181. marc

    Ge0rG, let me first finish my URI handling in Conversations and the user-invitation XEP ;)

  182. jonasw

    Ge0rG, depends on what you want to check, the aioxmpp end-to-end test suite might be a good start :)

  183. marc

    Ge0rG, but I think that's really important

  184. Ge0rG

    marc: what's important?

  185. marc

    Ge0rG, some official server list

  186. Ge0rG

    marc: xmpp.net had a semi-official one.

  187. Ge0rG

    but now it's down and needs work to bring up again.

  188. jonasw

    yeah, about that xmpp.net thing, Kev, I’m still hoping for your Dockerfile :)

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

  190. Kev

    jonasw: Let me sort that out now.

  191. jonasw

    Kev, that’d be lovely

  192. jonasw

    I’m tempted to sink my weekend into getting xmpp.net up&running again

  193. Ge0rG

    !praise jonasw

  194. jonasw

    (and then people wonder why jabbercat isn’t making progress)

  195. Guus

    !praise jonasw

  196. jonasw

    hold yer horser

  197. jonasw

    save the praise for when I’m done

  198. jonasw

    I might easily get fed up by PHP

  199. Kev

    What is jabbercat, BTW?

  200. Guus

    (by the way, why isn't jabbercat making progress?)

  201. jonasw

    Kev, https://github.com/jabbercat/jabbercat, TL;DR: new Qt5 Desktop Client

  202. Kev

    Because we don't have a Qt5 Desktop client already? :)

  203. Ge0rG

    it's a very promising early alpha

  204. marc

    Ge0rG, to speed things up "we" should decide how we implement PARS and user-invitation

  205. jonasw

    Kev, frankly, when I started, I didn’t know / forgot about Swift & co.

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

  207. Ge0rG

    (except for the wontfix ones)

  208. Ge0rG

    marc: let me help you with that. We integrate account creation into PARS.

  209. marc

    Ge0rG, okay, and what's the protocol flow then?

  210. Ge0rG

    marc: ad-hoc -> xmpp: URI with optional https: URI -> out-of-band -> IBR/PARS request

  211. marc

    Ge0rG, so the server generates / appends an additional PARS token if enabled?

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

  213. Ge0rG

    marc: there is no "if enabled"

  214. Ge0rG

    and there is only one token, that can be used for both

  215. Ge0rG

    No, that won't work for closed-registration servers.

  216. marc

    Yeah, that's somehow my problem ;)

  217. Kev

    Ge0rG: Nothing is optimal :)

  218. jonasw

    Ge0rG, why?

  219. Ge0rG

    jonasw: the xmpp: URI needs an indicator whether registration is allowed.

  220. jonasw

    Ge0rG, ;allow-register?

  221. marc

    Because that means that somebody may propose just an other XEP for it...

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

  223. Ge0rG

    But that will break most current clients that support xmpp:

  224. Ge0rG

    should we provide means for the server to specify a different domain from the inviter's?

  225. jonasw

    Ge0rG, will it though?

  226. marc

    Ge0rG, yes we should, I also had this idea :)

  227. Ge0rG

    jonasw: when you open an xmpp://foo.bar/user@foo.bar link, I'm pretty sure unexpected things will happen.

  228. marc

    yes, I think the XmppUri parser in Conversations is broken

  229. jonasw

    I’m pretty sure I’ll get "unknown protocol" because I don’t have an application which supports XMPP URIs at all

  230. Ge0rG

    the URI parser on android is broken as well

  231. marc

    At least it doesn't support the authority part properly AFAIK

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

  233. Ge0rG

    So we would end up with: `xmpp:georg@legacy.yax.im?preauth=TOKEN;ibr=yax.im`

  234. marc

    Ge0rG, should we really avoid using XMPP URI properly just because some clients don't implement the parser properly?

  235. Ge0rG

    marc: we are using the URI properly.

  236. Ge0rG

    marc: the primary goal of the URI is to add a contact, not to register with the server

  237. jonasw

    are we? wouldn’t xmpp://yax.im/georg@legacy.yax.im be more correct?

  238. marc

    What about xmpp://server/inviter@server;preauth=token` then?

  239. Ge0rG

    See above.

  240. marc

    I think jonasw is right

  241. Ge0rG

    marc: so your goal is to force the invitee to register with your server?

  242. marc

    Ge0rG, yes, at least it would be nice if we have an option for this use case

  243. Kev

    jonasw: How do you want this tarball?

  244. marc

    Ge0rG, because I'm pretty sure my server has nice XEPs enabled ;)

  245. jonasw

    Kev, deep fried

  246. jonasw

    Kev, mailto:jonas@wielicki.name

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

  248. jonasw

    I just wish this was all working before end of year :D

  249. Ge0rG

    marc: if you want to "entice" the receiver to re-register on a different server, I don't agree.

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

  251. Ge0rG

    marc: but in that case, the xmpp://server/inviter@server would be semantically correct.

  252. jonasw

    Kev, thank you very much

  253. marc

    Ge0rG, don't get me wrong, my intention is to make easy onboarding....

  254. jonasw

    gotta head out now for lunch, will take a look later :)

  255. Ge0rG

    marc: right. And onboarding without having to create an account is easier :P

  256. jonasw

    FWIW, marc, I think we shouldn’t encourage non-power users to have multiple accounts.

  257. Ge0rG

    what jonasw said.

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

  259. jonasw

    (hitting enter / the big button on each step)

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

  261. jonasw

    (and I think that it should be that easy to use XMPP)

  262. marc

    I agree, but to me it looks like we miss some useful feature in the XEP then

  263. Ge0rG

    marc: what would that useful feature be?

  264. marc

    Ge0rG, somebody is on a shitty server? :D

  265. Ge0rG

    marc: this is not a feature of the XEP

  266. marc

    well, it's user invitation

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

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

  269. marc

    Ge0rG, if we don't have this feature there is no way to invite a user to a non-public server

  270. Ge0rG

    marc: my point is, what if you are on a shitty server and I'm not?

  271. Ge0rG

    marc: by non-public you mean non-federated?

  272. marc

    Ge0rG, no, just a server where only registered users can invite somebody

  273. marc

    Ge0rG, I think there are some reasons to join a specific server even if an user has already an account, privacy/trust etc.

  274. Ge0rG

    marc: to invite a user to a non-federated server, the correct URI would be indeed `xmpp://server/inviter@server?ibr;preauth=TOKEN`

  275. marc

    This wouldn't be possible and IMO that's not good if we have the chance the include this

  276. marc

    Ge0rG, non-federated server is not the correct term

  277. marc

    Just because a server doesn't allow public registration it can still be federated...

  278. Ge0rG

    marc: if it allows federation, there is no need to force non-power-users to create a second account

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

  280. jonasw

    I think you two are misunderstanding eaxh other

  281. marc

    :D

  282. jonasw

    Ge0rG wants to keep the account creation, but not as default

  283. jonasw

    and away

  284. marc

    Well, I'm fine with that :)

  285. marc

    It shouldn't be the default but it should be _possible_

  286. marc

    And, maybe that's the controversal part (?!), PARS should be optional

  287. marc

    Hm, maybe that's not too important

  288. marc

    I don't know

  289. Ge0rG

    marc: why do you think PARS should be optional?

  290. marc

    Ge0rG, just thought about it

  291. marc

    Doesn't make sense

  292. Ge0rG

    marc: :)

  293. marc

    :)

  294. marc

    Okay, sounds good to me

  295. Ge0rG

    marc: anticipated UI: +-----------------------+ | Invitation from Georg | | | | JID: [georg@yax.im ] | | Name: [Georg ] | | | | [ ADD CONTACT ] | | | | [create yax.im accnt] | +-----------------------+

  296. Ge0rG

    marc: the first button is prominent, the second button is toned down, like "skip registration" would be

  297. marc

    Ge0rG, +1

  298. Flow

    Ge0rG, so JID and Name are editable text fields?

  299. Ge0rG

    Flow: the JID is visible but not editable, the name is editable

  300. Ge0rG

    Flow: one might want to add a roster group selector as well.

  301. Flow

    Hmm, how about "Invitation from Georg (georg@yaxim)" then?

  302. marc

    Ge0rG, if we agree on the possiblity of predefines usernames (optional) we're almost done :D

  303. Ge0rG

    marc: please don't.

  304. Flow

    and why is there a [create yax.im account] button?

  305. Ge0rG

    Flow: what's wrong with the above? You can reuse your regular "add contact" dialog and just disable JID editing

  306. marc

    Ge0rG, but it allows me as admin to create an account for an user

  307. marc

    As I said, optional, server-side option, maybe for admins only etc.

  308. marc

    Not useful for public servers

  309. Flow

    Ge0rG, ok, if that is the idea. But I would proably go for a specialized UI

  310. Ge0rG

    marc: if you already created an account, you should use xmpp://user@server?preauth=TOKEN

  311. Ge0rG

    Flow: [create yax.im account] is for power-users who want to have an account on the same server as the inviter.

  312. marc

    Ge0rG, well the user still has to specify the password

  313. marc

    So ibr is still correct I think

  314. Ge0rG

    marc: I think this is a completely different use case.

  315. Flow

    Ge0rG, but UX usually means to hide operating elements for power useres

  316. Ge0rG

    Flow: tell that to marc

  317. Flow

    will do

  318. marc

    :D

  319. Flow

    good thing a protocol can't require how the UI looks like

  320. Ge0rG

    Flow: actually that's a bad thing, in most cases.

  321. Flow

    Ge0rG, require or suggest? ;)

  322. Ge0rG

    Except when protocol designers try to create a UI :P

  323. Ge0rG

    But yeah, I think that hiding the account creation behind an "Advanced..." button would be good.

  324. marc

    Ge0rG, sounds good

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

  326. 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"?

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

  328. marc

    Ge0rG, yes

  329. Ge0rG

    marc: what I'm looking for is to add a contact, and to create a user-defined account if required.

  330. marc

    Ge0rG, do you really think it's worth making an extra XEP for that?

  331. Ge0rG

    marc: if you pre-created an account, you want your invitee to use that.

  332. Ge0rG

    marc: I only want to give the invitee the option to create an account themselves

  333. marc

    Ge0rG, what's the down-side of allowing this optional feature?

  334. Ge0rG

    marc: because this optional feature must be implemented by all clients

  335. marc

    okay, that's a reason

  336. Ge0rG

    marc: every time you add an option to a protocol, you double the number of possible situations

  337. marc

    But the code is very small

  338. marc

    Ge0rG, I know I've implemented it in conversations

  339. marc

    You just have to check if that's a full JID or just the server name

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

  341. marc

    In the latter case you have to fix the server name in the JID text entry

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

  343. Ge0rG

    marc: both options can share wire protocol

  344. Ge0rG

    marc: both use cases can share wire protocol

  345. marc

    yes

  346. Ge0rG

    marc: and I think they also can share an XEP

  347. marc

    Ge0rG, yes, me too that's why I'm so stubborn about it :D

  348. Ge0rG

    marc: it just doesn't make sense to map both use cases onto the same UI

  349. marc

    Ge0rG, on what side? inviter, invitee, both?

  350. Ge0rG

    marc: invitee

  351. marc

    Ge0rG, I'm fine with that

  352. Ge0rG

    marc: for the inviter, the admin use case can be mapped to some ad-hoc command without explicit client-side UI

  353. Ge0rG

    the user-inviting-user case should have a "Create invitation" UI

  354. marc

    Ge0rG, My demo showed the admin version

  355. marc

    Ge0rG, just imagine that a normal user would get the qr code directly

  356. Ge0rG

    marc: it's nice that you added the admin version into Conversatios, but that's quite some overkill

  357. marc

    Without the possibility to choose a username

  358. marc

    Ge0rG, actually that's all done automatically

  359. marc

    Because the server responds a form with the possiblity to choose a username

  360. marc

    There is no additional logic for this admin feature

  361. marc

    Since the UI is generated automatically by the form

  362. marc

    So I don't think that's overkill

  363. marc

    It's like generateUserInput(form);

  364. Ge0rG

    marc: okay, so if you are an admin, you get a data form for username / display name?

  365. marc

    Ge0rG, exactly

  366. Ge0rG

    marc: I think there is no need to XEPify that.

  367. marc

    username might still be optional but you get the possibility

  368. Ge0rG

    marc: we should XEPify the ad-hoc command name. And to a normal user, it should return a PARS;ibr link.

  369. marc

    Ge0rG, maybe not, but it would prevent user/admin defined behaviour...

  370. Ge0rG

    marc: if you are an admin, it might return a PARS;ibr link or a data form asking for a username

  371. marc

    Yes

  372. marc

    That's my idea

  373. 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`

  374. marc

    Ge0rG, looks good to me

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

  376. Ge0rG

    +; dependency on PARS

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

  378. marc

    Ge0rG, yes!

  379. Ge0rG

    There used to be an Easy_Account_Creation page on the wiki

  380. pep.

    Finally caught up with all your messages! Good to know you're getting somewhere :)

  381. marc

    :D

  382. marc

    I think we should re-use ?register action, right?

  383. pep.

    iiuc, that means as a server admin I'll be able to issue registration tokens right? and have IBR wait for that token

  384. marc

    pep., yes

  385. Ge0rG

    marc: you mean https://xmpp.org/registrar/querytypes.html#register

  386. marc

    Yes

  387. Ge0rG

    marc: do you want me to write the XEP?

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

  389. marc

    Ge0rG, we can work together on it

  390. marc

    pep., You can specify a set of people which are allowed to generate tokens or something like that

  391. pep.

    yeah

  392. marc

    But that really depends on your service

  393. Ge0rG

    pep.: you could disable generic IBR and use this mechanism to allow all your users to invite other users.

  394. marc

    exactly

  395. pep.

    Ge0rG, I guess I could. Or have a blacklist rather than whitelist

  396. Ge0rG

    pep.: how is that supposed to work?

  397. Ge0rG

    marc: there is also https://xmpp.org/extensions/attic/xep-0235-0.3.html

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

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

  400. Ge0rG

    Eh, https://xmpp.org/extensions/xep-0235.html

  401. Ge0rG

    marc: I think that is absolutely out-of-scope

  402. pep.

    They'd be able to generate tokens etc.

  403. pep.

    You can traceback where it came from though

  404. marc

    Ge0rG, we should at least define an error for that

  405. Ge0rG

    pep.: right, one could easily kick the spammer and all of their friends.

  406. marc

    Ge0rG, nothing is more annyoing to a user if you get something like "doesn't work at the moment, try again later!"

  407. Ge0rG

    marc: I'm sure we can re-use existing IBR errors

  408. marc

    Ge0rG, I mean for token/invitation generation

  409. Ge0rG

    And there is https://xmpp.org/extensions/inbox/user-auth.html

  410. Ge0rG

    marc: the ad-hoc command should always return a token, just maybe not with an `ibr` tag.

  411. marc

    Ge0rG, that would be confusing ;)

  412. Ge0rG

    marc: to whom?

  413. Ge0rG

    marc: the default use case is to generate a PARS uri

  414. Ge0rG

    marc: if you are talking of the admin use case, yes, it should return an error.

  415. marc

    sometimes you have the ability to create an account sometime not?

  416. marc

    +s

  417. Ge0rG

    marc: for the user use case, the server generates a PARS or a PARS;ibr link

  418. Ge0rG

    marc: depending on whether user-initiated account creation is allowed on the server.

  419. Ge0rG

    marc: a non-ibr PARS link will mean that the invitee's client is responsible for account creation

  420. marc

    Ge0rG, just thought about the case where an inviter creates too much PARS;ibr tokens

  421. marc

    Maybe you want some policy to limit the number of PARS;ibr tokens

  422. Ge0rG

    marc: maybe. But there is no need to expose that to the inviter's client

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

  424. marc

    Ge0rG, maybe I don't get your idea but this is how I understood your approach

  425. Ge0rG

    marc: (2) Marc invites somebody without account -> server generates PARS only -> invitee opens link in yaxim and registers on yax.im -> nice

  426. marc

    Ge0rG, sounds like a bad idea to me... not every client provides a xmpp server?

  427. Ge0rG

    marc: no, but the ones implementing PARS do :P

  428. jonasw

    for now

  429. marc

    Ge0rG, Does PARS require a client software to provide a xmpp server?

  430. Ge0rG

    marc: actually, I forgot to add that part to the XEP

  431. marc

    Ge0rG, :p

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

  433. jonasw

    Ge0rG, so jabbercat better doesn’t implement PARS

  434. Ge0rG

    marc: it doesn't mean the client developer must run an IBR server, they can provide a list of public servers instead

  435. jonasw

    (I won’t get into the business of running a public server.)

  436. jonasw

    ah well

  437. Ge0rG

    jonasw: you can SRV-link jabbercat.im to the yaxim server :P

  438. marc

    :>

  439. marc

    Ge0rG, okay, I think I'm okay with your idea

  440. jonasw

    Ge0rG, will do

  441. Ge0rG

    jonasw: I'm pretty sure I can handle the additional load

  442. Ge0rG

    jonasw: btw, did you buy out jabber.cat already? :P

  443. jonasw

    no, won’t

  444. jonasw

    too politically unstable that TLD ;-)

  445. Ge0rG

    Heh.

  446. Ge0rG

    Still better than .io

  447. marc

    Although it may be very confusing if that happens to invitees who sit next to each, for example ^^

  448. jonasw

    does im have DNSSEC by now?

  449. Ge0rG

    jonasw: nope

  450. jonasw

    m(

  451. Ge0rG

    marc: why so?

  452. marc

    Ge0rG, because they don't get the same dialog

  453. marc

    Ge0rG, invitee A an create an account on the server and invitee B can choose some public server

  454. jonasw

    Ge0rG, but then I want private+persistent PEP on jabbercat.im!

  455. Ge0rG

    jonasw: please star & comment on https://prosody.im/issues/485

  456. jonasw

    I won’t comment, Zash hates that

  457. jonasw

    (rightfully so)

  458. jonasw

    > PEP with permanent storage is now in mod_pep_plus and should be working. Thanks to Link Mauve!

  459. pep.

    Yeah, that's in trunk

  460. Ge0rG

    > Is this feature usable with 0.10? *crickets*

  461. pep.

    0.10, pff :)

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

  463. edhelas

    once the user login it automatically ask him to add the MUC to the bookmarks and join

  464. edhelas

    it's a bit like Discords in doing

  465. Ge0rG

    edhelas: web-based stuff is easier

  466. edhelas

    yup

  467. jonasw

    I want that MUC invite integration thing

  468. Ge0rG

    edhelas: can you make it work with PARS and easy-xmpp-invitation? :P

  469. edhelas

    dunno

  470. Ge0rG

    "Timothée Jaussoinhat Sie eingeladen, einen Chatraum zu bet..." - the UI is cut off.

  471. Guus

    That's what you get for inventing such long words in your language!

  472. Guus

    shees, you're almost as bad as the Finnish!

  473. edhelas

    there's never enough place to display german messages

  474. pep.

    it's also cut off in english

  475. Guus

    oh. :)

  476. jonasw

    Guus, don’t insult the finnish

  477. Ge0rG

    edhelas: which is why German is a good UI testing language.

  478. jonasw

    they’ve got the most amazing language on this continent

  479. jonasw

    yeah, long words and long sentences :)

  480. jonasw

    and umlauts!

  481. edhelas

    they beat all of us at the Scrabble

  482. pep.

    edhelas, where is that in the UI btw? Where do I generate that

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

  484. 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_.

  485. jonasw

    :)

  486. jonasw

    that’s how amazing it is!

  487. edhelas

    pep. in a chatroom, click Menu > Invite

  488. pep.

    nice

  489. 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!

  490. Ge0rG

    Should the ad-hoc command node be a human-readable short string or a unique identifier / URL?

  491. jonasw

    the latter

  492. jonasw

    there’s a separate name field thing

  493. jonasw

    cf. https://xmpp.org/extensions/xep-0050.html#retrieve

  494. Ge0rG

    prosody is using URLs as node names, the XEP is using short identifiers.

  495. Ge0rG

    I'm not talking about the 'name' field but about 'node'

  496. jonasw

    URLs is probably safest

  497. jonasw

    me too

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

  499. jonasw

    yup

  500. Ge0rG

    So for the sake of implementing an invitation ad-hoc-command, it should be a URL as well? Hmhm.

  501. jonasw

    one could probably re-use the URI the XEP will allocate

  502. Ge0rG

    you mean the XEP html URI?

  503. jonasw

    no

  504. jonasw

    urn:xmpp:fancy-invite-xep:0:fnord

  505. jonasw

    urn:xmpp:fancy-invite-xep:0:command

  506. Ge0rG

    ah, yes.

  507. marc

    Ge0rG, are you writing the XEP atm?

  508. Ge0rG

    marc: not yet. Should I?

  509. marc

    Ge0rG, Just asking because your question regarding ad-hoc command

  510. Ge0rG

    marc: I was looking into what's needed to write that XEP

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

  512. jonasw

    fix things!

  513. Ge0rG

    Fixed. Looks good.

  514. Ge0rG

    Meh. Why is there no non-shady barcode scanner app that works in portrait mode?

  515. jonasw

    mine switches; is that important?

  516. Ge0rG

    yes, if you want to screen-record.

  517. Ge0rG

    especially since the launcher locks to portrait mode.

  518. pep.

    Ge0rG, marc, what are you going for in the end, improving PARS to include that use case, or another XEP?

  519. Ge0rG

    pep.: probably both

  520. pep.

    I'm filing a bug against dino for IBR and PARS

  521. marc

    pep., you mean regular IBR?

  522. pep.

    0077 yeah, at least, they don't have it apparently, from the quick search I did

  523. Ge0rG

    marc: https://op-co.de/tmp/easy-onboarding.mp4 (2.5MB)

  524. Ge0rG

    marc: https://op-co.de/tmp/easy-onboarding.mp4 (2.5MB; broken IPv6)

  525. marc

    Ge0rG, nice!

  526. marc

    You already have a "parkedtextview"

  527. pep.

    Ge0rG, I feel that "Register a new account" check might be one check too many

  528. marc

    I searched one for Conversations

  529. marc

    pep., Indeed

  530. pep.

    Ge0rG, mind you I don't want to force the account creation on that server

  531. pep.

    Just talking UX wise

  532. Ge0rG

    marc: what's a parkedtextview?

  533. Ge0rG

    pep.: the usual approach is two buttons: "[login] [create]"

  534. marc

    A textview where you have a fixed text at the end (e.g. @example.com)

  535. Ge0rG

    marc: it's not parked, it's smart.

  536. Ge0rG

    marc: wait, I'll show you.

  537. marc

    Ge0rG, I found a textview on GitHub that promised to do that and it was called "ParkedTextView"

  538. marc

    I don't know if that's the correct term :D

  539. Ge0rG

    marc: https://op-co.de/tmp/autocomplete-jid.mp4

  540. Ge0rG

    marc: https://github.com/pfleidi/yaxim/blob/master/src/org/yaxim/androidclient/widget/AutoCompleteJidEdit.java

  541. Ge0rG

    marc: and if you tap into the hostname part, it will make it editable as well.

  542. pep.

    Ge0rG, who do I pay to appear in your server list?

  543. marc

    Ge0rG, that's nice! It is also possible to fix the domain part?

  544. Ge0rG

    pep.: PR against https://github.com/pfleidi/yaxim/blob/master/res/values/servers.xml

  545. Ge0rG

    marc: nope, not supported yet

  546. marc

    pep., In a perfect world this server list would be download from a server list provided by XSF or something like that

  547. marc

    +ed

  548. mathieui

    marc, in a perfect world we would have no need for xmpp

  549. pep.

    Ge0rG, k

  550. pep.

    mathieui, you mean everybody would be using WhatsApp?

  551. 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`

  552. pep.

    Ge0rG, and then you tested for IBR?

  553. Ge0rG

    pep.: no.

  554. marc

    Ge0rG, easy onboarding!!1! :D

  555. Ge0rG

    pep.: it's a generic public-server list for JID auto-completion, I don't have IBR flags.

  556. pep.

    I'm curious what would get included in the list

  557. marc

    We really need a good server list... :D

  558. Ge0rG

    marc: we need a list with meta-data, like hosting country, privacy regulations, ToS-TLDR, reliability, and of course a fancy logo.

  559. Ge0rG

    The logo is the most important part, people don't care about the others.

  560. marc

    Ge0rG, if meta-data includes XEPs, yes

  561. SouL

    +1 for the logo

  562. pep.

    Ge0rG, agreed, a server-list like that would be nice

  563. Ge0rG

    marc: there was some discussion on standards@ regarding that.

  564. Ge0rG

    Probably around a year ago

  565. marc

    Yes, we need a badge and a list for public server which support all XEPs required for mobile devices, HTTP upload, OMEMO, etc.

  566. Ge0rG

    marc: you just volunteered.

  567. pep.

    marc, OMEMO is a client-side thing

  568. pep.

    well, PEP ~

  569. marc

    pep., No, it needs PEP

  570. pep.

    Sure

  571. Ge0rG

    The PARS proposal that daniel made also needs PEP. Private PEP

  572. marc

    Ge0rG, what's that?

  573. marc

    I mean the PARS proposal

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

  575. pep.

    I'm not sure I understand how that would work

  576. jonasw

    Ge0rG, your broken IPv6 is annoying

  577. jonasw

    mpv is now at more than a minute for trying to connect to your server

  578. jonasw

    can you please remove the AAAA records

  579. daniel

    Ge0rG, will it also be able to validate pokemon go tokens?

  580. pep.

    jonasw, yeah same, I resorted for wget / mpv instead :/

  581. pep.

    jonasw, yeah same, I resorted to wget / mpv instead :/

  582. jonasw

    finally

  583. jonasw

    oh no

  584. jonasw

    ah yes

  585. jonasw

    Ge0rG, hm, somehow the firs t screen seems cluttered

  586. jonasw

    is it possible to show *only* the dialogue without the othert suff in the background?

  587. jonasw

    is it possible to show *only* the dialogue without the other stuff in the background?

  588. Ge0rG

    jonasw: you will find bliss in RFC 6555

  589. pep.

    happy eyeball?

  590. jonasw

    Ge0rG, yeah, but I can’t make that magically happen

  591. pep.

    heh

  592. Ge0rG

    jonasw: the first screen of yaxim? the account creation one?

  593. jonasw

    yes

  594. Ge0rG

    jonasw: do what I would do. https://github.com/dino/dino/issues/208

  595. jonasw

    that is, make the dialogue full screen. what’s that called in android?

  596. jonasw

    Ge0rG, I don’t even know which component is at fault here

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

  598. Ge0rG

    jonasw: probably it's mpv

  599. Ge0rG

    youtube-dl -4, --force-ipv4 Make all connections via IPv4

  600. jonasw

    mpv didn’t accept -4

  601. jonasw

    also, ECHAN

  602. mathieui

    https://gateway.ipfs.io/ipns/QmSgwwdejjsizQnKffKo6e84vfvBWCH5tnGpAwLPJVvhby/ if any german people are available, it may be interesting

  603. zinid

    ipfs never works 😉

  604. Alex

    he guys, lets start the member meeting in 2 minutes

  605. Zash

    Feels like we just had this, with the board/council not too long ago :)

  606. Alex bangs the gavel

  607. Alex

    here is our Agenda for today: https://wiki.xmpp.org/web/Meeting-Minutes-2017-12-08

  608. mathieui

    Alex, it’s supposed to be at 20:00 UTC ?

  609. mathieui

    it’s 19:00 right now

  610. Alex

    then I put it wrong in teh Cal ;-)

  611. mathieui

    right, wiki says 19:00 but latest members mailing says 20:00

  612. Zash

    19:05 even!

  613. Alex

    lets do it now, as I have to leave soon, when there are no concerns

  614. Ge0rG

    What if there are members wanting to vote at 20:00?

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

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

  617. Zash

    SamWhited: Last minute proxy-bot-votes happen tho

  618. Zash

    Altho if the original original announcement said yesterday then everyone should have voted already, so ..

  619. SamWhited

    Does it ever actually come down to one or two votes then? Why try to fix it until it's a problem?

  620. Alex

    SamWhited agreed, lets continue

  621. Zash

    Go for it

  622. Alex

    1) Call for Quorum

  623. Alex

    as you can see 34 members voted via memberbot, so we have a quorum

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

  625. Alex

    3) Opportunity for XSF Members to Vote in the Meeting

  626. Alex

    anybody here who wants to vote now?

  627. Alex

    memberbot would be still up for that

  628. Alex

    ok, will start working on the results then

  629. Zash

    In case anyone had wanted to, but showed up at the announced time, then it'd be a bit weird.

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

  631. Alex

    4) Announcement of Voting Results

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

  633. Alex

    all new and returning members are accepted

  634. Ge0rG

    Congratulations, everybody!

  635. Ge0rG

    🎆

  636. mathieui

    Congratulations to all returning members and pep.

  637. Alex

    5) Any Other Business?

  638. Alex

    looks like there is none

  639. Alex

    6) Formal Adjournment

  640. Alex

    I motion that we adjourn

  641. mathieui

    seconded

  642. Alex bangs the gavel

  643. Alex

    thanks guys

  644. SamWhited

    Thanks alex; and congrats all!

  645. mathieui

    thanks for the work, as always, Alex

  646. 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:

  647. SamWhited

    https://i.imgur.com/3jykNf1.png

  648. pep.

    I'm interested in hearing about the 4 No votes, ping me in private if you want to talk about it

  649. Alex

    and sorry about the time confustion. I work in too many different timezones these days ;-)

  650. Alex

    pep.: maybe related to the short application, at least this is some kind of pattern I have seen in the past

  651. pep.

    Ok

  652. Ge0rG

    SamWhited: what kind of console is that? Maybe you need Smiley Hugification™

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

  654. Ge0rG

    weird indeed.

  655. lovetox

    pep. i like you, just wanted to put it out there.

  656. pep.

    lovetox: 😘

  657. SouL

    Congratulations everyone, and also pep. !

  658. Zash

    Bunneh: draft uta-email-deep

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

  660. Zash

    2014 called, or something

  661. Ge0rG

    Zash: it was 2014 for Jabber, and that was already a decade late

  662. Zash

    Better late than never?

  663. Ge0rG

    Yeah, right

  664. Ge0rG

    Oh, that rfc is for MUA access to servers. They are really a decade late

  665. moparisthebest

    interesting they chose the term 'Implicit TLS'

  666. moparisthebest

    we settled on 'Direct TLS' for 368

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

  668. moparisthebest

    but I'm excited it's going back to recommended status :)

  669. moparisthebest

    if that reaches draft can we bring back implicit 5223 also ? :D