XMPP Summit - 2023-02-02

I will be online when I get myself to wake up :)

What is sleep?

Waiting at airport.

Have a good flight.

Leaving for the train station. See you in Brussels :)

Aaaaaand *drum rolls* of course my train to cologne is canceled!

😢

Never mind, it appears they replaced it with another train going the exact same route

On my way :)

Where did everyone go? 🙂

I'm here. I didn't go anywhere

> On my way :) \o/

I'm 2 min from Ibis, having a quick breakfast and I'm here.

me too

Good morning

singpolyma: good morning, emphasis on the 'morning' 😅

Landed

Have fun everyone! I'll try to lurk remotely when possible.

Found a Syndace

And emus, looks like I'm in the right place

The IRL room is almost full, we're just missing a couple of people (and one of them has the A/V equipment, so we haven't attempted to set up a stream yet)

As such, it's currently the peak remote participation experience. It all goes downhill from here.

I like your optimism, Kev.

Carefully honed over years of Summits :)

We haven't crashed the wifi yet, there's hope ;)

Switching on the A/V equipment might be a factor there.

The A/V equipment has just arrived.

Ralph believes he's early setting it up, because he's not 15 minutes late yet.

Goodbye, wifi!

A room full of people are unsurprised 🤣

I think we're just missing Zash and Link Mauve

Kev's voiceover might be better than having an active A/V setup.

You are not wrong.

We're doing introductions while A/V is being attempted

Kev is Kev and does things.

Edwin is Kev's minion.

Matthew does things.

Eddy does things.

MattJ: Passing Noord

Goffi likes components and pubsub and PEP (not clear if the person or the spec).

I'm going to stop now, someone else can take over...

noooo

I was about to comment: 'screw the a/v, kev ftw'

live, opinionated transcription ;)

Fine.

Andy doesn't do anything.

Alex does things.

Alex doesn't think Kev is sexy any more :(

:shock:

Tissues to wipe most of the tears have been issued.

A/V work is still in progress, but we're going to start with determining the day's agenda

intosi@ik.nu, I'll need one now that ralphm mentionned wokkel

Attempt to live stream the Summit: https://meet.jit.si/XMPPSummit25

I'm in!

I also

https://www.kaidan.im/2022/08/31/e2ee-trust-management/ kaidan's automatic trust management

Wobbly table on which the camera rests. Excellent view of Daniel and Winfried though! ;)

First topic, "Push 2.0"

https://pad.nixnet.services/TRjHpDkUSrep9jqzcjY0uw?view#

> if you are offline if you are not connected over TCP ;)

Kindly refrain from singing praise directly in the microphone while I have my volume all the way up trying the hear Matt :)

Sorry Sir.

Nice voice though :)

ralphm: are you recording too?

would be nice to have transcript with whisper afterwards.

I'm surprised that anyone has the wakeup and fetch still working on iOS

#XMPP Summit at #Brussels We plan to discuss the topics in the following order: 1. #Push 2. #Spaces 3. MAM 4. MUC 5. IN-NG 6. #Jingle / #WebRTC 7. Disco 8. #PubSub 9. NL/EU 10. XMPP Providers 11. #Communications 12. ATM

MattJ, Kev ^ fine to toot at least that? + where to join the chat?

Note that for comparison, encrypted payload is what iOS matrix clients like Beeper use. Sometimes/often wrapping e2ee inside them yes

I don't object.

Is there a short description of what these are supposed to be about exactly? Some I can guess but not all

Just what's on the wiki, at this point.

