XMPP Summit - 2023-02-03

When do we start?

About 10 IIRC.

Yeah, 10

https://jabbers.one:5281/upload/6H4Y_YxDvagfFpT2uSiZ_nYq/20230203_094406093_f126..jpg

Thilo Molitor, thanks for the extra words about iOS push! It's quite lengthy, and not actually "summit notes" - if it's okay with you, I propose we move it to wiki.xmpp.org and link to it there. We could possibly combine it with the stuff in that text file in the mod_cloud_notify docs.

I think it has some value as a document we can point people to if they want to understand how things work today

Good morning everyone!

Good morning!

Good morning everyone from Italy! 😊

Moin.

Moin!

Done: https://wiki.xmpp.org/web/Push_notifications

For reference the blog post I wrote back then, which may be outdated: https://ralphm.net/blog/2019/09/09/fastening

https://cerdale.zash.se/s/S_KzH6qZXblOarTx-TBEmAsK/JEUHFBiuSKCpnq69SwuAYQ.jpg

emus:

h

what is not a "full knowledge client" ??

Converse.js for example

In most setups, at least

Oh, cjs doesn't store an archive? Interesting

Is this the same term as "thin client" ?

It does, but it's more of a cache

ok, makes sense

Compared to e.g. Conversations, which treats your local history as the truth, and MAM is just for syncing to that

right

Is there a Jitsi or other stream?

Zash: yes

https://meet.jit.si/XMPPSummit25

For collations one thing that is important is to say what things you support the collation of. for example, a client that supports edits but not reactions should be able to get the reaction messages raw not collated (so that fallback bodies can be displayed)

Great photo @Zash :-)

I'm in it, so didn't take it

> I'm in it, so didn't take it I referred to posting here :-)

@all physical summit participants - any objections I publish the images we shot via Fosstodon & Twitter to provide some impressions?

I asked already twice, but wasn't sure if that was clear ✏

I think it was clear, and the one person who opted out kindly took the photo, so I think it's fine :)

This whole collation thing really feels like a microoptimization to me... what % of most MAM archives are stanzas that can be collated?

singpolyma, much fewer currently than when we’ll have that implemented.

Should have brought the external flash, such uneven lightning at the restaurant

I’ve seen messages with hundreds of reactions in non-XMPP rooms.

Link Mauve: right, but are those not quite busy rooms that probably have thousands of messages too? I dunno. I'm not saying it's not an optimization, of course it is, but seems like a lot of complexity to save a small bandwidth for a small number of clients

On the image publishing: Ok, cool!

Uhm. For reactions you definitely want who did that, usually

Another small private vs big public chats?

... divider

thing

yeah maybe. Maybe if there are 10k reactions I don't want to list who did them all?

But like, even in BigCo company slack you do list that in practise, reactions are usually hundreds or a thousand or so at most even in the all-company channel

MattJ, sure, thanks for moving it to the wiki :)

combining it with the mod_cloud_notify docs sounds good, too :)

hmm, yeah, "blah, blah, and 32 others" might be a thing

Slack limits a single individual to 23 different reactions for a given message, and a message can have a maximum of 50 different reactions.

A MAM archive per MAM message per payload?

yes, sure, but you still get say the :tada: emoji has a count in the hundreds

also in practise most clients dont support edits that have no body or an empty string body 😬️

oh no, is a receipt an automated reaction?

singpolyma, also edits can affect non-body parts.

Like XHTML-IM, e2ee payloads or such.

Link Mauve: for sure

can I edit a message to change the thread id?

singpolyma, aaaaaaaaaaaaaaah!

Impression from the Summit: https://fosstodon.org/@xmpp/109800203838289905 ✏

singpolyma, is it a payload?

(yes)

Link Mauve: yes, just standard <thread>

or no? marvin or Daniel said only the body is corrected?

what about encrypted bodies tho?

I think I currently don't allow that because I figured clients are so bad at editing bodies that other stuff wouldn't be safe, but since most don't support threads anyway I have considered allowing it

what about full stanza encryption????

"Correction MUST only be used to change the logical content details of a stanza (e.g. the message body) and not to change the nature of the stanza or its metadata (e.g. correction MUST NOT be used to turn a chat message into a pubsub notification). Where a correction stanza includes metadata, for example stanza or MAM ids, these are properties of the correction stanza, and do not correct aspects of the original stanza."

I would argue that <thread> counts as metadata

