vanitasvitaeHm, I got something of a dejavu from last year 😀
GuusLast year, my first TWO trains got cancelled
GuusEhhh... The lights just went out in the train that I'm in now.
GuusIt's still moving though 🤨
jonas’good morning, summiteers
jonas’I’m ready to join remotely once the party starts
flowvanitasvitae, Holger: have a safe trip :)
vanitasvitaeHah, train is delayed by 10 minutes due to snow and ice :D
vanitasvitaeI knew it. flow thanks :)
ZashSnow, in winter? Completely unexpected!
pep.Ugh, soo early
GuusGlobal warming is a scam!
jonas’itym a SCAM
vanitasvitaeThe cisco train station was called Diegem, right?
jonas’vanitasvitae, from the data in this room, I think that’s true. somebody claimed that a train to Diegem is a good t hing, also the address Guus gave in the email contains Diegem
HolgerLanded. Someone else happen to be at the airport?
GuusIn half an hour
GuusZaventem, that is.
vanitasvitaeHm, if all goes to plan I'll arrive at 10:13 in Diegem
Syndacepep., Zash, Link Mauve: We already left to the train station
pep.Syndace: here we are!
pep.We'll catch up
ralphmGood morning all!
ralphmHaving breakfast with Alex
HolgerWe landed in time but now can't leave the plain. Gate somehow b0rked.
GuusHolger: you out? I'm about to arrive (but will have to get through security)
GuusWe can share a cab
TobiasJust a reminder for folks at Thon. Some of us are meeting up around 0910 in the lobby to take the train from Schuman to Diegem.
HolgerGuus: Got off the plain now, but I guess it'll take me 20 minutes to get to the busses.
HolgerPlus I need to get a coffee and tickets.
GuusLet's share a cab, which is faster
GuusI can do coffee 😁
GuusWhere are you at? I'm near the escalators, second floor
GuusThere's a Java Coffee House here
jjrhAnyone at Cisco yet?
DanielWe are about 10-15 minutes away
HolgerGuus: Close to the 'info' desk now.
GuusUnsure where that is. I'll stand still and show off my XMPP hoody. 😀
HolgerGuus: I'd like to get tickets for Saturday/Sunday, because here I know how it works (IIRC you don't get the same 'airport tickets' everywhere in town). But sharing a cab then sounds good.
jjrhI'm just chilling by the cafe past reception
HolgerDownstairs at the ticket thing now.
GuusHolger: what level?
HolgerBack at 2 now, looking for you 🙂
DanielWe are here
jonas’could the folks already there try to figure out what’s needed for webex?
ZashSo, what's the wifi?
alameyoI'll be a bit late 😣
jonas’Zash, if I read the mail from Guus correctly, there’s a list with wifi accounts somewhere, possibly at the reception?
jonas’> A printed list of wifi accounts will be available. As I'm not sure how
> often an account can be re-used, please cross off the account that you used
> from the printed list (or risk suffering intermittent disconnects).
KevIt's a list on his phone, currently doing the rounds.
Seve/SouLHave a good Summit friends!
jonas’apparently I didn’t buy enough cisco:
> Video is not currently available due to low bandwidth or local computer conditions (such as CPU or RAM use). Video will resume automatically when conditions improve.
Ge0rGjonas’: for the other phone numbers, you need to leave the conf and select the option from "Connect Audio"
jonas’Ge0rG, the other phone numbers won’t get me audio
jonas’Ge0rG, the other phone numbers won’t get me video
jonas’audio works fine here
jonas’a bit quiet, but that’s probably the input material
jonas’I just must not hit play on my audio player, otherwise I’ll be deaf.
edhelasgoffi did you already talked about MUC Avatars, if yes, is it about https://xmpp.org/extensions/inbox/muc-avatars.html ?
goffiedhelas: yes we did quickly, we went to the conclusion that it must be used with PEP (PEP from the MUC room jid)
goffiLink Mauve: will do a PR on XEP-0045 about that
goffiLink Mauve will do a PR on XEP-0045 about that
edhelasI'm really interested about 2FA in XMPP and would be open to implement it in Movim :)
goffiedhelas: are you following the stream ?
jonas’edhelas, when you want something you say "reposted" (said out loud) in the physical room, ping Tobias :)
edhelasgoffi I am but I cannot talk where I am
edhelasjonas’ okay, thanks
Guuskingu: I'm kind of confused. Are you interested in joining the XSF summit, that started earlier today?
ralphmFor anyone interested in buying the new XMPP hoodies, please go to xmpp:firstname.lastname@example.org?join.
edhelasfor 2FA what I miss is the setup project through XMPP, Tobias can you ask if it's planned and how they implemented that ? should we use ad-hoc to return the QR-Code for Google Authenticator for example ?
jonas’Tobias, raise hand
jonas’Tobias, raise hand again
Link MauveZash, could that be used for providing multiple SCRAM mechanisms?
ZashLink Mauve: wat
Link MauveThe SASL2 thing.
ZashWhy can't you already?
pep.(yeah that involves thinking a bit)
TobiasLink Mauve, SASL can already provide multiple mechanisms, not?
jonas’don’t make me laugh, I have a cold!!k
Link MauveSo, before authentication you can’t know who is going to authenticate.
Link MauveIf you provide multiple SCRAM mechanisms, say SCRAM-SHA-1 and SCRAM-SHA-256, the user could pick any.
Link MauveWhile they only have one stored.
ZashIs there a failure+try this instead?
Tobiasyou mean where different users have different SASL mechanisms available to them
Link MauveFor instance yeah, without mandatory password changes you will have a transition period when upgrading from one mechanism to another.
Link MauveA per-user transition period.
jonas’Link Mauve, I don’t think that works safely unless the server can convincinly fake that it supported the first mechansim you tried (because user enumeration)
jonas’and even then it’s probably not safe
jonas’it would have to make the client do both mechansims while convincinly faking that it knows the right values, which is not something you can do in SCRAM
jonas’where does SASL2 save a roundtrip, by the way?
Tobiasjonas’, ask dwd
jonas’I was hoping someone here knows so that I don’t have to disturb the physical room :)
jonas’because it’s probably obvious and I’m just missing it because I haven’t read the spec closely
GuusIs someone talking to kingu privately? I'm not getting responses. We're happy for him to join us at Cisco's.
ralphmjonas’: ICYMI, the answer is that SASL2 doesn't require a stream restart
jonas’I don’t know what "ICYMI", but the question has been adequately answered :)
flowFeels like a missing oppourtinity if Bind2 would require SASL2…
ralphmIn Case You Missed It
ralphmflow: not really clear to me why
flowralphm, why it is a missed opportunity? Because it prevents ppl from implementing bind2 standalone, while I don't see an argument for Bind2 to require SASL2
jonas’who’s the person with the deep voice discussing with kev on unreads?
flowjonas’, MattJ I think
ralphmflow: deployment of this stuff might take a while. I think requiring them together makes this less painful.
jonas’very different from what I imagined your voice to be, MattJ (not that I can accurately describe how I imagine a voice)
flowralphm, I don't think I aggree. In fact I think it increases the implementation burden if ppl not only need to implement Bind2 but also SASL2
MattJjonas’, it's probably very different to how I imagine it too
flowjonas’, I am pretty sure MattJ had a differnt voice 2 years ago
flowralphm, especially since it is trival to make Bind2 and SASL2 work independently from each other
jonas’I tend to agree with flow
flowjonas’, always good to know that there are people who also share that view. I had the impression that the majority of the room's participants did not listen/care
Tobiasjonas’ means http://logs.xmpp.org/xsf/2018-02-12/#16:14:23
mathieuiwhat about having clients already generating unique ids having something in their disco saying that they do it, and let the server rewrite the ids for clients that don’t do it?
Ge0rGI'm still "hearing" audio over the phone, but the quality is... sub-par
pep.Can you still hear us?
SyndaceOkay we back bois
Ge0rGre deliberate duplication:
With my black hat on, I can't really make that assumption. I think that from the stated business rules, some trusted entity (read: each server and each MUC / MIX) will have to keep a list of "known" @id values for a sufficiently long time to reject duplicates.
jonas’Tobias, this time really my hand
Tobiasdwd, where is that HMAC id generation described? some mail to standards ML?
Ge0rGat least the chat logs don't randomly change the web archive URL
jonas’or rather the IQ point raised by flow
Tobiasjonas’, it's up
TobiasGe0rG, there are several things discussed there. how are these ids defined now?
Tobiasis it hmac(secret=streamid, content=session management counter)?
Ge0rGTobias: yeah. I think the HMAC(stream-id, stanza counter) idea was brought up to make it impossible for other entities to predict the @id
Ge0rGIt'll be lovely if you have enqueued a message into SM, but then your stream breaks down, you can't resume and you need to reconnect and start from scratch
jonas’I mean, I’d probably introduce an id attribute to my StanzaToken class (which is used to track a stanza through the outbound queue) and allow converting the StanzaToken to a string implicitly once an ID was assigned to the stanza.
jonas’(and raise otherwise)
jonas’that would get safe behaviour without having to explicitly handle dependencies
flowI become more and more sceptical of the HMAC approach…
MattJflow, I'm going the other direction. It seems more and more appealing, after all the id mess we currently have
MattJThere is no perfect solution, but this one seems to have pretty good properties
Ge0rGjonas’: does the supporting server need to keep a mapping of incoming-ids to proper-ids, and rewrite all id references on the s2s boundary?
flowMattJ, I maybe missing something about the exact nature of the id mess
winfriedI am really worried about the sequence of the stanza's with HMAC / the send queue, it feels very wobly (seen too many race conditions)
jonas’Ge0rG, I’d say we don’t do rewrites and let things break
Ge0rGwinfried: let the send queue class return the generated id when you enqueue a stanza
jonas’winfried, you need to have a strict ordering on your stream for stream management anyways
jonas’if you have a race there, the stanza ID thing will make it more apparent, but you need to fix it anyways
winfriedjonas’: fair point, "lets brake broken clients big way" ;-)
ralphmFWIW, I don't know what happened to the WebEx camera feed.
flowGe0rG, racy, because I want to setup the listener before enquing
pep.I think we should have the summit chat displayed on a screen, just like the cameras (fail to correctly) focus people speaking
flowbut now I have to wait for the enque to get the id for the listener
Ge0rGflow: pass the listener (not a filter) to the sendMessage() function
flowbut yeah, it would work with a bigger lock, but you increase your critical section touhg
Ge0rGflow: "critical section" reminds me of that fugly smack4 race condition bug where it's interleaving multiple stanzas with each other.
flowI could get along with the HMAC thing if we wouldn't use the sm height
Ge0rGflow: with your counterproposal being?
MattJflow, I think we moved from SM to a simple per-client counter
flowGe0rG, dunno, add the integer into the stanza as extension element?
Ge0rGI'm really against using a long-term client identifier for the HMAC
flowMattJ, ok, not sure if I understand, I'll ask you to explain it later to me (preferably in person)
jonas’Ge0rG, everyone is
jonas’MattJ, huh, I thought we agreed that a per-client counter is not workable?
Ge0rGjonas’: phew. My audio is really garbled, so I'm only trying to connect puzzle pieces
MattJjonas’, did we?
MattJYou highlighted it as a potential issue, I don't think we concluded that made it unusable?
jonas’MattJ, well, you’d have to persist a counter reliably. on each stanza sent/acked. or you transfer it on login, but hm.
jonas’I mean, in the end, you still have to deal with broken reconnects because you can’t know for sure what arrived before resuming
jonas’and then you’d have to recalculate IDs of queued stanzas
flowI lean towards server assigned IDs…
MattJNot in the per-client, right?
jonas’MattJ, in the per-client case, too
Ge0rGflow: what's wrong with server-assigned client-predictable HMAC ids?
MattJjonas’, why would the id change between reconnects? (unless you reorder stanzas)
ZashErrors and iq replies needing to be excluded from the counter thing is weird.
flowI could be wrong but all aruments against are nil. Could someone please make wiki page listing the pros and cons of the different approaches?
jonas’MattJ, when stream management is not resumable
jonas’then it’s tricky
MattJjonas’, stream management is not involved with a per-client id
jonas’MattJ, but the ID is effectively a cross-stream stanza counter
Zashstream id, sm id, client id, so many ids!
jonas’I’m too distracted by the room audio, let’s take this to a wiki or discussion later, I think that’s better.
flowGe0rG, nothing I guess, please write a strawman
jonas’flow, you were arguing against them a second ago
flowjonas’, I don't think I did, I was arguing against client-generated server-verifyable IDs using the SM height I think
jonas’flow, server-generated client-predictable HMAC-IDs would do the same
jonas’except that the client doesn’t *have* to put it in the @id, the server will do it if it’s missing
Ge0rGthe best thing about HMAC-IDs is that it will finally make both clients and servers fix their SM counters
flowok, I think I have an idea how entities can still generate server verifyable unique IDs at the same time they do generate the IDs right now
Ge0rGbecause these are still getting desynced
Ge0rGflow: by pulling a queue number for each stanza?
goffiis there any open source up-to-date server implementation of MIX?
Tobiasthere is an out of date one for openfire
jonas’and thank you very much for doing the remote hands here :)
goffiyes I know for OpenFire, that's why I've specified "up-to-date" ;)
jonas’I think daniel triggered a partial implementation in ejabberd
goffino independant component? It would help spread it if we are not tied to a server.
MattJgoffi, unfortunately the design of MIX requires server support on the user's account
MattJMaybe it could be done with component delegation, not sure
goffiMattJ: for which reason (haven't checked the spec for a while)
goffiyes I was about saying that, or privileged entity
flowgoffi, mainly because your server needs to know which MIXes you joined
flowsimilar to what PAM does for PubSub
goffiok, it's probably doable with delegation then.
goffiI would love to give it a try if I had time, but I've not :'(
edhelaskeep in mind that MIX is not only to replace MUC for some people
edhelasmy goal is to publish Atom items into MIX nodes
edhelasmaybe next to simple messages
edhelas0060 is also a bit like 0045 :p
TobiasZash, scoped = when referencing via ID you are actually referencing sender bare JID + that ID
Ge0rG0333, 0367 and 0372 won't scope by sender JID in MUCs
jonas’Tobias, hand please
Ge0rGluckily, sending 0184 into a MUC is madness
ZashIt's scoped on full JID now tho?
Tobiasi understood kev that he meant on bare
jonas’that isn’t correct in MUC
Ge0rGbare JID scoping is acceptable outside of MUCs, because if a user attacks their own clients, it's still clearly scoped.
flowSecretary: Jonas owes Tobias a new hand
ZashMUC with MIX protocol?
jonas’Tobias, raise hand please
mathieuiZash, what about MIC?
Ge0rGjonas’: thank you so much for saying this!
Ge0rGwhere's my "told you so" stamp? :D
jonas’Ge0rG, you’re welcome ;-)
Tobiasjonas’, could you make sure that your point is mentioned in the etherpad mentioned in the subject? I missed some of it