(for reference: https://wiki.xmpp.org/web/Conferences/Summit_25#Agenda )

What do the push services do if your payload is too big? Probably just give an error which can be returned to xmpp server?

(I'm not following the stream fwiw, people around and not enough bw anyway)

There's a pad with some kind of notes?

https://pad.nixnet.services/TRjHpDkUSrep9jqzcjY0uw?view#

Thanks

though that seems to be a draft XEP

(I didn't click the link before resharing what MattJ posted above)

Yeah, that's not summit notes

jonas’, you mean TODOs everywhere? :P

I'll start something for notes

I'm happy to follow from afar, not need to rush things for me

xml compressed, json, cbor, msgpack ;)

The compression library we used for cramming stuff into Push messages was written by Thiago Camargo (of jinglenodes fame): https://github.com/xmppjingle/shogun

Ah, great to see Thiago back in action! I loved working with that guy.

From my PoV one of the biggest limitations of current push is that servers don't use it as part of their presence model. If a mobile client is registered for push notifications and the TCP connection closes, that user is not "offline" and IMO presence should stay online, along with everything that implies, since they still have a reliable way to get content that is coming in.

MattJ, so the hedgehoc is not what we use for notes?

Guus: I haven't talked to Thiago since the VEON project stopped, but I was surprised that this library has seen updates.

singpolyma: interesting. Does/Should Stream Management tie into that somehow too?

nevermind, I understood

Thiago and me used to be colleagues at Nimbuzz in Rotterdam. One of the nicer people I've ever worked with.

Guus: sure, that makes sense. The SMACKS timeout could be extended indefinitely while push is live to allow resumption when a notification is opened maybe? I'd have to review SMACKS to be sure if that is right to do or not

Ralphm: video resolution combined with the camera not being fully stable on a table that people lean on (I guess) makes things unreadable.

turning the camera to people that are talking is maybe a better use of the video stream.

(like you're doing now)

So the proposal for "xmpp web push" would be to wrap a webpush payload in a basic stanza for transport purposes?

Is a directional microphone being used? Audio of people in front of the camera is notably better as compared to that of people behind the camera. I can make out Ralph better when he's at the whiteboard, as compared to when he's sitting down (which, presumably, is closer to the camera?)

Is that vague list defined anywhere?

Guus: in the code ;)

(it being vague means: probably not)

My push impl pretty much pushes everything, I think :/

I found it hard to determine when to push, or when not to push.

So I went with an overkill approach, wanting to limit the amount of misses (which I assume is worse than getting to much)

The benefit to supporting webpush over http and also an xmpp is that the push proxy could be xmpp only, which is nice. But it slightly complicates the servers. That seems like the trade off for that

Hmm, yeah, having built webhook delivery at scale I can see how there are concerns to doing that

you could run the xmpp to webpush proxy on the xmpp server side same as we do with stun/turn etc, discover via extdisco on the client and use it

DIdn't Andrzej just say that you're not _allowed_ to delegate those secrets?

which kind of voids the discussion if it's technically possible?

not allow to share them. if there was a magic way to delegate them without sharing them... but that doesn't sound real

yes, same payload different transport makes perfect sense to me

I believe there's a way to separate the TLS private keys from the entity doing the TLS connections, but then someone would have to run that thing and it solves nothing.

they support for mobile browsers as well

probaby proxied by their normal push services

but they handle that

Yes, web clients get notifications via service worker

Oh, yeah, I don't think we have any xmpp webpush implemeted yet

For the record: *sigh* in the direction of reverse proxies.

ah, same.

but Matt makes a good point: if we can prevent that annoyance... it might be worth while.

(I _think_ he made that point)

Double encrytion also not needed if webpush proxy is run as a sidecar like stun/turn

can you turn the camera please Ralphm?

You need some kind of queuing for the webpush webhook delivery, you're not gonna "just post" inline, not at scale

so that means either a thread or a sidecar

sender shouldn't decide priority at all. that's up to recipient

indeed.

Heads up: lunch at 12:30 CET.

there's already a match profile for "stuff that goes into mam" and that seems compatible with what SCE need already anyway

I'm not sure you need anything extra

Not specific to MUC, but I'll reiterate because it's relevant to MUC push: > From my PoV one of the biggest limitations of current push is that servers don't use it as part of their presence model. If a mobile client is registered for push notifications and the TCP connection closes, that user is not "offline" and IMO presence should stay online, along with everything that implies, since they still have a reliable way to get content that is coming in.

If the client can have a long running TCP most of the time (as we can on android) then the notify only wakup is ideal

it won't have the battery issues because you're not expecting to reconnecte every notification really

about the CSI profile: is what CSI determines to be 'important' specified? I thought it was not?

Guus: no, I think the idea is to not notify at all for things CSI would not deliver

You can't write specifications prescriptively. Specs should describe what clients and servers will actually do, not what you wish they did -- that's how you get them ignoring you

Re-posting the URL to the summit notepad (for perhaps the first time): https://pad.nixnet.services/oy6MKVbESSycLeMJIOh6zw#

yes, first time I thnk

I didn't write much in there, so contributions welcome

Disagree. We have two classes of specifications: historical, which are speccing something that has already been implemented, and standard which is definitely prescriptive but generally improved during experimental and draft stages.

Sorry about that :)

We're on a break.

ralphm: specing something with no implementation and that client or server devs aren't on board with is just a waste of time IMO, that's how you end up with a WHATWG situation where the devs start their own org and ignore you

Thanks for the pad

singpolyma: ok

We already have lots of unimplemented XEPs which is a bit of a problem, but at least we don't have *too* many ignoring situations (though with push we do a little bit, since tigase went and did their own thing, but at least this proposal is to re-standardize)

Something about push: you should keep in mind that xmpp relies on ordering of events in the xmpp stream and sending some stanzas (encrypted) through push messages and some stanzas only on the real xmpp connection will break that assumption (and possibly IQ stanzas) in some subtle way...if you don't want to send every stanza through the push connection of your os or redesign a bigger part of the xmpp problem, I'd strongly advice against going this route...

Thilo Molitor: I think the idea for apps that want to work that way is to just use the push notification to show a notification to the user, but not to store it in any way and then when the user taps the notification the app opens, connects to server, and does normal stanza fetch / mam sync

Even then: what about the big/long mam catchup if the user opens the app some time later? What if the user does not have an internet connection when he tries to read all 5 messages he received in the app but these can't be fetched because of missing/bad connectivity?

I think this is very bad ux...

sure, but that's up to each app dev to decide how their UX should work I guess

What about read markers coming from another device that should remove pending notifications because the user read the messages on another device?

Sure...but to make that clear: I think this is a dead end route that nobody should try to follow...

What about IQ stanzas?

For XMPP providers list, to me the most important thing is the reliability of the service -- is it run by volunteers or by people who do this as part of their work? Is there monitoring? If it's volunteer is it only one volunteer? The current list has some of this information, but doesn't seem to use it as part of the evaluation at all

For example many services are run by one volunteer and so if it goes down while they are at work they cannot even look into it until they get home

Ralph says "Someone apologise to the Summit room".

telephone networks definitely compete on features too

video calling, picture and group messaging, visual voicemail, wifi calling, etc etc

Sure, telco's like you to believe that. In practice, though, it is about cost only.

Family had lunch, but I'm back now. Video quality dropped quite a bit?

They provide two services: voice and data. SMS is a bit of a side thing, and nobody cares about anything telco's do on top.

on the other hand, I joined from a McDonalds 😀

ralphm: for most people I know SMS is the main thing :) voice is the legacy thing. Ok, I guess data is the main thing, but that's not telephone network anymore