so, not editable

Do we need another way to move a message between threads?

MattJ: You're probably right, but that's definitely a value judgement as current written

Link Mauve: "another" ?

Link Mauve: ah, I see

singpolyma, if we can’t edit the thread (because it is metadata), but actually want to. ✏

I'm not super worried about it, but I know some users might like it

But then, I'd also like to have edits of more than just most recent message. Which message correction could support with no spec changes, but currently reccomends you don't allow

I want to reiterate that the query needs to say what kinds of collations it supports

not just collation yes/no

great

Yeah, you want the individuals

I do bodies for all my reactions :)

Reactions do! ✏

We're not generating fallbacks in our case to be clear. We get a body from the phone network which represents a reaction, but the sender and recipient fully expect to get that fallback in the no-reaction case because it's designed by apple/google to be a fallback in the dumb-sms-client case

But the result is the same on xmpp side

So, unfortunately I have to leave again. Have fun everyone! See you at FOSDEM!

See you :)

Cool you've been here ✏

Here we go... :)

hehe

Can I show and tell my video at break? ;) ;)

nicoco, this whole discussion might be of interest to you btw.

Remote participation-presentation ?

singpolyma, that might be a very good idea :)

The A/V machine isn't the one that's linked to the projector, but I'm sure we can figure something out

"with body" is also a tricky heuristic. Given how most clients are it's not too bad, but yeah...

maybe "with body or fallback indication element" since then you know it has a fallback of some kind

singpolyma, so... are you serious about doing a presentation? If we get Jitsi on the projector, would that suffice?

I mean, you could even just play my video. it has voiceover. and I can answer questions via relay

or from the av machine or whatever

Ok, we can definitely do that

How long is it?

https://kumi.tube/w/1LQQp5Uia4u8Pdojxen1y8

Thanks

We'll do lightning talks after lunch

I won't be on the stream by then, but I'll probably still be here in muc

Join via Jitsi: https://meet.jit.si/XMPPSummit25

Can someone put the jitsi link in the topic or sth?

Ah I got it, https://meet.jit.si/XMPPSummit25

don't we normally rather simple servers, complex clients? ;) clients are easier to change than servers (at network scale)

XMPP is complex everything 😜

Best of both worlds

vanitasvitae: I mean, not usually, heh. But yeah, I understand there are tensions there sometimes

https://xmpp.org/extensions/xep-0134.html#simple

"Well yes, but actually no"

But anything that involves a new server feature is problematic because it'll "never happen" while you wait for all servers to update

Vs a client feature I can roll out tomorrow

singpolyma, you say as a client dev :P

Threads is something that i'm considering in Movim as well, shoudn't be something too difficult to implement afaik

"Prosŏdy - a study in simplicity"

While Z.ash could just write a new module and deploy it for every clients he's got

I was thinking of simply doing something like Discord

https://upload.movim.eu/files/9d94237298995552fa13436420195fbca436dce7/XxJuwLm0cqw7/image.png

(When do we do mentions again so I don't have to do this ugly non-mentioning thing)

We've had cases of pretty fast deployment of server-side extra features via plugins yes.

But, for example, we're still "waiting" on bookmarks2 because many servers don't even implement yet and many that could haven't updated

edhelas: I'd love to have something meaningfully compatible with what we're doing in cheogram android in movim. Doesn't have to match our UI of course, so long as people on both sides feel like they get what they want and can talk to each other

Right now you can talk to cheogram android thread users from movim, but you always have to explicitly push the reply button which makes it not happen often in practise

singpolyma Yes no problem :) I'm not planning to do anything in the short term, we can talk and figure out a nice way to do it. Maybe through Modern XMPP for the UI part ?

Cool. I might also do a prototype PR at some point for movim. Depends where all my other balls in the air are :)

singpolyma, we’re not waiting on bookmarks2 at all, clients which follow the modernxmpp guidelines get them properly whenever they use an up to date server.

Link Mauve: sure, yes, we've added bookmarks2 support in our client when the server supports the translation

But that approximately only works for our users who are on snikket instances right now

Prosody 0.12 and "mod_bookmarks" should support that, and 0.12 is in "only" is Debian backports. That might be part of the issue. Even though mod_bookmarks2 is also a thing in community modules and has been for a while (but then I guess people fiddling with modules may also use backports..)

Right, but does any non-prosody have it?

