XSF Discussion - 2018-01-05


  1. Flow

    jonasw, i've just discussed with ge0rg that entity caps would need a push mechanism for the service's ver attribute because the server may enable a feature dynamically at runtime. I'm not sure if this is something for xep390

  2. Ge0rG

    there is the implicit assumption that stream features / server caps don't change over the lifetime of a connection.

  3. Ge0rG

    I suppose the server could send a presence unavailable from the service domain, containing the caps hash.

  4. Flow

    hmm, my first though was to use a message for the push

  5. Ge0rG

    Flow: entity caps is using presence everywhere. If you have a presence listener anyway, it would just get reused

  6. Flow

    good point, but i'm not sure if this justifies

  7. Flow

    reusing presence

  8. Ge0rG

    We could just invent a new nonza.

  9. Zash

    Whut

  10. Flow

    that only causes trouble when using stream resumption

  11. Flow

    or maybe not since the features are announced early

  12. Ge0rG

    </s>

  13. Zash

    Features are still things attached to potentially remote entities, right?

  14. Zash

    So you want notifications to be routable stanzas.

  15. Flow

    Zash, so you also think that the service should use an unavailable presence as xep115/390 push?

  16. Zash

    Flow: Huh?

  17. pep.

    Could this be used for stuff like pubsub services?

  18. Flow

    pep, not really, a remote service doesn't know that you are using it, so we would need a way to register for caps updates

  19. pep.

    I know edhelas was interested in having sth similar to caps for that

  20. Flow

    which seems a little but to much for a problem that hasn't been a problem since xep115 exists

  21. Ge0rG

    just send out presence pushes to all entities that ever asked for your caps :P

  22. Flow

    Ge0rG, for all eternity?

  23. pep.

    As querying a service with thousands if nodes can be quite heavy

  24. Zash

    Flow: I'm probably missing tons of context here

  25. Ge0rG

    while we are at it, there is no caching for disco#items.

  26. Flow

    Zash, I don't think so, it's really just "what if your service gets a new feature at runtime"

  27. Ge0rG

    Zash: context is: a client wants to cache its server's entity caps, but those can change when modules get (un)loaded

  28. Flow

    (which isn't really a practical problem)

  29. Flow

    Ge0rG, like client's caching disco#items?

  30. Zash

    disco-sub!

  31. Ge0rG

    Flow: there are rather static and more dynamic disco#items...

  32. Ge0rG

    The typical flow is: 1) query domain for disco#items 2) iterate over each item's disco#info

  33. Flow

    Ge0rG, true

  34. Ge0rG

    maybe adding the caps into disco#items would already prove sufficient, as we can't skip 1 anyway

  35. Flow

    Ge0rG, that doesn't sound like a bad idea

  36. Ge0rG

    I'm full of good ideas. Implementation is what matters :P

  37. Flow

    only problem is that xep30 has a "<item/> SHOULD be empty"

  38. Ge0rG

    just add a new attribute to item :P

  39. Flow

    but the schema!

  40. Ge0rG

    unknown attributes must be ignored?

  41. Flow

    says who?

  42. Flow

    (not saying that isn't what I'm doing)

  43. Ge0rG

    general consensus

  44. marc

    Ge0rG, I'm pondering if we should skip account creation on this XEP for simplicity and make an own XEP (with a reference to this one) later. What do you think?

  45. pep.

    Depends on how strict you want your parser. I know often it helps fond bugs when you are

  46. pep.

    find*

  47. Ge0rG

    marc: that's what I was telling you in the beginning :P

  48. marc

    Ge0rG, no, you had the idea to combine PARS and my account creation becaus they are similar :p

  49. Ge0rG

    marc: if we skip account creation out, we can just rewrite PARS to be a server-side adhoc command triggered thing, and add the `ibr` flag to the spec for servers supporting that.

  50. Ge0rG

    marc: but honestly, I've seen multiple situations in the past where the account creation flow would make sense.

  51. marc

    Ge0rG, :D

  52. marc

    Okay, let's keep it then?

  53. Ge0rG

    marc: I wouldn't even mind putting both use cases into PARS.

  54. marc

    hm, doesn't fit the name PARS IMO

  55. marc

    at least account creation

  56. Ge0rG

    marc: good point.

  57. Ge0rG

    marc: I suppose renaming PARS into "Easy Onboarding" would be counter-productive. Some nerds already know what "PARS" stands for.

  58. Ge0rG

    jonasw: being the editor, is there prior case law, or do you consider it a good idea to rename an XEP when its scope shifts?

  59. Kev

    I'd expect Council to be involved in the shifting of scope, at least.

  60. Kev

    One can't really get Council to accept an Experimental XEP for one purpose, and then change the purpose of the XEP.

  61. Ge0rG

    Kev: okay, so we have PARS. And we want to extend it to carry a flag that the token may also be used for IBR. And then we further want to extend it to allow "account sharing" where an admin sends a link to friends to easily onboard them.

  62. Ge0rG

    They are using the same wire format

  63. Ge0rG

    And are all belonging to "Easy Onboarding"

  64. Kev

    That doesn't seem to be particularly changing the scope much.

  65. Ge0rG

    Kev: it's not "Pre-Authenticated Roster Subscription" any more, but rather "Pre-Authenticated User Onboarding"

  66. Kev

    Yeah.

  67. Ge0rG

    so it's not changing the purpose, but still shifting the focus

  68. Kev

    This isn't particularly ringing alarm bells for me.

  69. pep.

    PARS -> PAUO, hmm

  70. pep.

    I preferred the first name Ge0rG :p

  71. Ge0rG

    pep.: me too. Will need to come up with a new catchy backronym first.

  72. pep.

    And the discussion about caps ended

  73. Ge0rG

    marc: so have you written down anything yesterday?

  74. marc

    Ge0rG, no, not anything. What's the plan now? New XEP, re-using PARS XEP?

  75. Ge0rG

    marc: I'm ambivalent about leaving account-creation in or out.

  76. Ge0rG

    marc: maybe a new "Easy Onboarding" XEP is better suited.

  77. Ge0rG

    or maybe... dunno

  78. Ge0rG lacks coffee

  79. marc

    Ge0rG, a new XEP for user invitation and account creation as is?

  80. Ge0rG

    marc: there are three user stories I see as relevant: 1) explicit account sharing --> uses PARS-style URI with token and custom IBR payload <xmpp://invitee@domain?register;preauth=XXX> 2) roster invitation with IBR to somebody without an account --> uses the IBR wire format from #1, server auto-enrosters user 3) roster invitation with IBR to somebody with existing account --> uses PARS as is

  81. Ge0rG

    #2 and #3 share the <xmpp:inviter@domain?add;preauth=XXX;ibr> URI

  82. Ge0rG

    we could make three XEPs: PARS, a new XEP for account-sharing + the new IBR payload, a new "Easy Onboarding" XEP bringing them all together

  83. Ge0rG

    or just two XEPs: PARS and a new one for everything else.

  84. Ge0rG

    or stick everything into PARS, because there is so much overlap between #1 and #2 and between #2 and #3

  85. marc

    Ge0rG, I agree but I don't know what's the best solution regarding XEP(s) for it

  86. Ge0rG

    From a symmetry perspective, #1 and PARS are similar to each other as they are building blocks that can be combined in #2

  87. Ge0rG

    so it wouldn't make much sense to have PARS separate, but not IBR+

  88. marc

    Ge0rG: So, a new XEP for account creation and user invitation as already planned?

  89. Ge0rG

    marc: no

  90. Ge0rG

    marc: after some more pondering I'd say we need exactly one new XEP.

  91. marc

    Ge0rG, and what's the content of this new XEP?

  92. Ge0rG

    marc: a description of the two use cases and how a receiving client should handle them, the wire protocol for IBR+token and a reference to PARS

  93. marc

    Ge0rG, two use cases = account creation & user invitation?

  94. Ge0rG

    marc: right

  95. Ge0rG

    marc: there is really no need to distinguish between #2 and #3 from yesterday's discussion

  96. marc

    Ge0rG, -> no "ibr" parameter?

  97. Ge0rG

    marc: account creation --> `xmpp://newuser@domain?register;preauth=XXX` user invitation --> `xmpp:inviter@domain?roster;preauth=XXX;ibr`

  98. marc

    Ge0rG, wtf, we discussed 2h regarding the action parameter and you didn't like it and now you have "?roster"? :D

  99. Ge0rG

    marc: account creation --> `xmpp://newuser@domain?register;preauth=XXX` user invitation --> `xmpp:inviter@domain?;preauth=XXX;ibr`

  100. marc

    :D

  101. marc

    And no "?;" please :)

  102. Ge0rG

    marc: for some reason I used ?roster in one place in 0379, but not in the other places.

  103. Ge0rG

    ?; = empty action, not to be confused with: ?: = elvis operator

  104. marc

    "?;" doesn't make sense IMO, we discussed it already ;)

  105. marc

    Ge0rG, well, for PARS-only the "?roster" action makes sense, doesn't it?

  106. marc

    Not not in combination with "ibr", I thought that's what came out last time we discussed the action parameter stuff

  107. marc

    s/Not/But

  108. Ge0rG

    marc: generally speaking, the ?roster action doesn't make any sense, ever.

  109. marc

    Ge0rG, okay, you should update your XEP then

  110. Ge0rG

    marc: we should update 0147

  111. Ge0rG

    except nobody cared about it two years ago.

  112. marc

    Ge0rG, I would mention server-side PARS in the new XEP and make a reference to the PARS XEP, okay?

  113. marc

    For server-side PARS the server returns the normal PARS URI

  114. Ge0rG

    marc: for server-side PARS, the server returns either a normal PARS URI or one with `ibr` flag.

  115. Ge0rG

    I don't know if the ibr flag needs to have a value, though.

  116. Ge0rG

    URI parsing is a art.

  117. marc

    Not really :)

  118. marc

    Ge0rG, a value?

  119. marc

    Like "ibr=" ?

  120. Ge0rG

    marc: like `ibr=1`

  121. Ge0rG

    because an empty value is not much more than no value at all

  122. marc

    No

  123. marc

    Empty values are fine

  124. marc

    See action parameters :D

  125. Ge0rG

    marc: no, there is actually a problem here. https://tools.ietf.org/html/rfc5122#section-2.2 Only allows the query type (i.e. action) to be valueless

  126. Ge0rG

    query parameters need to have an "=" between key and value, albeit the value might be empty

  127. Ge0rG

    furhermore, xmpp://domain/ is invalid

  128. marc

    Okay, that's all XMPP URI related :-/

  129. marc

    But that means we need an action type

  130. marc

    At least one "iquerytype"

  131. marc

    Well, exactly one "iquerytype"

  132. Ge0rG

    marc: iquerytype may be empty, leading us back to ?;

  133. marc

    This URI definition is really shitty...

  134. Ge0rG

    marc: it never was designed for what we are doing with it now.

  135. Ge0rG

    We could have `xmpp:inviter@domain?preauth=XXX;ibr=YYY` but I don't want to add a second token for the sake of adding a second token.

  136. Ge0rG

    especially as other applications will want to append crpyto keys and then render everything as a QR code

  137. marc

    You forgot "?;"

  138. marc

    Ugly as hell...

  139. Ge0rG

    marc: yeah, ?preauth is a violation already.

  140. marc

    Ge0rG, fix your XEP then :D

  141. Ge0rG

    marc: to what? `?;`?

  142. marc

    Yes :>

  143. Ge0rG

    Can do, I suppose. Let's hope my parser won't crash on that

  144. marc

    Or we change the RFC :D

  145. Ge0rG

    Muhahaha!

  146. Ge0rG

    Sorry.

  147. Ge0rG

    > This document extends the "roster" URI action defined in XEP-0147 with a new key-value parameter named "preauth" to store the generated token. So maybe it's action=roster after all?

  148. marc

    Ge0rG, ?action=roster;preauth=TOKEN ?

  149. Ge0rG

    marc: no, `?roster;preauth=TOKEN`

  150. Ge0rG

    marc: I the action string is `roster`

  151. marc

    Now we're at the beginning :D

  152. Ge0rG

    marc: not at all

  153. marc

    Ge0rG, we discussed the action stuff already and got to the point where we both agreed that we don't want the "roster" action :)

  154. Ge0rG

    marc: yes, but then I reread https://xmpp.org/extensions/xep-0379.html#link_generation and realized it's the missing link

  155. marc

    And now you're convinced that we should use ?roster ?

  156. Ge0rG

    marc: I'm now more indifferent to using `roster` or ``

  157. marc

    Ge0rG, I would use "roster" for optical reason :D

  158. SamWhited

    I've got a meeting later to (hopefully) convince work to book me a ticket to FOSDEM; we have cheap-ish flights from here to Frankfurt, Amsterdam, and probably a few other places. Anyone on that side of the pond know where it's easiest/cheapest to catch a train to the summit/FOSDEM so I can give work some rough price estimates?

  159. SamWhited

    (flying to Brussels directly is way more expensive for whatever reason)

  160. Ge0rG

    SamWhited: probably more expensive because of EU administration

  161. mathieui

    fyi tickets from paris were fairly cheap last time I looked

  162. SamWhited

    That would probably be a good option too; I think flying there is relatively cheap

  163. mathieui

    amsterdam-brussels looks like ~50€

  164. Ge0rG

    SamWhited: a one direction train ride FFM-Brussels is ~3hrs and 70-125€, depending on rate

  165. mathieui

    SamWhited, https://www.trainline.eu/ has most regional prices for western europe

  166. mathieui

    damn, the price of the train tickets doubled since two weeks ago

  167. SamWhited

    I should book this soon… I hate coordinating trips like this.

  168. remko

    SamWhited: AFAIK, there should be belgian trains from amsterdam, but not frankfurt.

  169. remko

    SamWhited: Belgian trains are www.belgianrail.be

  170. SamWhited

    Yah, looks like I'd have to go to Cologne and transfer if I did FRA

  171. SamWhited

    AMS looks the cheapest overall anyways though; or I could be super cheap and take a bus from there.

  172. remko

    there are also trains to cologne, yes

  173. SamWhited

    Although I wouldn't mind accidentally getting stuck for a day or two in Paris on my way back if I were to do that… and it's not much more expensive

  174. Ge0rG

    German trains are pretty expensive, though

  175. remko

    the train to cologne is belgian

  176. SamWhited

    Actually, I wouldn't mind exploring Amsterdam either, so I guess either would be fine

  177. daniel

    SamWhited: there is also one from Frankfurt Main station to Brussels. Not sure if that's better than transferring in Cologne though

  178. remko

    but yeah, getting from frankfurt to there might be expensive

  179. SamWhited

    daniel: I think that one was more expensive, let me pull it up again

  180. SamWhited

    yah, roughly twice the price

  181. Ge0rG

    bus from FRA to Brussels would be ~20€

  182. mathieui

    yeah but like 10 hours or something?

  183. Ge0rG

    not sure you want to have a 6-7hr trip though.

  184. SamWhited

    yah, if I'm doing the bus I'm doing FRA

  185. SamWhited

    err, AMS

  186. SamWhited

    too many airports

  187. Ge0rG

    Why can't we route XSF participants via XMPP?

  188. Ge0rG

    Why can't we route XSF Summit participants via XMPP?

  189. Kev

    I've just realised it's quicker (by a margin) for me to fly Cardiff to Amsterdam and Amsterdam to Brussels than to go to Brussels by train.

  190. remko

    SamWhited: Frankfurt is also twice as far away from brussels than amsterdam. So Paris, Brussels, Amsterdam, Eindhoven are your best bets for airports.

  191. jjrh

    Can one remotely attend the XSF fosdem?

  192. remko

    Kev: including waiting time in airports?

  193. Kev

    Seems to.

  194. Ge0rG

    jjrh: yes, there's Cisco WebEx.

  195. SamWhited

    Train ride time doesn't count, because I'm 5 and riding trains is the best (maybe it wears off if you live somewhere that actually has reasonable trains though)

  196. remko

    there's also ecological footprint to bear in mind ;)

  197. edhelas

    for https://xmpp.org/extensions/xep-0157.html is it possible to put MUC as well ? I'd like to put our chatroom for support-addresses

  198. jjrh

    Awesome (minus the webex part)

  199. mathieui

    SamWhited, don’t forget to add like 10-15€ for paris tickets though (it’s stupidly expensive)

  200. SamWhited

    *nods* I'm not actually sure if they'd care about that, but I figured I might as well give them the lowest prices I can find while trying to convince them

  201. Kev

    TBH, the worst part of the trip back is usually getting up early and getting to the station, which would be no better (actually worse) getting to the airport instead.

  202. Kev

    I usually leave the hotel 'early' and get back home late afternoon.

  203. Ge0rG

    edhelas: "This contact information may include email addresses, web URLs, and JabberIDs" - I see no reason not to give a MUC with "?join"

  204. remko

    Kev: and more stress. Flying is always more stress, and less legroom :)

  205. mathieui

    yeah, that

  206. mathieui

    more stress, more processes and lineups, and less legroom

  207. mathieui

    (and expensive water)

  208. Kev

    This is all getting close. I probably have to start thinking seriously about booking stuff next week. Do we have venues and hotels arranged yet?

  209. Ge0rG probably had some 20.000km of train rides last year. That does wear off.

  210. SamWhited

    Flying's not so bad if you're not in the U.S., but I still hate it. Trains I can find a table, order food, and have a surface to put my laptop on

  211. daniel

    Train prices are unpredictable unfortunately. I'm paying 22 Euro for Dresden Brussels. That's 700km and a 9 hour train ride by high speed train

  212. jjrh

    SamWhited, flying in Canada is still a crappy experience.

  213. remko

    i was expecting the IC option from amsterdam to be cheapest, but apparently, the high speed train is cheaper

  214. remko

    so yeah, very unpredictable

  215. mathieui

    well, still more predictable than planes

  216. edhelas

    Ge0rG yeah I though the same

  217. Ge0rG

    edhelas: I'm actually pondering about doing the same for yax.im.

  218. edhelas

    https://github.com/movim/movim/issues/490#issuecomment-355592163

  219. Ge0rG

    edhelas: you could just display the link and reuse xmpp: linkification

  220. daniel

    If you are into trains you should take the FRA - Cologne - Brussels trains instead of FRA - Frankfurt central - Brussels. Because the FRA - Cologne section is one of the few sections where the high speed trains actually reach their top speed. And the FRA train station is amazing. It's predominantly severed by high speed trains and just seeing the trains enter the station is amazing in itself.

  221. SamWhited

    that's tempting me to do that instead of AMS

  222. remko

    on the other hand, in amsterdam, you can legally get cannabis :)

  223. remko

    you know, the other kind of trainspotting

  224. SamWhited

    I see what you did there…

  225. daniel

    remko: I don't think that's a good argument these days for Americans

  226. SamWhited

    In Austin it's "illegal", but also invisible to cops, which is very convenient

  227. SamWhited

    But yah, that's what Colorado is for

  228. Kev

    There's no good argument for Americans.

  229. Kev

    Oh, right, I see what you mean.

  230. SamWhited

    *snort* it's true

  231. moparisthebest

    my only question is if it's invisible to cops, if you wrap something in it, does that become invisible too?

  232. SamWhited

    Tentatively added myself to the summit list since I'm reasonably sure I can convince work with this. Hotel is still a problem until we know what the group discount is though.

  233. Kev

    Do we have a hotel sorted, then?

  234. Kev heads off to the wiki

  235. SamWhited

    not as far as I know, that's always the problem for me. Work wants to book early and at the same time I book a flight, but hotel isn't done until a week or so before

  236. Zash

    That is the question

  237. SamWhited

    And by "always" I mean "last year and this year"

  238. daniel

    Kev: according to my logs Guus signed something and sent it over but is still waiting to hear back from them

  239. Kev

    SamWhited: Yeah, it wasn't always this way.

  240. daniel

    That's a lot entry from the 28th though

  241. Kev

    Oh, yes, wiki says it's the Thon again.

  242. Ge0rG

    daniel: I don't think you get to go through Frankfurt main station if you are going from the airport to Cologne

  243. daniel

    Ge0rG: I was talking about the airport station (FRA)

  244. Ge0rG

    daniel: ah, alright then. Don't have special memories about that one, though the Frankfurt skyline is rather impressive.

  245. Ge0rG

    But yeah, FRA->Cologne is the track where you can actually go 300km/h

  246. daniel

    Ge0rG: I guess you are not into trains then 😀

  247. Ge0rG

    daniel: as I said, I'm travelling around 20k km per year by train ;)

  248. daniel

    And as far as skylines are concerned I prefer the ride into Cologne. Less pretentious 😀

  249. SamWhited

    Cologne is less pretentious? That's impressive

  250. Ge0rG

    SamWhited: frankfurt is full of bankster skyscrapers, cologne has a rather classic appeal

  251. daniel

    I'm from Cologne I should say

  252. daniel

    So there might be some bias

  253. SamWhited

    Yah, but Cologne is known for Eau de Cologne, and nothing is more pretentious than that!

  254. SamWhited

    Some SCAM person may want to try and put us on this list: https://fosdem.org/2018/fringe/

  255. SamWhited

    Which I just found out was a thing

  256. Kev

    Maybe. It's not clear that it would be good to do so, at least to me.

  257. Kev

    If we assume that anyone actively involved in the community already knows about the summit, that means someone finding us on Fringe is someone not actively involved. If they're an active XMPP person who just happens to be outside the community, them knowing about the Summit might be great.

  258. Kev

    But if they're a person with a bit of an interest and wants to come along to find out what we're about, the Summit might not be an inviting place for them.

  259. Kev

    Lots of strong opinions, very technical discussions, sometimes getting a bit heated, with little time for someone to get up to speed on what's going on.

  260. Kev

    5 minutes at the stand at FOSDEM would probably be better outreach for them.

  261. Kev

    Your milage may reasonably vary :)

  262. SamWhited

    I would assume that new people who don't know anything about XMPP wouldn't read that page with a description on it and then decide to go (and if they did they'd know what they were getting into)

  263. SamWhited

    And if they don't, it doesn't stop most people who won't go from seeing the booth

  264. Kev

    I realise you can reasonably make the argument that it's good to put us there. I don't agree, but this isn't a thing where I'm clearly right and you're clearly wrong :)

  265. pep.

    Is this up-to-date? https://wiki.xmpp.org/web/XSF_Infrastructure Some services are using docker now right? And systems on the machines seem particularly old