That's why Whatsapp is big, and Google umteenth effort to force RCS is their last chance to be part of the game. Maybe

320x180 at 10 frames/second.

https://github.com/monal-im/Monal/issues/652#issuecomment-1218421555

This lists some of the problems Friedrich and I see with the providers list

Thilo Molitor: I agree with the bulk of that too, yes

My personal take on the providers list: (quote from the monal issue) « While some may argue that an objective list of XMPP servers is beneficial both, to end users choosing a server and to client developers integrating more servers » < there is no objective list that can be made. And please can we assume it and be honest about it already ✏

I like how only _minutes_ after Ralphm mentioned that he was going to close the door - which will lock it - there was someone from the staff in the room collecting your used tableware ;)

Isn't WhatsApp barely known in the US?

vanitasvitae: it's not very popular in USA or Canada, but depends on the community

Facebook Messenger is much more popular. Or iMessage

wasn't an earlier version of iMessage based on XMPP?

I think I heard Matt Tucker say once that at the time, Jive Software was powering chat for Apple.

(this will have been far before the iphone era)

could be. I know WhatsApp and Zoom are

Yeah, funny story that, WhatsApp. Jan Koum once approached me to work on a Blackberry app for a new chat that he was building. My then employer could not be bothered signing the contract that I had prepared for this.

One of the reasons why I now choose to not have an employer...

I'm likely to have to drop out for the day before the next segment really gets started, unfortunately

kids will wake up soon

Guus: I see fancy xmpp hoodies everywhere at the meeting! didn't you want to print some new ones? :)

oooh.... :shame:

you can actually see me wear an old one today, by coincidence

let me get on that, now.

the face that I'm making now on the video stream is me trying to look for the design files that Ralph sent me earlier...

ha, yes, I see focused Guus ;) and I'm curous about the designs

I'll share my screen

(foudn them!)

ah yes, I remember now!

thanks! I'm still interested :)

_or_ we make the design public, so everyone can print themselves (where single orders might be cheaper than collective order + intl. shipping)

I suggest we pic-up on organising this again

I'm sending an email to the printer _right now_

thanks Guus!

Aah, 2023.. :) "sending an email to the printer"

As I'm the only one with a Show&Tell tomorrow I guess that there is not much interest in it, I'm removing mine.

https://cerdale.zash.se/s/ACKJrpXUEylvT6932R63SV_f/DSC02748.JPG

MattJ - can I do it like this? #XMPP Summit at #Brussels The first topic we discussed and reviewed was #Push 2.0. Read our pre-notes: https://pad.nixnet.services/TRjHpDkUSrep9jqzcjY0uw?view#Client-registers-to-receive-push-notifications #openstandards #opensource #decentralisation #interoperability #rtc #jabber

emus_web: that link can be turned into an editor