DOAP says ejabberd, tigase and openfire don't. ejabberd and openfire only support 411 which doesn't include bookmarks2 (right?).

metronome (yunohost) doesn't either..

right

So it's only prosody and only newest prosody

which is not no one, which is why I have built features which rely on bookmarks2

but if people want to use those features I mostly have to tell them to use snikket ✏

(of course, the bookmarks2 case is extra weird because we don't actually need server side support, but then we lose compatibility with other clients... possibly one of the most complex cases of this kind of roll out, so maybe it was a bad example of the original topic)

singpolyma, then again even ignoring the compat issue you do need the server to allow you to store more than a few items per PEP node, right. Which, AFAICS, is two issues in itself: (1) there's quite a few servers in the wild with a hard limit of 10 items, (2) there's quite a few servers in the wild that don't support the kinda newish `max_items=max` thing for configuring the node to the max. number of items, and without that thing it's cumbersome for the client to configure a sane limit.

Oh yes, I guess I wasn't aware there were still servers with such poor PEP support

So I think in practice you can still run into trouble with multi-item PEP.

singpolyma, well PEP was exclusively used for single-item use cases until relatively recently, so there's still many configs around that weren't updated for newer use cases yet.

Ecosystem movement is done when it's done!

interested. I guess there are some cases like avatar where you don't really need more than one

But yes, this is exactly what I was talking about. If you need server changes, the ecosystem update can be very slow

vs new client features that can happen overnight with no ecosystem wait time

Mood, tune, all the traditional things really only needed one 🙂 And then the newer things were spec'ed to stuff everything into a single item, to cope with the ecosystem. And _then_ we ran into race conditions with that hack.

tune would be useful to have multiple also, but I guess it does work with only one

That was years ago really. It's not like Movim and Libervia haven't existed for at least 10 years now

The max_items=max change is recent but the need for more than one item per node isn't ✏

As pep. says we use multi-items for many years. The time necessary to have features implemented in most server is exactly why I've developed a server independent component and privileged entities/namespace delegation.

pep., goffi, yes for 'social' stuff the need isn't new, but I think there's still many servers in the wild that weren't configured to work for those cases.

We can have new features server side overnight with them.

We are coming back from the lunch break!

(Should audio be back already?)

People are still standing around mumbling

So we haven't officially resumef

The hallway track! We're missing out!! (:P)

if you listen hard you can sometimes pick out something

The mic atleast appears to be powered

Kids aren't up yet so I'll hang around as long as I can, hehe

Is audio working now?

yes

yes

Great, we'll start the presentation in a moment

Conversations 3 is going to rely on max_items=max so you better start upgrading your servers ☺️

Problem solved :)

Casual DDoS

Membership Applications Q1 2023 https://wiki.xmpp.org/web/Membership_Applications_Q1_2023

comment nodes work ok, but I've thought they might be too limited (replies to replies, getting notified of all comments, etc). Maybe just a single second node "all replies and replies to replies etc on blog X", but of course that's not how anything works today and may have other problems.

Link Mauve is talking about gst-meet

ok

We are going to play https://kumi.tube/w/1LQQp5Uia4u8Pdojxen1y8 - in case that doesn't work out for remote participants on Jitsi

But hopefully it will Just Work

https://github.com/avstack/gst-meet < And then you can pipe a gstreamer pipeline to your jitsi meet room

pep., on MacOS? :)

No clue

👍️

Go watch the video, remotes.

We'll catch up in 6 minutes or whatever it is.

In the video I say this feature is "soon" but it's in our stable release for a few weeks now

MattJ, I haven’t tested, but I know Gstreamer is used on that OS too so it should work.

There's also an example of how to play a youtube video in the README :P

The problem isn't playing a video, the problem is the proprietary dongle we must use to use the projector in this room, which introduces another level of horribleness.

yeah, you can always reply or quote and start new thread

which we'll have more explicit UI for later

yes, <thread> has parent but we don't implement anything with that at this time for this feature

Right, exaclty

slack style threads are a message reply + a thread id

to start a new thread "in reply"

yes, I'm listening

Message Reply XEP for reply

then thread under that

not really no, unique thread id will work out for us ✏

Thank.s

thread-id := stanza-id OR thread-id ?

I think probably if doing that it makes sense to add Reply XEP also to make it clear, but if we spec that thread id that matches a stanza id is a reply that's ok

though you would have to make sure thread ids and stanza ids never overlap. We use UUIDs right now for thread ID in our feature so that's probably safe :)

