XSF Discussion - 2018-01-31

moparisthebest, no, attic has no XMLs

scratch that idea then

moparisthebest, FYI, CoAP is a UDP binary HTTP-ish thing; can be used over DTLS (TLS for UDP). used for IoT stuff.

Acronym galore!

let's reject XEP-0368 for the drama!

zinid: we've had enough drama for this year already.

Ge0rG, okay

😅

what drama? it's mainly trying to get IANA to do IANA stuff

IANA is too busy to add records for that marginal protocol XMP-wtf

I'd think XMPP is more widely used than CoAP or managesieve

> The primary reason for introducing CoAP over TCP [RFC0793] and TLS [RFC5246] is that some networks do not forward UDP packets. Complete blocking of UDP happens in between about 2% and 4% of terrestrial access networks, according to [EK2016].

UDP isn't used by any serious protocol anyway.

serious = HTTP or JSON based

zinid, lol

they do coap over tcp now

that’s funny

Ge0rG, QUIC?

Flow: accelerate the Internet!

when did council switch?

was it before 2017-11-28 or after?

AFAICT first session of new council was 2017-11-29, is that correct?

Hi. Could someone kill the s2s between gultsch.de and muc.xmpp.org? It's stuck again. (I think it happens when I switch certs?) thanks

cc @ intosi maybe?

I'll take a look.

And like I said the last four times this happened. It's not urgent and you can leave it stuck if that helps you debug the issue and I will do everything in my power to help

MattJ, maybe?

I'm trying to get the informational protoxep covering 'xmpp 2' stuff out before the summit, but it's getting tight, BTW.

or Zash

Writing on the train at the moment.

Will xmpp2 fix the s2s stuck issue?

Kev, I’ll be happy to do some editing if that helps

(i.e. do some more proof-reading than usual ;-))

Ge0rG: Possibly not :)

jonasw: Ta. I think if I get anything out, it'll be useful.

Although Georg's slide stack is fairly thorough, I'd like us to have something in (proto)XEP form.

derdaniel: try again, please :)

Kev: I still don't understand your reasons for that, but I'm not going to stop you

s2s:close("muc.xmpp.org", "gultsch.de"); | Closed outgoing session from muc.xmpp.org to gultsch.de | OK: Closed 1 s2s session | Result: nil s2s:close("gultsch.de", "muc.xmpp.org") | Closed 1 incoming session from gultsch.de to muc.xmpp.org | OK: Closed 1 s2s session

Ge0rG: I'm trying to produce suggested ways of addressing things too :)

intosi: 👍

Plus, I think doing things in the context of a XEP helps (it means the IP picture is clear, etc.).

Kev: so you are not documenting what's broken but writing proto-protocol to fix it? That's great :)

lovely :)

I'm not trying to just duplicate the slides in XEP form, no.

Kev: now I'm really interested in what you propose

Nothing revolutionary.

FWIW, even though I’m not going to be at summit, I’ll still be online to do editor tasks if needed.

I hope the WebEx doesn't fail

jonasw: Thanks.

Ge0rG: And me, I want you to give this presentation.

Although, if it does fail, do you mind if I give a poor-man's approximation of your presentation?

(Well, I'll do that anyway, it's a question of whether I could steal your slides)

Kev: not at all. I hope that the points are sufficiently self-describing for you to present

Even for an idiot like me :)

power-point karaoke

ha

jonasw: Musical chairs with power-point. When the music stops, whoever is still standing has to present the next slide.

ha

I'm saying that now, and I've an awful feeling it's probably something someone has already done, somewhere, somewhen.

power-point karaoke is actually a thing. you get a random slidedeck and need to make sense of it, for the amusement of the audience

I remember a ppt karaoke session with Dan Kaminsky at some CCC congress, a decade ago. It was just hilarious.

if you’re lucky, you get a really obscure slidedeck about brainfuck and happen to know something about brainfuck, but if you’re unlucky, it is about porous stones and you’re like what

Ge0rG: was a called a power point karaoke or was it one of his actual talks?

Kev: if you need any deeper content in anticipation of evil audience questions on that slide deck, feel free to let me know.

daniel: it was an official powerpoint karaoke session, and Dan was "volunteered"

Ta. I did send a sub request to you, but you ignored it ;)

Kev: I'm sorry, it's well possible that it got lost amidst dozens of spammer JIDs awaiting my approval.

brilliant, as soon as I press send, I spot a glaring typo.

Kev: you should have used PARS

Kev: but feel free to re-request now.

It was only a half hour or so ago.

I'll do so now.

power-point karaoke actually sounds really fun; after a few beers I imagine that would be hilarious.

SamWhited, it is

even without beers :)

Oh, wait, maybe this is my fault and yax.im isn't whitelisted on isode.com

