XSF Discussion - 2024-06-05

does subscription of roster is compulsory to access current present of that contact?

Yes

MSavoritias fae.ve, is "the OMEMO experience" still that bad for you? It's been much better for me for several months or so, the last remaining issues I have are in groupchats, when there are siskin users, or quicksy users that change phone without backup (but in this latest situation it's on them) Usually, making sure that everyone exchange OMEMO direct messages with the apple fan(s) solve the issues now, which is not excellent but OKish… The sad thing about it is that none of my non-tech savvy friends care about e2ee in the first place, but well

.

As I said if its 1:1 chats with a person having a mostly static set of devices it works. Aside from that the answer has two parts: 1. You have the random problems. By that I mean: - Groupchats may or may not work. have tried with multiple clients here and there (android, ios, windows, linux) , we all disabled it. under 10 people chat btw all times. Problems varied from you are not joined, joined but too early, too late joined, you have been offline this whole time, etc. - Omemo not being the default makes it everytime a ritual to turn it on and everything. plus TOFU or not to TOFU - I havent seen a good UI/UX to check what keys the other person has or doesnt have so im skeptical to even turn it on just because of that. - Its difficult to find out what exactly the problem is when OMEMO doesnt work. for example in a groupchat it could be: 1. you dont have they keys 2. they didnt send you the keys and you need to retrigger it 3. they sent the keys to other people but not to you because you were offline 2. You have the keys problem. what i mean is that i have people using web clients or trying clients and i have to aprove a new key every time which is meh

some of my thoughts at least

test

check

ah so. adding to that some context: personally i used to be into OMEMO but lately have been moving away from that in favor of OX or similar things and i dont plan to implement OMEMO at the very least in my client. idk how MLS handles that or if I can actually make a UI on top of that. I mean signal and whatsapp couldnt (in the sense that you blindly accept keys and nobody cares so you might as well create a new OX key instead of having whatever OMEMO does

that is not to say we cant make improvements to OMEMO to make it usable at some point. but right now its at best a POC maybe early alpha of something. the UI/UX part at least. the XEP/tech part afaik we dont have that many cryptographers to give on that

> The sad thing about it is that none of my non-tech savvy friends care about e2ee in the first place, but well ah and regarding this i dont see XMPP doing anything particular about it to change it so idk what we expect here. (not that they should care. we should have 1 encryption that works *always*)

For what it worth, I think OX by default would be a better choice than OMEMO.

I am looking to implement https://xmpp.org/extensions/xep-0447.html in Movim, and add multi-images/files support per message. It will also help to integrate with things like Slidge (ping nicoco). I was wondering if there was some decisions made regarding possible things like blurhash/thumbhash. I'd be interested t add a <thumbnail xmlns='urn:xmpp:thumbs:1' .../> XEP for it if you are interested in

Ping

(not sure if you received my message regarding 0447)

i see it

ah server is still acting up it seems

I wonder if we should create a Roster Item Extension XEP that can store the same or similar extensions (pinned, chat notification settings) that bookmarks can but for 1:1

That would mean bookmarks for group chats. Roster for 1:1

messages do arrive. but very delayed it seems

Cheogram and slidge supports blurhash, I can’t find the entry in their wiki anymore

Here’s some XML for you edhelas if you want your blurhashes compatible with cheogram and slidge 😉 https://git.sr.ht/~nicoco/slidge/tree/master/item/tests/test_attachment.py#L101

Roster item extension would require server support, wouldn’t it?

And MAM does not reply

> Roster item extension would require server support, wouldn’t it? yes. but if we consider that a clean solution it could be worth it

personally I would prefer that to sticking 1:1 chats in the bookmarks node

I mean obviously just an idea and something to think about and iterate on

edhelas: you should ping larma directly.

goffi regarding ?

Is it only with me, or this room is super slow today? It takes several minutes for my messages to reach xsf@

edhelas: regarding XEP-0447, he's the author.

> Is it only with me, or this room is super slow today? It takes several minutes for my messages to reach xsf@ its not you. its the xsf server

oh OK I see other people complaining now.

On the bright side, all the extentions paying of, conversations tells me I left for "technical reasons" and also rejoins after a while _without me manually pressing the button_ !

On the bright side, all the extentions paying of, conversations tells me I left for "technical reasons" and also rejoins after a while _without me manually pressing the button_ !

On the bright side, all the extentions paying of, conversations tells me I left for "technical reasons" and also rejoins after a while _without me manually pressing the button_ !

Menel, ah the irony. your client is buggy and the messages are sent multiple times again :P

On the bright side, all the extentions paying of, conversations tells me I left for "technical reasons" and also rejoins after a while _without me manually pressing the button_ !

On the bright side, all the extentions paying of, conversations tells me I left for "technical reasons" and also rejoins after a while _without me manually pressing the button_ !

On the bright side, all the extentions paying of, conversations tells me I left for "technical reasons" and also rejoins after a while _without me manually pressing the button_ !

On the bright side, all the extentions paying of, conversations tells me I left for "technical reasons" and also rejoins after a while _without me manually pressing the button_ !

Still?

yep at least to me

i see the message 7 times

I mean even now?

not anymore no

OK, wondering if it's the client or `smacks_s2s_resend = true` and my experimental server config... Disabled that for now. Edit : Seems to have been my server config. Good to know that knob does something. Still automatic rejoin 🎉 ✏

edhelas: don't you already have sims in movim? What does 0447 add for you?

I'd like to move to what other clients implement and support several files per messages

sims and SFS are mostly the same on several files per message I think

(SFS has the optional attach more sources later thing, but all recent discussions in jdev have people not interested in implementing that)

SFS has multiple files backwards compatible which SIMS can't

Regarding blurhash: 0264 can do this using data uri. it's not going to be well defined, but that's because blurhash is not well defined

larma: correct. Mostly what's not defined is blurhash has no registered mime type. I'm using image/blurhash and image/thumbhash for now

This is just me of course, but I think it would be appropriate to use `image/vnd.*.blurhash` (not sure which vendor name) or at least `image/x.blurhash` for an unregistered mediatype

If we think nothing will ever get registered then I'd be open to learning about vnd maybe. Generally the issue with the x- stuff has been that you end up stuck with it and then you get standards and specs referencing the x- namespace, which is a whole disaster

> This is just me of course, but I think it would be appropriate to use `image/vnd.*.blurhash` (not sure which vendor name) or at least `image/x.blurhash` for an unregistered mediatype larma: do you want stpeter mad at you? That's how you get stpeter angry https://www.rfc-editor.org/rfc/rfc6648.html 🤣 ↺

Seriously though no x- ever

That's why it's x. and not x-: https://www.rfc-editor.org/rfc/rfc6838.html#section-3.4

Right, but that spec does hint at using vendor-specific prefixes instead :)