Probably Safe™ 👍️

Yeah, this concern about "how to know if it's meant to be in reply or not" is why I would suggest to add Reply XEP tag for such a case

https://xmpp.org/extensions/xep-0461.html in case anyone not familiar

singpolyma: couldn't you build a very similar UI based purely on replies? Where you essentially have a 'show messages that reply to x and replies to those' button instead of a 'show thread button'

I think that would better inter operate with clients that only do replies

Yes, but then it couldn't interop with thread clients.

Daniel: sure, if you wanted to track the full reply tree you could simulate this from that. it would be more expensive

Email does it...

badly :)

Why replies when there are single-reply threads? :D

yes, having tried to implement that in email clients before this is why I say it's possible but more expensive :)

you have to recursively track everything. Old email specs has References header as a way to optimize this (to show grandparents etc)

If someone starts sending thread ids that are message ids as is being discussed we'll have to build a thing that detects that and shows it as a reply, basically. I think that's more work than just using reply xep, but it doesn't sound un-doable

Wasn't there something about "The XSF does not give UX recommendations"?

vanitasvitae, haha

reply and select thread are the same

replying will always select thread in our UX

vanitasvitae, the XSF thinks they don't :P

we don't do reply xep yet, but that's planned

pep., 😀

reply is a new thread only if thread id changes

SELECT WHERE message-id = :thread OR xpath(data, '/thread') = : thread something something

having two ways to do replies seems like duplication for no benefit, but I expect I can implement it fine :)

There's no facilitation in the room right? (somebody taking turns for who wants to speak) It's slightly annoying to follow when people talk over each other

pep., here in the room?

No presidium or anything, no

Not in MUC, but for people behind the camera

Here, in the physical Summit room 🙂

> It's slightly annoying to follow when people talk over each other I feel like we are very disciplined in that regard, are there multiple talking at the same time often?

We're probably pretty close to the point where organization and a presidium would be needed, sure.

Scaling Meetings™

Something something Dunbar numbers

I guess it depends on what you're used to, Syndace. I've certainly seen worse. :)

Syndace, it also helps people not talking much and who don't actually feel like interupting to talk :)

Do we need to make changes to the existing XEPs as a result of the discussion?

vanitasvitae: depends who wins

MattJ and I are both saying no ;)

Yeah, undetermined

<thread> is in a RFC

Zash, I think it's useful when it's not just a one person meeting already :P

Which one?

IM?

https://xmpp.org/rfcs/rfc6121.html#message-syntax-thread

Thought this was about 0201

Ah, yeah, replacing/updating 201 makes sense as a result of this.

0201 is dead anyway. I built some stuff to rely on it right before it died :P

Sounds like making a different element that also means reply, but I can implement two elements that both get interpreted as reply it won't kill me

https://jabbers.one:5281/upload/qVuxeXSxd289S3TafgYmq8fm/20230203_150019332_549f..jpg

So <reply-to id=x/><thread/y><new-thread/> ??

Zash: that's what I'll do under this proposal yes

Without the reply-to right?

Syndace: with, for me, since they're the same. if someone sends me just one or the other I can interpret either of them as meaning the same thing also. it's not hard

Or write down that <reply-to/> + <thread> = new thread that includes the replied to message?

if reply-to and new-thread are both present with different ids I have no idea what I'd do 😅️

If's not hard for you, but it makes clients that only support replies show one random reply for the thread start and then nothing else

Syndace: yes, clients that don't support threads won't show threads of course. That's what we have to deal with today anyway

Yes, but they will now show your thread starter reply

sure, because my user pushed the "reply" button

hmm, okay

*Short Break *

but if others want their UI to be different that's quite alright of course

I'm just excited that even half of what I proposed got consensus

> if reply-to and new-thread are both present with different ids I have no idea what I'd do 😅️ It's the beginning of a new thread. But it shows the embedded 'quoted' message it replies to

Daniel: right, it embeds the quote of one message but forks off a different message

Yes.

so the UI might be pretty weird with that. but it's also probably not likely with any UI people are discussing building

Right.

It depends. If reply to is just a type of rich message it's fairly straight forward ✏

Fairly similar to how one would show an embedded image a the fork-off message

sure, that's true

if you just render as a quote

which is obviously what we do now since we use quote and not reply xep at all in current code

