XSF Discussion - 2018-01-05

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

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

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

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

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

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

reusing presence

We could just invent a new nonza.

Whut

that only causes trouble when using stream resumption

or maybe not since the features are announced early

</s>

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

So you want notifications to be routable stanzas.

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

Flow: Huh?

Could this be used for stuff like pubsub services?

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

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

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

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

Ge0rG, for all eternity?

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

Flow: I'm probably missing tons of context here

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

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

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

(which isn't really a practical problem)

Ge0rG, like client's caching disco#items?

disco-sub!

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

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

Ge0rG, true

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

Ge0rG, that doesn't sound like a bad idea

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

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

just add a new attribute to item :P

but the schema!

unknown attributes must be ignored?

says who?

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

general consensus

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?

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

find*

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

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

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.

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

Ge0rG, :D

Okay, let's keep it then?

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

hm, doesn't fit the name PARS IMO

at least account creation

marc: good point.

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

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?

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

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

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.

They are using the same wire format

And are all belonging to "Easy Onboarding"

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

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

Yeah.

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

This isn't particularly ringing alarm bells for me.

PARS -> PAUO, hmm

I preferred the first name Ge0rG :p

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

And the discussion about caps ended

marc: so have you written down anything yesterday?

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

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

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

or maybe... dunno

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

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

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

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

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

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

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

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

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

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

marc: no

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

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

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

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

marc: right

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

Ge0rG, -> no "ibr" parameter?

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

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

:D

And no "?;" please :)

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

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

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

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

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

s/Not/But

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

Ge0rG, okay, you should update your XEP then

marc: we should update 0147

except nobody cared about it two years ago.

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

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

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

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

URI parsing is a art.

Not really :)

Ge0rG, a value?

Like "ibr=" ?

marc: like `ibr=1`

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

No

Empty values are fine

See action parameters :D

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

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

furhermore, xmpp://domain/ is invalid

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

But that means we need an action type

At least one "iquerytype"

Well, exactly one "iquerytype"

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

This URI definition is really shitty...

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

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.

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

You forgot "?;"

Ugly as hell...

marc: yeah, ?preauth is a violation already.

Ge0rG, fix your XEP then :D

marc: to what? `?;`?

Yes :>

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

Or we change the RFC :D

Muhahaha!

Sorry.

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

Ge0rG, ?action=roster;preauth=TOKEN ?

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

marc: I the action string is `roster`

Now we're at the beginning :D

marc: not at all

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

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

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

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

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

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?

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

SamWhited: probably more expensive because of EU administration

fyi tickets from paris were fairly cheap last time I looked

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

amsterdam-brussels looks like ~50€

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

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

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

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

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

SamWhited: Belgian trains are www.belgianrail.be

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

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

there are also trains to cologne, yes

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

German trains are pretty expensive, though

the train to cologne is belgian

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

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

but yeah, getting from frankfurt to there might be expensive

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

yah, roughly twice the price

bus from FRA to Brussels would be ~20€

yeah but like 10 hours or something?

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

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

err, AMS

too many airports

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

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.

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

Can one remotely attend the XSF fosdem?

Kev: including waiting time in airports?

Seems to.

jjrh: yes, there's Cisco WebEx.

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)

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

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

Awesome (minus the webex part)

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

*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

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.

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

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

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

yeah, that

more stress, more processes and lineups, and less legroom

(and expensive water)

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?

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

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

SamWhited, flying in Canada is still a crappy experience.

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

so yeah, very unpredictable

well, still more predictable than planes

Ge0rG yeah I though the same

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

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

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

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.

that's tempting me to do that instead of AMS

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

you know, the other kind of trainspotting

I see what you did there…

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

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

But yah, that's what Colorado is for

There's no good argument for Americans.

Oh, right, I see what you mean.

*snort* it's true

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

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.

Do we have a hotel sorted, then?

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

That is the question

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

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

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

That's a lot entry from the 28th though

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

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

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

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

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

Ge0rG: I guess you are not into trains then 😀

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

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

Cologne is less pretentious? That's impressive

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

I'm from Cologne I should say

So there might be some bias

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

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

Which I just found out was a thing

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

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.

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.

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.

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

Your milage may reasonably vary :)

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)

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

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

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