So there is the risk of vandalism

emus_web, use this link: https://pad.nixnet.services/s/GPBR4xa4k#

Yes, I know

yup

wurstsalat: "we" making the design public would basically be "me" doing that. I'll think about that.

In any case, I didn't make any effort to make new swag because I didn't know how well this year's Summit and FOSDEM would work out.

ralphm: I see

No, but I promised to order some for individuals almost a year ago, and never did. I'm doing that now.

I'll follow up with everyone that ordered then, to see if they're still interested.

If there's more interest, I can also include that in the order.

Ralphm should we move the camera to the board?

I'd rather see people discussing

Ok, as online folks want 🙂

but its right now Kev at the board AND talking 🙂 ✏

"dressible hats"...

inb4 acls in pubsub

At some point we were talking about implemeting ABAC (https://en.wikipedia.org/wiki/Attribute-based_access_control) in XMPP

Goffi: https://pad.nixnet.services/oy6MKVbESSycLeMJIOh6zw?view

MattJ, how did you make the pad entry link just read-only?

Click "Publish" at the top

I see, but we cannot do it now, it will not allow continuation to edit, right? Or does it just opens a read-only view?

It just opens a read-only view

You can still edit the original

👍

MattJ: how to you tell to the prosody MUC that you don't want to get MUC presence?

goffi, unless I've missed something, the room owner configures it for everyone.

OK, and I guess by default you get presence right?

Yup

I don't see how this scales then. Most owners probably don't have any idea that the feature even exists.

Would be good to have a way to request it from client.

(well-known ad-hoc for instance)

Join option of some sort mayhaps

Using caps maybe ?

If an app really doesn't want it wouldn't it make more sense to filter it at their server?

privacy list

(joking)

I've just heard back from the company printing the hooded sweaters. Excluding shipping (from them to me, and from me to you) the price will be about 30 euro per sweater (35 for the 3XL size and larger). Sadly, the orange sweaters are not available in sizes over 2XL. I am about to place an order. Is there anyone that wants in, that I didn't talk to today (either here, or via email)?

mod_minimix?

it's the sweater that you see Alex wear on the summit floor. :)

Guus, are those the same "I think therefore IM" sweaters from 2 or 3 years ago?

vanitasvitae: yes.

uhh, what did I choose?

Ah, I already have one then 😛

emus 1 large, orange.

Guus: sorry, nevermind I got confused

you still want that one?

I thought we had a choice of the text

Guus: yes sure

You get to choose between orange sweater with navy print, or navy sweater with orange print, as well as the size. Those are all of your options. :)

:)

FMUC = Matrix rooms ? :p

I would do it myself if I could, maybe someone can link the relevant XEPs to the topics in the chat (?) ✏

FMUC: https://xmpp.org/extensions/xep-0289.html

I would do it myself if I could, maybe someone can link the relevant XEPs to the topics in the pad (?) ✏

Sorry, I meant the pad

but is fine I can try to add it

I'm somehow have the feeling to be back in time with the current topic.

edhelas: basically

Am I the only one not hearing anything on Jitsi?

Because everyone is gone :p

Ah.

Maybe you can hear The Void 😱

I was wondering if everyone was dead

Ralphm lets stream the dinner, so they can watch us eating 😉

(just kidding)

So.. reading the pad, that's it? Everyone at the table agreed about Spaces? It's not a milion of different things anymore?

Let's write a new PEP XEP to broadcast what you're currently eating

everything is decided now /s

> So.. reading the pad, that's it? Everyone at the table agreed about Spaces? It's not a milion of different things anymore? Yes!!

seems to be going in a good direction reading from the pad

I finally made it to the city :O

I guess I will join up with you at 19:00 then

🥳

you can just bring your stuff right away

So we will not have a multi-verse when doing Spaces 🎉

Already brought stuff to the apartment

vanitasvitae: are you coming right to the restaurant?

vanitasvitae: hi

Because we are leaving the hotel in 15 minutes or so

To make sure everybody is aware. Please be in the lobby in at 18:25 CET, the taxis are booked for 18:30.

Oh, I guess I'll run then :D

https://mercury-im.org/upload/d7b889510080fc34fd5573214b1e3c48541968d7/rVh6HuAf0eeTo3BfPSeH6ZrTrebDCqrXbCSu5Qjq/nGMumZfIRpGo8vKg34LcwQ.jpg

Should be manageable

I've updated and corrected the notes in the pad regarding ios and push

thilo.molitor: those are very useful additions, thanks!

I've added even more infos about push and background modes in ios

Thanks Thilo

how was your dinner? 😊

Dinner was really good. We will post an image tomorrow :-)

No problems, got a new card. Night all ✏