XSF Discussion - 2022-09-18

So I'm bringing back 0080 support in Movim :) 8 years old code to resurrect

edhelas: 👍

> So I'm bringing back 0080 support in Movim :) 8 years old code to resurrect that's a XEP I'd really like to see in Conversations as well. static geo:-URIs are not the same :)

The XEP is actually pretty good :)

Maybe having a small update for privacy handling (whitelisting JIDs) could be interesting

Would be fun to have locations event in MUC as well :p

Maybe Monal devs could also have a word on the xep improvements

> edhelas: > 2022-09-18 06:58 (GMT+02:00) > Would be fun to have locations event in MUC as well :p ouh yes

Then you could embed a minimap and follow friends, when going to a convention for example

Or start a hide&seek game :D

edhelas: it's pep right? So if you want to whitelist you just set a whitelist on the pep node?

singpolyma yes :) but talking about it in the XEP might help

sharing location can bring big privacy issues, not the same thing as Mood or Tune for example

Just like a one line "note you may wish to set the pep node to whitelist security" just in case the reader is unaware of the options?

Dunno, I'll see where I'm going with it

As usual with reusing generic mechanisms to fulfil specific tasks, you'll want to look at edge cases, such as what happens if a client forgets about an ongoing sharing activity. You might want to bake some TTL and/or "sharing ended" into the protocol.

"share my location for 30 min" is an option seen in many IM clients

MattJ this exists already natively in PubSub

but nobody implements it, and thats sad

pubsub#item_expire

this would be so useful for data which are only valid for a small duration

Maybe it's time to change that? :)

tune, location and a future status xep

check your issue tracker :D

pubsub#item_expire damnit :D

Okay, it's only been open 2 years :)

yeah thats recent, i have issue on the Gajim tracker from Zash which are 10 years old 🤤

Again the prophecy is right, 0060 is magically adding feature each time you have a look at it

Wasn't the prophecy about 0045?

Both.

I heard some found pieces of 0045 in 0060

They have both reached the critical size where they start growing by themselves.

I have mixed feeling about that 🤔

indeed.

although I think I have enough proof of fact that with a few rooms with 500+ occupants, MUC *can* _indeedly_ cause server detonation now 🤭

"each of our clients joins 5000 rooms. Why is it slow?" <-- last week

"We have 5000 rooms. Why is it slow?" <-- Matrix client admin

*server

Oh no, these had 150.000+

150000 ...rooms?

It's over 9000

🤔

> 150000 ...rooms? Yes, to get started

Wow.

Let me tell you about dunbar numbers.

guus.der.kinderen, a very similar example is why I worked on XEP-0437

Which is what I am implementing next...

Thank you for that. ☺️

Because, yes, as Zash rightly points out - whether you "join" 5000 rooms or not is irrelevant, people in reality will only interact with 5 on average

And it's mostly passive traffic, so not generated by actual interaction either

Maybe we should investigate more into cutting down noise from joins, parts, random presence in public chats. It does seems like a multiplier, especially when we have the same 20 people in 20 rooms...

(And surprisingly the killing factor is actually IQs and not presences)

disco?

Disco can be cached closer to the requesting client.

Disco, vCard fetching (💥), last Activity, version ... <Insert payload> ✏

Clients tend asking a lot of stuff to newcomers, a bit less after

And most clients don't just lazy load the occupants roster, so they just queue alle the IQs on a first join stalling as well and blocking

Could have a disco cache in the MUC itself. Avatars, I'd like to see something like that image hash thing, ie squeeze a in a very small version of the image into presence directly (like max 8x8px), then lazy-load the real avatars.

and who uses last activity today???

> <Zash> and who uses last activity today??? 😅

Gajim did this for a long time

queuing multiple IQs for every participant

rather not queuing, i mean we just sent it out

now we really queue it and send one per second or something

but this means it needs a lot of time until you have everything, but i guess avatars are not that important

Should be on the server to slow it down if needed not the client. Though client may also need to throttle to remain performant in some cases I guess

Zash, I already started working on that very small avatar thingy, fyi.

I already have some code for that in a branch of roezio.

How small is very small?

A few blocks of BC7 at most.

Something which can fit in a few hundreds bytes of base64 at most.

One block (4×4) is 16 bytes, so about 22 bytes after base64.

If you want to go 8×8 like Zash suggested, that’s 64 bytes, or 86 bytes of base64.

I'm mostly thinking 8×8 as an upper limit

So 8x8 pixels?

I’m writing the protocol (in the future) and two implementations (one in a client and one in Prosody (that one is in the future too)), admins will be able to configure that upper limit obviously.

roezio renewed my motivation lately (thanks pep.!), but that’s based on some old discussion already.