I've written some stuff at the end of the pad, I hope I captured the consensus and rationale that was presented. Feel free to review/amend as needed. Break time :)

95 online on the pad!

wow, that's amazing! Are those really unique users?!

Its probably Slack staff spying on us!

https://tilanus.com/dav/index.php/s/7yDwkXxARjmJKK9

Folks, any other language present at the summit besides (yes I know its accurate to break it down by flags): 🇩🇪 🇪🇸 🇫🇷 🇬🇧 🇮🇳 🇳🇱 🇵🇱 🇸🇪

Thanks Matt

greetings to all. where can i find t-shirts with xmpp logo?

Piero: they're not generally on sale. Occasionally, there is a sale of swag at certain events (like FOSDEM), but I'm not sure if that's happening this year.

As it happens, I'm about to order a small set of hooded sweaters with XMPP branding. I'd be happy to include you in the order. The price will be somewhere in the range of 30 to 35 euro, plus shipping.

I think that you're watching the live stream. Several people are wearing that sweater in the meeting. It's the brightly orange one that's being worn by someone on the left hand side, or the navy one, that's worn by a couple of others. The design is the same, it's just the colors that are different.

What did Winfried just say?

Couldn't make it out.

An aside to Ralph.

a response was "what the hell"

The person using Matrix wasn't using it for chat but for their emailing system?

And, what vendor was pushing Matrix?

As pep. said

ta

Not vendor, just an unspecified individual

The aside to Ralph was saying who the vendor was.

oh

My wife, as a Dutch healthcare specialist, is having to use various 'standardized' IT systems. It is a burning pile of rubbish.

Guus, thank you. I'm trying to find a t-shirt printing service online.

As in, 'secure' text messaging depends on you manually filling out a phone number in the subject of an email message, etc.

piero: there is none, as far as I'm aware.

yes

omg, I failed to relogin into converse correctly 😃

lol

recurring conversejs UX issue

no, I typed my question into the name field

Yes, exactly

Hello again 😃

https://cerdale.zash.se/s/rijgIBJX_wffqxYYri8UpRUQ/DSC02830.JPG

😂

Who made the xmpp logo stickera last time I attended?

I was about to suggest the same thing as what Kev just did: should we fund this?

^

If we want this we'll need to go fish for these people and not wait for them to show up

more so if this is as critical as Ralph just made it out to be.

Zash's questions comes from people online asking for it https://fosstodon.org/@xmpp/109801150730549100

maybe the XSF should consider tendering for this?

Follow and participate in the “More Instant Messaging Interoperability” MIMI IETF discussion: https://datatracker.ietf.org/wg/mimi/about/

https://xmpp.org/extensions/xep-0409.html - IM-NG

@guus it is Zivver using Matrix as e-mail backend

https://xmpp.org/extensions/inbox/jingle-sdp.html

Hi what's your plan after the meetup today? Actually just arrived in Brussels ✏

https://opensourcedesign.net/jobs/jobs/2019-03-19-design-of-badges-for-different-xmpp-compliance-levels

Sure we can influence?

(that was ralphm talking?)

We have money and we're not even using nor asking for it

I think we're done with 'real work', for anyone listening in.

Arne, I'm not physically in Brussels, but it is just being mentioned in the summit that there is no concerted effort for anything for after the meeting

Ah ok, thanks.

then I maybe see you tomorrow :D. I unfortunately didn't have time to come earlier

Thank you everyone from the room as well!

Suggestions for a next event with remote participation: have someone look at the chat and proxy what is said? Can be part of the facilitation ✏

https://jabbers.one:5281/upload/cs3LXcUETGtX_y5RAXpb_Oe-/20230203_171934241_6ba6..jpg

I'm getting slowy ready to go out, if someone is interested. Still I will likely need 45 till im in the center. beside I have no clue, what about meeting at 8?

I will go towards center now and look for a restaurant

emus: I need to finish to prepare for a demo, and a bit lazy for the 30 min of transport, will stay at hôtel tonight.

goffi: ok - many success and thx for feedback

where are you now? maybe we can join

I am in a restaurant now (had no connectipn at my seat)

Anyone in a bar in the center?

Our little group went back to the hotel already, as we need to be up early to setup at FOSDEM

I'm sorry Eddie, a couple of us have just got back to the hotel to head to bed.

Ah, what Ralph said.

No problem 😊 See you tomorrow, but I wont be there early unfort.

Matt has my printed QR codes

👍