jdev - 2024-06-25

Wasn't there a plan for out of band histories retrieval? I keep finding it silly how clients behave while catching up histories across many rooms

That's a job for a 3rd quic stream 😉

moparisthebest: please pitch me this whole quic thing

rom1dep: it's TLS except you can keep the same connection open across network changes, ie wifi to LTE to different WiFi etc, and as an added bonus you can open multiple independent streams inside the same secure connection for free

But I don't see how that would make things better in that case?

The case where head-of-line blocking delays the real-time stanzas where you are being sent a bunch of old ones?

Head of line blocking affects 1 stream, so you have a stream open for real time stanzas and a seperate one for catching up on history (and maybe even a third for joining 1000 MUCs)

Ideally I would see clients fetch "bundles" containig all the histories, from all servers the user is connected to

That's what they do now

I mean, that would get rid of the pagination

It sounds like you are saying "open another connection to grab history" ? Which is also what I'm saying :) except with quic it's free

You still need pagination no matter what

I was thinking along the lines of a single http-upload zip with "everything from XMPP.org since XYZ"

So you would import whole domain's histories at once and not page by page room by room

Everything since... Is pagination

Ok, sure, I mean you get one page instead of dozens, is the point

You can do that now

I mean it's always gonna be by room because XMPP muc is by room, there's no link between rooms on a server like IRC or so

> You can do that now aren't you limited by stanza size? Is "now" an efficient way to dealing with long histories? (My empirical experience says no) > I mean it's always gonna be by room because XMPP muc is by room, there's no link between rooms on a server like IRC or so Can't we negotiate this at domain level? ✏

> What I would like to see happen next is the deprecation of that configuration protocol, and a replacement that allows you to 1) configure retention on a per-account basis, 2) request a manual purge of the archive one thought ive had, is the possibility for mam retention time to be configured on a per muc. unsure if this is at all related but it seems sensible to me ↺

kinda tangential to disapearing messages

> The case where head-of-line blocking delays the real-time stanzas where you are being sent a bunch of old ones? You want to make sure mam is fully synced before you start getting real time stanzas anyway ↺

why? I think you want the opposite

my arm has been cut off and I'm bleeding out, must call 911... oh better wait for MAM to sync first

Assuming your client had crashed right before you cut your arm or something

Normally you shouldn't need mam sync at all because we have smacks

don't disconnect or restart prosody or anything before serious accident... noted. but why not just sync mam on a different stream? :/

Sure but I still want mam sync done before live messages come in for consistency reasons. So I know I have all the messages etc

why not just back fill ?

If you're very careful with your deduping it can be done that way

But it's much nicer to just not have dupes

> Normally you shouldn't need mam sync at all because we have smacks but cheo will always sync after a crash or oom-kill, right? ↺

Yes

Though I'd like to fix that

> my arm has been cut off and I'm bleeding out, must call 911... oh better wait for MAM to sync first Considering the amount of data being passed around, it's a real shame that there is any waiting at all

moparisthebest, why bother with QUIC? you can just open multiple streams to a server. don't even need to enable stream management on your MAM sync stream, saving resources, and you don't need to send initial presence so that you won't be bothered by incoming messages on that stream either.

(ofc. you could somehow multiplex that with MIX, but it doesn't need XMPP protocol extensions beyond "oh and when you get a second QUIC stream, treat it like another XMPP stream. maybe allow SASL EXTERNAL to re-use the auth of the first stream") ✏

jonas’: quic is just free multiple streams with only 1 TLS overhead, which is more important for servers than clients But the connection roaming is super important for clients

only if you ignore smacks

moparisthebest, sure, but it's not a _requirement_

binding this type of stuff (using secondary streams) to QUIC is not sensible ✏

making it more efficient using QUIC *is* sensible

yea I'm not saying you can only do this extra stream stuff with QUIC, only that it makes it free

FSVO free

midly interesting XMPP usabilty story: someone one 404.city contacted me with a valid request via 1:1 message, I replied and got in return: xxxxxxx@404.city: modify: Messages from strangers are rejected

now the person will never know that I tried to reply ✏

yeah

404.city is notoriously and well-known bad about this.

this used to be(?) the case even for the abuse contact, fwiw :)

I wonder if something can be done about this

at least, the 404.city user should become aware that they can send messages to me, but that my response won't be delivered to them

good luck

he