Kev: I do have a mutual subscription with a JID that matches yours on the XSF application.

Yeah, I'm only using my work account while I'm travelling.

Kev: and you are playing Unknown title - Unknown artist.

As time is running out (apologies for the delay), I'm cross-posting this invitation for _you_ to attend the XSF Dinner 2018 in a couple of places. Please help me spread the word! If you're interested in joining us, please RSVP by fill out a short form at https://goo.gl/forms/vgzWXyiRo5ne43yX2 but do so today!

> and yax.im isn't whitelisted on isode.com Because federation isn't a thing.

Dame Blanche doesn't have a translation this year :(

Ge0rG: It was a sledgehammer approach to stopping spam. It's effective in that respect, but has unfortunate sideeffects.

Kev: there should be a way to auto-whitelist JIDs on outgoing traffic to them.

That sounds sensible.

reverse-XEP-0191

(As was pointed out elsewhere, the form didn't include the dinner date/time originally - it now does: it's Tomorrow, at 8.)

What time will Summit start?

10 IIRC

We'll start at 10.

tz?

CET?

local time, so yeah, CET.

so 09:00Z

That sounds like I can make it in time, and even have some coffee first.

Excellent

Guus: do we get a copy of the form send to us?

is there a plan when lunch break will be?

Or do I need to take a picture of the screen?

maybe I can sync my lunch break :)

Daniel, you should get a copy by mail (but if you can confirm that for me, that'd be great)

jonasw: we will have lunch at the venue itself, but haven't explicitly defined a time for that. When most people grow hungry, I suppose.

Guus: i got a confirmation mail.

Guus: I got it on members@ and summit@

Guus, okay

Ge0rG: "Need for ephemeral all-online-clients routing (Bare-JID + <no-archive/>?)" I'm not sure about this. I think that if it went to all clients, it should go in the archive. Else you have issues with resync due to momentary disconnects.

Kev: I could imagine that as useful for (some?) CSNs

Possibly. But then you fall into the trap of inconsistent views, don't you?

Kev, for "typing" and "stopped typing" it doesn’t matter (a lot), and that just pollutes the archive

active and inactive makes sense to keep

I have a somewhat contentious suggestion here, but I don't know if I'm brave enough to make it.

Thanks Kev. Sam, you surely didn't get the confirmation mail on the mailinglist?!

Kev: be brave!

While we are at presence spam... > iqvxh3d3s@xmpp.tips wants to subscribe to your presence, ...

Seems legit.

Kev, be brave!

"Special server handling"

Guus, "RSVP before 7PM UTC (5PM Brussels time)" I’m pretty sure this is incorrect

but that might be the glaring typo you spoke about

I'm thinking more of deliver/read receipts here than CSN, in the first instance.

that’d be either 4PM UTC or 8PM brussels time

But what if you get your server to handle the message metadata, instead of clients doing the collation?

Kev, that’d be great

jonasw: the glaring typo was in the subject, but you're right, that's also a mistake.

that's what I get for rushing things at the last moment. Again, apologies.

Kev: +1 to that

Kev, that’d be great, but maybe quite a large step for now?

Well, 'for now' is kinda nebulous here.

Kev: ask daniel about sending delivery receipts on MAM catch-up

Client collation of historical delivery receipts is painful at best. Even ignoring the traffic impact.

I've just had another evil and contentious thought.

CSN aren't messages, they're presence.

Kev: except when they are used as read markers

Ge0rG, are you confusing CSN and Chat Markers?

CSN can’t be used as read markers AFAIK

Guus: yes got the confirmation.

Ge0rG: did I mention I'm doing this now. Even though the XEPs forbids this. I'm such a bad person

daniel: you are doing what now?

Sending 184 on mam catchup

Only if there isn't one in mam already of course

daniel: I think we talked about it some days ago. Or maybe it was jonasw telling me how your logic works?

I’m pretty sure that the XEP doesn’t intend to forbid that

jonasw: CSN can be used as an activity marker.

Ge0rG, but that’s not read

Kev: if we redefine CSN in terms of presence, we _might_ get rid of ephemeral-message-to-all-devices.

hmm

presence’ getting large

don't forget to inject avatars and caps²

Transport csn in directed presence ?

Kev, but then we’re getting in directed-presence semantics when you send CSN to specific contacts, don’t we?

That somehow makes sense

I’d be worried about that

I mean, yes, it makes sense

but we’d have to look closely at the sematics involved in sending directed presence to people

jonasw: what's wrong with directed presence?

Ge0rG, I’m not 100% sure, but that would break broadcast of global presence changes, wouldn’t it?

As far as I can see, CSN in directed presence would work, and makes lots of things better.

So, my current strawman is that we move CSN to directed presence, we have the server handle receipts as special data, and that way we avoid (I think) ephemeral bare-JID messages.

Ge0rG, if I send you directed presence with CSN, would my subsequent global presence change to away (a) not be broadcasted to you or (b) break the CSN I sent you before?

Kev, I love it

if it actually works :)