But yeah, we could register a vendor specific prefix and then use that

Although it would be weird to have `vnd.xmpp.blurhash` if we're not hosting the spec or otherwise are responsible for blurhash ✏

Right. I mean, I don't know what the MIME type registration process is like, but there are several I'd like to see happen (blurhash, thumbhash, webxdc at least)

a reminder that we have our member meeting later today @19:00 UTC. if you are a member and have not voted yet on the Q2-2024 you can still do until our member meeting starts. ✏

Thanks as always, Alex!

Ping

its meeting time

Hi

Here is our Agenda for today: https://wiki.xmpp.org/web/Meeting-Minutes-2024-06-05

1) Call for Quorum

as you can see 36 members voted via memberbot, so we have a quorum

2) Items Subject to a Vote

New and Returning members, you can see all applicants here: https://wiki.xmpp.org/web/Membership_Applications_Q2_2024

3) Opportunity for XSF Members to Vote in the Meeting

any members here who have not voted yet and want to vote now?

looks like there are none

okay, then I will shutdown memberbot, and start working on the results

4) Announcement of Voting Results

when you reload the page at: https://wiki.xmpp.org/web/Meeting-Minutes-2024-06-05#Announcement_of_Voting_Results you can see the results

all applicants and reappliers are accepted

Congrats to everyone

5) Any Other Business?

👏️

looks like there is none

6) Formal Adjournment

👍️

I motion that we adjourn ✏

Thanks

thank you Alex

Thanks!

Congrats all and thanks Alex

Many thanks!

Thanks Alex!

Thanks Alex ! And welcome new member MSavoritias (fae,ve) ! 🎉