XSF Discussion - 2024-03-25

kurisu, taba: If you were not joined to this muc for some days, you may have run into a conversations bug: mam hole. Conversations only asks for 750 messages starting from the last message in local history

jover

lissine: what's the fix

also yellow hru

If having all the history is important to you you can delete the history and then scroll up for as long as you want

If it already happened, you can clear history and retrieve history again. If you're joining and noticed that you're running into this bug, you can quickly leave the channel and join it again, and hope that no one writes a message in between (if someone does you can't retrieve history anymore)

It's so over

> If having all the history is important to you you can delete the history and then scroll up for as long as you want The problem is, some servers limit the number of days of mam you can retrieve. So if you want to save all history (for searching purposes for example) this is not really a solution

As you will lose all your "hard earned" local history

> If having all the history is important to you you can delete the history and then scroll up for as long as you want what the fuck? ↺

Daniel: could you just make it simpler?

FYI gajim has a toggle of how much mam history you want. IIRC the options are none, one day, 2 days, 1 week, 1 month, forever.

How about all of it

Load more as the user scrolls

When you know how much history you want, you can get it right i.e. the messages you'll be missing would be the oldest ones, not the newest

>> If having all the history is important to you you can delete the history and then scroll up for as long as you want > The problem is, some servers limit the number of days of mam you can retrieve. > So if you want to save all history (for searching purposes for example) this is not really a solution the real problem is that my client didn't retrieve like the last messages 10 messages i cared about ↺

i don't even care about the 750 messages after the last synced message as much

kurisu, taba: It's a bug, Conversations doesn't know there's a "hole" in message history

> i don't even care about the 750 messages after the last synced message as much In that case you can clear history and scroll up

sorry, but i'm mentally incapable of willingly losing messages??

why does that even make sense

syncing the last 750 messages would make even more sense

It makes sense because if you're in a busy room (like conv-offtopic) and you weren't in it for a couple of months, syncing all history would take a lot of time

And server time

ignoring the fact that i want that... you can just sync the last 10 messages...

sometimes i join a chatroom to join the ongiong conversation

that's extremely counterintuitive

> It makes sense because if you're in a busy room (like conv-offtopic) and you weren't in it for a couple of months, syncing all history would take a lot of time That's why lazy loading exists... But yes gajim is also idiotic about mam and dino is too ↺

> It makes sense because if you're in a busy room (like conv-offtopic) and you weren't in it for a couple of months, syncing all history would take a lot of time > > And server time That's why Gajim lets you choose whether you want all history (may be costly) or a specific amount of time > ignoring the fact that i want that... you can just sync the last 10 messages... As I said this is a bug. I reported it in the past in the Conversations muc and IIRC Conversations 3 will fix this somehow

oh right, C3, cheogram

>That's why Gajim lets you choose whether you want all history (may be costly) or a specific amount of time Both options are idiotic

singpolyma, thoughts?

kurisu: Why is the Gajim approach bad?

It's the best IMO

you should be able to load messages on scroll

or search, or whatever

the mam xep is very obviously written with lazy loading in mind

Because why would I want to set how much history I want, let alone why would I want all of it? The program can readily tell how much I want by how far up I scroll.

That's what telegram and matrix do.

except matrix stores the entire history ON ALL SERVERS

cope

> Because why would I want to set how much history I want, let alone why would I want all of it? The program can readily tell how much I want by how far up I scroll. Among other things, searching happens locally. As opposed to Telegram which does searches server-side

> except matrix stores the entire history ON ALL SERVERS Good. ↺

and telegram only has a single server

>> except matrix stores the entire history ON ALL SERVERS > Good. kurisu: why would anyone want all of C offtopic... ↺

>> Because why would I want to set how much history I want, let alone why would I want all of it? The program can readily tell how much I want by how far up I scroll. > Among other things, searching happens locally. As opposed to Telegram which does searches server-side That's why searching should happen remotely. ↺

i think mam xep includes a search filter, no? ✏

>> Good. > kurisu: why would anyone want all of C offtopic... Why would I not want it? To save 50 megabytes in a month? You're just coping as usual trying to find something bad about matrix. Although, if we take into account how bloated xmpp serialization is it can probably come up with 50 megabytes much faster than that. ↺

kurisu: That has the downside of not being able to search if you're not connected to the internet

Also, performances

You can fallback to local search.

>> kurisu: why would anyone want all of C offtopic... > Why would I not want it? To save 50 megabytes in a month? You're just coping as usual trying to find something bad about matrix. > Although, if we take into account how bloated xmpp serialization is it can probably come up with 50 megabytes much faster than that. kurisu: look up the requirements for the most optimized matrix client ↺

i'm not fucking running that shit

It seems that you know a lot of things on how to design the perfect chat client

Performance of limited search? How nice to NOT find something with greater performance!

> You can fallback to local search. In that case you will only get results from your local history. That's why it's preferable to have as much local history as you can. And BTW storage history doesn't take much. 1 year on my account is ~30 MB, and I spent a few months in busy MUCs

But I agree the idea of remote search is interesting for discussion

>> Why would I not want it? To save 50 megabytes in a month? You're just coping as usual trying to find something bad about matrix. >> Although, if we take into account how bloated xmpp serialization is it can probably come up with 50 megabytes much faster than that. > kurisu: look up the requirements for the most optimized matrix client ask aria net or whatever dev how big their matrix server or client or whatever has gotten ↺

it's just wasted space for literally no reason

>> You can fallback to local search. > In that case you will only get results from your local history. That's why it's preferable to have as much local history as you can. > And BTW storage history doesn't take much. > 1 year on my account is ~30 MB, and I spent a few months in busy MUCs "In that case" i.e. in the rare case where you want to use a program inherently tied to the internet, without the internet. Yes, that's nice to have. That's no reason to load everything unconditionally. History storage may not take much disk space, but opening a client after a long time and having to wait a minute or more while the chats jump around while they load isn't a good UX at all. ↺

Also nowadays messages are not only text messages anymore, you have metadata and a bunch of other things around (reaction, reply...)

And telegram integrates that very nicely, and so should xmpp.

If remote searching is to be added to xmpp, it should take into consideration jumping to messages (like https://gultsch.social/@daniel/110118815716187992) that are not necessarily in your local history, and being able to lazy-load history both before and after that message

>> You can fallback to local search. > In that case you will only get results from your local history. That's why it's preferable to have as much local history as you can. > And BTW storage history doesn't take much. > 1 year on my account is ~30 MB, and I spent a few months in busy MUCs CC: kurisu same. my backup takes up like 40 mbs ↺

Like, you can jump from a reply to the message being replied to even if it's a year away, and even in that case it won't load everything in between. That's how it should be.

> If remote searching is to be added to xmpp, it should take into consideration jumping to messages (like https://gultsch.social/@daniel/110118815716187992) that are not necessarily in your local history, and being able to lazy-load history both before and after that message Yes ↺

>> In that case you will only get results from your local history. That's why it's preferable to have as much local history as you can. >> And BTW storage history doesn't take much. >> 1 year on my account is ~30 MB, and I spent a few months in busy MUCs > "In that case" i.e. in the rare case where you want to use a program inherently tied to the internet, without the internet. Yes, that's nice to have. That's no reason to load everything unconditionally. > History storage may not take much disk space, but opening a client after a long time and having to wait a minute or more while the chats jump around while they load isn't a good UX at all. kurisu: that's an issue with the clients... they should quickly sync the last 20 or so messages and sync the rest in the background ↺

> Like, you can jump from a reply to the message being replied to even if it's a year away, and even in that case it won't load everything in between. That's how it should be. Is that something C3 is going to be capable of ↺

> Like, you can jump from a reply to the message being replied to even if it's a year away, and even in that case it won't load everything in between. That's how it should be. Yes. That's how it should be if we have remote searching

> And telegram integrates that very nicely, and so should xmpp. Didn't know that Telegram had a decentralized network and a compability history of 20 years across plenty of servers and clients ! ↺

Maybe we should hire a few of their devs

> Is that something C3 is going to be capable of It depends whether it's possible to do it with the current MAM XEP

it's fine, he just has to rope about something every 5 minutes

>> Is that something C3 is going to be capable of > It depends whether it's possible to do it with the current MAM XEP i think so ↺

> Like, you can jump from a reply to the message being replied to even if it's a year away, and even in that case it won't load everything in between. That's how it should be. permaybehaps ↺

>> And telegram integrates that very nicely, and so should xmpp. > Didn't know that Telegram had a decentralized network and a compability history of 20 years across plenty of servers and clients ! Those are not mutually exclusive with bad user experience, nor in any way justify it. In fact, poor UX makes it hard to be proud of the 20 years. Because those are 20 years of poor UX. ↺

depends on the userbase

it's changing

Pragmatically: if replicated archiving functionality is something that's desired, start drafting a proposal how that's technically and functionally going to work. We're a standards org, after all.

I don't think we have a protocol hole that prevents syncing archives. You can do sensible things with MAM.

Also I think (may be wrong here) gajim and dino mam loading is much slower than it could be. If 30 megabytes is a year, then a week should be loaded instantaneously, but for me it can hang on that for like a minute I think. Is it wasting time on roundtrips, like "request N messages, receive them, only then request N more"? ✏

Could be. Could also be the server requiring time to collect the data from the archives.

Has to be, even. Can't ask for the previous page without knowing what the page is previous to.

But what if you request huge pages?

That's allowed, although the server is allowed to limit the result if it's more than it's willing to serve in one go.

I mean if we are doing eager loading, we could at least do it fast. In most cases you wouldn't even notice eager loading if it loaded a year in couple of seconds. I think that'd be much simpler to implement than remote search and the "jump to that message ago without wasting time on everything in between". I a server lets you download a 30 MB file in one go, why wouldn't it let you download 30 MB of messages in one go. Although given how slow draugr.de file downloads are it almost makes you wonder if files are downloaded like that too lol

Actually eager loading does have a huge advantage: you can search encrypted messages.

If a server has 10000 users you don't want to serve 30MB to everyone who joins a channel with 'infinite' history

Well, those 10000 users will want to send and download 30MB files occasionally.

I'm not sure if they do, but as Kev pointed out: the existing protocol already support much of this. If that's true, then this becomes something to take up with those that implement things (servers and clients) - unless you want to suggest we start using a different protocol.

> I mean if we are doing eager loading, we could at least do it fast. In most cases you wouldn't even notice eager loading if it loaded a year in couple of seconds. I think that'd be much simpler to implement than remote search and the "jump to that message ago without wasting time on everything in between". > I a server lets you download a 30 MB file in one go, why wouldn't it let you download 30 MB of messages in one go. Although given how slow draugr.de file downloads are it almost makes you wonder if files are downloaded like that too lol kurisu: loading the mono((C)heo) backup take A WHILE ↺

Yes, it seems the existing protocol already supports that, it's just a matter of how you use it. It's like with databases I think: unless it's sqlite you will generally limit the number of queries.

i have no clue what it does and it scares me

>> I mean if we are doing eager loading, we could at least do it fast. In most cases you wouldn't even notice eager loading if it loaded a year in couple of seconds. I think that'd be much simpler to implement than remote search and the "jump to that message ago without wasting time on everything in between". >> I a server lets you download a 30 MB file in one go, why wouldn't it let you download 30 MB of messages in one go. Although given how slow draugr.de file downloads are it almost makes you wonder if files are downloaded like that too lol > kurisu: loading the mono((C)heo) backup take A WHILE A while you mean from a local file? ↺

Over

yes...

maybe decryption takes a while? who knows

Although for me cheogram sometimes hangs a bit even just opening up... Bruh

it should just be an sqlite dump i think or smth

no clue

> Yes, it seems the existing protocol already supports that, it's just a matter of how you use it. It's like with databases I think: unless it's sqlite you will generally limit the number of queries. it's just jover for sqlite ↺

from what i've read

it sounds more and more like you're wanting a change in a very specific implementation. Maybe you should talk to the community that develops that/those clients.

> maybe decryption takes a while? who knows Pretty sure e.g. with a 7z archive you won't see a difference when unpacking a 30 mb file if it's encrypted or not. So definitely not encryption. ↺

> singpolyma, thoughts? taba: this is the first I hear of this bug, but it explains some things. I will put on my lirt to look into it ↺

>> singpolyma, thoughts? > taba: this is the first I hear of this bug, but it explains some things. I will put on my lirt to look into it singpolyma: thank you ↺

soo, scrolling back, I'd like everyone, in the future to: - avoid insulting language about projects in our community (be constructive, not destructive) - stick to the topic of this room (discussion of standards, their development (not necessarily implementation), and general XSF meta)

thanks all.

Would it be possible to discuss about deprecating password protected rooms in 0045 ?

please don't, they're needed for IRC bridging.

Really ? There's password in IRC ?

yes.

#TodayIlearn :D

edhelas, deprectating to-be-replaced-with-something-else, or simply no longer have rooms that can be password-protected?

well he's right that they aren't needed when you can make it member only and invite people

Maybe clarifying the usage I'd say.

moparisthebest ^ this

But yes... IRC, even though there I haven't seen this used... In forever?

Member only rooms are most of the time the way to go for most of the usages. ✏

moparisthebest, the other user of my IRC gateway uses it.

I know because he was very annoyed when some client repeatedly killed his MUC bookmarks :)

Is there a reason other than "I'm not using it" for wanting to deprecate this?

I do think it's sensible to have some writing somewhere that a sane client might not want to allow users to create rooms like this, or at least recommend the other

> moparisthebest, the other user of my IRC gateway uses it. https://xkcd.com/1782/ ↺

accurate.

>‎25/03/2024 | 15:34:22 ‎moparisthebest‎: But yes... IRC, even though there I haven't seen this used... In forever? i use irc since over a decade (was a kid) and xmpp since 2 years (plus opened-sip), those three convinced me to never use something else (or maybe just classic phone)

s1 you're using SIP ? On which server did you create your account ?

btw the last calls for Consistent Color and Nonca end today. if you have feedback for those XEPs now is your last chance

Thanks for picking up the Editor tasks, Daniel. It is good to see things moving again.

s1: I realize I wrote that funny, I still use IRC (through XMPP) daily, I mean I haven't seen password protected IRC channels used in about forever :)

Is more than one video or more than one audio content in jingle ever actually used

kurisu: think screen sharing (with audio) while video, so yes

So like What client does that

If I called Dino or Conversations with two videos, would they... Work?

I don't know if any XMPP client other than jitsi currently implements this, but it's a use case to keep in mind

iirc someone modified Conversations once to support screen sharing? Maybe Daniel remembers

Pade, possibly. Dele Olajide?

I think that multiple stream (multiple video or audio) can be used for Jingle groups calls with SFU in Siskin IM and Beagle IM, if I recall correctly

I think it was a guy who used to be active in XMPP channels with a green wolf avatar but now I only see him on fediverse, it's highly likely I'm misremembering though :)

Will you ever see more than one audio or video content? It depends. Generally yes this can happen

If you want to transmit multiple of a thing you can either have multiple contents or multiple tracks in the same content

Ideally you would probably do the latter. But if you are implementing a generic jingle thing you might want to support multiple contents of the same type.

Conversations currently won't display multiple video no matter how they are recievied

Siskin IM or Beagle IM will display multiple video but I do not recall if that uses multiple tracks or multiple contents, but I think I could work for both

The PR or whatever I recall for Conversations was mostly about uni directional video

Due to unified plan with webrtc being so widely deployed, multiple contents is realistically what you will see in the wild

why does jingle use iq like it uses them? It would seem a session-accept would belong in <iq type=result>, but instead it's always "set" and "result" is more like an ack. Why is it done like that?

kurisu: yeah, the empty iq returns in jingle are kinda gross, but probably not worth the pain of changing it

I'm just wondering why it was done like that in the first place? Maybe there's some good reason for it I'm not seeing?

Not sure about the original reason but there can be significant time delay between session init and session accept

That's probably unusual for iq in other contexts

You want the (automated) iq result to happen quasi instantly

And then the manual session accept is a different thing

Plus there are obviously lots of jingle actions that don't have a response but you want to ack them on an iq level

I'm not sure what the acks gain you vs <message/> in most cases

Since iq are usually implemented with call backs on the client side you get quasi automated error tracking

Yes messages have errors too. But most client libraries won't track them the same way

https://xmpp.org/extensions/xep-0166.html#concepts-session It seems that diagram allows all actions in the pending state. In practice... is that supported?

so like a receiving contect can seriously enable video in an incoming voice call and send content-add before they even pick up, and Conversations or Dino will ask the caller if they want to enable video? I mean in practice, are things like that implemented?

I can Only speak for Conversations but in Conversations content adds and removes only work after session accept

But something like transport info will obviously work before

thought so

That said implementing a bit more than other clients is a good reason for those clients to move forward. Otherwise we all get stuck at the bare minimum

A quick question. If ICE connected over TCP, what to do with SCTP (datachannels XEP) ?

Maybe it's worth adding to the datachannels xep something like "I don't care much about channels, just give me a reliable connection"? So if connected over TCP, then sctp is not negotiated at all.

I don't think we should silently just get rid of negotiated transports. I think it would just work, no? Albeit being a bit unnecessary

Technically the ice-udp xep (that data channels wraps around) doesn't even allow ice tcp ✏

> I think it would just work, no? Idk. Maybe this will require another protocol defining how datagrams are sent over tcp. Like <32 bit big endian size><payload>

Maybe will just work. Seems like sctp headers define block sizes. So should be parsable.

Hi XMPPeople! I would like to make some changes to the XEPs table on xmpp.org regarding Experimental/Deferred XEPs. There are some screenshots https://github.com/xsf/xmpp.org/pull/1357#issuecomment-2018796516 Comments most welcome!

Daniel: https://xmpp.org/extensions/xep-0371.html this one allows tcp. Ok. So be it. Negotiate sctp if declared in transport. Thanks.

rion, yes i'm aware of 0371. however the datachanels xep uses the other one

Daniel: I guess it was just forgotten. so nobody updated :)

cal0pteryx, i think the general idea of flagging dormant xeps is good. I’m afraid the checkbox that overwrites the other checkboxes is confusing

maybe at least move the checkbox elsewhere

Next I'd question whether we need all those checkboxes 🙂

Does anyone use them? What for?

I regularly search for XEPs by name or number, and in that case I don't care about the status of the XEP I'm looking for

Otherwise, I'm browsing the list, and then I want to see everything

Except with the "dormant" selector, I'd sometimes want to filter by that. Today the closest is filtering out deferred, but that's not useful because so many deferred XEPs are important.

So I cautiously suggest that the dormant selector is the only one that's really useful

> Hi XMPPeople! I would like to make some changes to the XEPs table on xmpp.org regarding Experimental/Deferred XEPs. There are some screenshots https://github.com/xsf/xmpp.org/pull/1357#issuecomment-2018796516 > Comments most welcome! cal0pteryx: looks great! Let's merge :) ↺

Daniel, you seem to dislike jdev, why is that again?

years go by, you never join, or stay joined :D

Anyway, as you are active with the Display marker XEP, the point came up in jdev, that its not clear if a display marker should reference the original message, or the corrected message id

and this goes for all the other XEPs that reference messages too, they dont mention how to deal with this