Kev: we might be able to come up with other use-cases for ephemeral bare-JID messages, if we think about it hard enough.

Maybe. But it's not clear to me that we can't also solve them.

Is there any good reading material on bare-JID messages somewhere? Because in my head all user generated messages should be bare-JID and all server generated messsages should be directed but I am probably missing a lot of use-cases.

What I'm trying to avoid is special-casing such that some messages don't hit the archive and some do.

SaltyBones, file transfers are usually to full jid

SaltyBones: Georg's slide deck is online somewhere, I think. Ge0rG?

(if they’re happening in-band)

SaltyBones, Kev: https://op-co.de/tmp/whats-wrong-with-xmpp-2017.pdf

jonasw, maybe we don't need to discuss this here but: why?

Ta muchly.

Please reload, forgot to refresh the PDF export.

SaltyBones, I don’t think it makes sense to broadcast a file to all clients by default.

SaltyBones, think memory use, battery use etc. on mobiles

Ge0rG, 208-01-30.00 :)

Is that the room it's in? :)

SaltyBones: perfect

Sorry, gotta go now.

jonasw: No, it doesn't make sense to broadcast it to any clients by default, but to hold it on the server until a client wants it :)

jonasw, they don't have to accept it but how would the user chose which client to send it to? It's usually transparent to him what the contact is doing with his devices...

Maybe opaque not transparent. :p

SaltyBones, offering is different from actually transferring the file

once one client accepted the offer, you wouldn’t want to send your file to *all* clients

you’d negotiate a transport with that client, and if the transport is in-band, you’d use messages to the full jid

(to avoid other clients getting spammed with a transfer they didn’t accept)

Ah, I see. So the client sends directed even though the user only sent bare-JID.

maybe

Okay, I see maybe the distinction should be automatic

vs interactive

yes, users should of course never touch full JIDs

if anything, they should touch a list of clients of the peer, with their disco identities

but no full jIDs

Yeah, and even that I would strongly oppose. :)

Guus: oh, sorry, I thought you were looking for confirmation that the survey went out

SamWhited: 👍

Everyone, please read Guus' e-mail and fill in the XSF Dinner form therein.

Dinner update: I've just been in contact with the restaurant. If people would like to have a vegetarian dinner, that'll be possible. Some of the menu items are vegetarian (or will be slightly modified to be vegetarian). For a main course, there can be a pasta. If you're interested in a vegatarian option, please add that as a comment to the form (and tell the waiter tomorrow, when ordering)

And there's always the option of A Tomato.

to consume, or to throw?

Guus: there's a history there.

This is not helpful rendering, but here's a very rough preview of my xmpp2 thoughts - https://www.dropbox.com/s/pkcbdwpxivg41gp/multi-client.html?dl=0

"not helpful" is quite an understatement

I'm sure everyone can read HTML.

Kev, you're getting awefully close to that guy from the Matrix. "All I see is blonde, red head"

(apart from the fact that that's the guy that ends up killing everyone, obviously)

spoilers!!k

some day, I’ll set up a web service which renders github PRs against the xep repository...

(fun fact, I initially spelled "red head" as "redhat")

All I see is Debian, Red Hat...

This MUC gets better and better each day hah

SouL, until somebody complains about too much off-topic

then we go back to xmpp@ ;-)

\o/

jonasw: That happens to every group chat ever

Zash, true

except to off-topic groupchats

jonasw: can you un-archive https://trello.com/c/8arSL8aD/2-vote-on-moving-xep-0368-to-draft

Still waiting on iana

Hey that sounds like a good song title

moparisthebest, done

Thanks

Reminder: As time is running out (apologies for the delay), I'm cross-posting this invitation for _you_ to attend the XSF Dinner 2018 in a couple of places. Please help me spread the word! If you're interested in joining us, please RSVP by fill out a short form at https://goo.gl/forms/vgzWXyiRo5ne43yX2 but do so today!

Guus, maybe highlight all people in the participants list by their nickname here?

I'll do that as a last resort :)

hmmm

the earlier they know the better?

Seems xmpp.net is "too busy" quite often?

Can happen.

I still think there’s a bug with the queue manager there

But not being able to submit any domains is perhaps a bit rich :)

jonasw: very likely.

I didn’t get the debug logs I asked for a few weeks ago and I didn’t have time to persue it since then

Did you ask for debug logs?

Ok. I'll wait with shutting down check.messaging.one then.

intosi, I asked for somebody to lend me a hand for gathering information, yeah

weeks ago, probably last year

Where did you ask?

Should be running again, FWIW.

intosi, iteam@

intosi, specifically MR 20171215T10:36:44Z 000 <jonasw>  can somebody take a look at the logs, we seem to have a stuck queue again

so yeah, several weeks, last year :)

but then there were the holidays etc and I kinda lost track

is this that issue again where malformed characters cause the queue processing to stagnate?

that was a weird one

maybe

I might have a clue why that happens.

that’d be great

Normally a client does disco#items on its service domain to find MUCs, File Upload and other nifty services. However, it is possible to have things like File Upload on the service domain. How is a client supposed to find out?

Disco info the domain first

To see if it even supports disco#items

Zash: what if it doesn't support either?

And the account itself too

Disco#info all the things

Roundtrips all the way

Ge0rG: what if?

Zash: what if what.

What if whatif what

Ge0rG: What if what don't support what ?

Zash: what if the service domain doesn't support disco#info

Ge0rG: Then it's broken

yeah

Zash: so you want to tell me disco#info is mandatory and disco#items is optional?

it's kind of a basic feature

And probably won't support disco#items either

yup

Ge0rG: Yes

So I'm supposed to disco#info my service domain, then to disco#items it, then to disco#info each item.

At least I think so

But if I disco#info my service domain, I'm not doing it in a code path where I'm collecting features, only checking for disco#items support

Ge0rG: Or do both kinds in parallel, and live with the possibility of an error

Do I need to disco#items each of the items of my service domain's disco#items?

It's disco#items all the way down!

I assume you want some limit

Zash: do I?

Ge0rG, if you want to support that, it's what you have to do

Tobias: I don't want to. Do I _have_ to?

Ge0rG: You don't have to do anything

If you want to discover a File Upload component that hides some levels down

you don't have to support that

I'd probably not go further than 1 or 2 levels down and stop there

My question is: is a client supposed to discover a File Upload on it's direct service domain?

Survey time?

Ge0rG: Same as with proxy65

Zash: can you un-redirect that answer, please?

Nothing about those require a separate domain

Soooo....

You as a client dev will want to support both setups

Both exist in the wild

I think I moved all the file transfer helpers to my main domain, yes

Zash: you are not the person I was talking of.

Well, still

"You received a message encrypted with OMEMO but your client doesnt support OMEMO." *sigh*

monar, Hantu.sc, bg, Dwisnewski, Holger, MattJ (and Ethan), michalwski: if you want to join us at dinner tomorrow, please RSVP at https://goo.gl/forms/vgzWXyiRo5ne43yX2 - do so today please!

(as well as anyone else that feels like joining)

I wish I could

Anyone who wants the vegetarian option: mention it in the notes at the bottom of the form.

Ge0rG, are you hungry?

zinid: yes

I'm too stingy.

Ge0rG could borrow me his member pass.

I could pretend to be Ge0rG.

Holger: are you attending?

Holger, just always say that we need XMPP2.0

Ge0rG: Yeah.

zinid: :-)

We are all Ge0rG on this blessed day

Holger: I wouldn't mind you taking my position at the Dinner, if this is okay with the Org.

Zash: in that case you need to wear a black fedora hat and politely troll everyone.

Ge0rG, you are not coming?

SaltyBones: no

That's a bit disappointing.

Ge0rG: Actual fedora ?

Ge0rG: That's nice thanks, but I was just kidding. I'll meet jabber.at-Mati and we'll search for a French fries stand :-)

Belgium fries.

Zash: it looks like the one worn by Indiana Jones, except it's black.

I pretend to be a Black Hat.

Holger: last time I attended Summit, another XSF member (I wasn't one at the time) invited me to the dinner but then couldn't come for personal reasons.

"he tricked me into coming and then left me on my own."

For what it's worth: although I appreciate the guesture - and would like to have Holger there - I'd try to avoid allowing people to trade places with non-members. That'll start to raise eyebrows fast.

Guus: alright

obviously, everyone is welcome, but I suggest with stick with who's paying for what as defined: the XSF will pick up the tab for members and sponsors only.

Guus: this is a very understandable position

Guus: Sure, that's fine.

jonasw: you have an incoming PR

intosi, cool!

that looks sane

thank you :)

that's fixing the observatory? nice!

I think so

the observatory will become usable again?

last time I checked it said GTFO

zinid: it has your IP address hardcoded.

intosi, https://xmpp.net/result.php?domain=jabber.org&type=client that seems wrong?

ah, nevermind, that’s probably v6 going wrong

can we get ipv6 support?

also, dns and jabber.org are not friends at the moment

is jabber.org maintained?

in theory, yes

Ge0rG, I assumed in practice ;)

I'm attempting to contact the admin for some weeks now.

who is the admin?

zinid: stpeter

yeah...

Jabber.org the XMPP server?

zinid: why?

There are DNS issues. If days had more than 24 hours, those would've been fully resolved.

It's high on my to-do.