jdev - 2022-12-26

is there a dedicated mechanism for "messages sent by the room itself" in MUCs? something like "system messages"? maybe by using msg type="headline"? my workaround so far is using a pseudo-participant, but I wonder if there is something dedicated for this.

nicoco: I think biboumi sends type=groupchat from the MUCs bare jid

and that renders sufficiently well in clients

thanks jonas'!

is there a XEP for group chats "pinned messages"? if not, any suggestion about how to handle them elegantly?

people tend to use the <subject/> for that

MIX has pinned messages IIRC

(the subject is obviously limited: no encryption support, no formatting, no media embedding etc.; more IRC style)

And only one subject

Right?

yes

You may have to write something nicoco

I was thinking about the subject, yes, but in telegram there can be several pinned message. I guess I could chain them in the subject; but it does not feel right as there is also a concept of "group name/group subject" that maps more naturally to MUCs

"how hard would it be" to allow binding another jid midstream? And using it alongside the first one. I'm thinking this might be more useful than opening another stream (burner jids, multiplexing c2s? what else?). As I've never really heard of clients doing this

pep: I guess it should not be too much work, spec-wise, to define "pinned messages" as a new mucconfig entry, then rely on MAM for clients to fetch the pinned messages. the problem I see is that we should make sure somehow that pinned message are not purged from the archive? or maybe we should not care, if room admins pin a message not in the archive, it's their problem. this needs some thinking I guess

Maybe the MUC didn't even have to be involved yeah, depending on your constraints

nicoco, MIX it is then, MUC does not support that.

"that"?

pinned messages

Let's define it then?

or move on to a less-broken standard? :)

jonas': do you think it's out of the way to submit a XEP for MUCs?

nicoco, depends I guess

No need to switch to a whole new protocol because of one missing feature

the avatar XEP got rejected by some council...

it was indeed

jonas’: that was dumb yeah ✏

nicoco, you could feed the pinned messages in a pubsub node associated with the MUC to avoid having to keep them in MAM

but then you're building MIX...

And new xeps are being submitted everyday, see bookmarks and bookmarks pinning ✏

FWIW, I would like to add MIX support too maybe, but I just don't use any client that supports it. I know it's a chicken-and-egg problem, but I am too much of an amateur dev to release something that I cannot battle test a little for my own use.

jonas’: On a MUCSub node!! (316)

what avatar XEP is that?

nicoco, it got rejected, it has no number

but essentially specifying MUC avatars

And it's three of them

ha OK. that does work and exist though?

yes

devs have to find that out the hard way though

are council decisions unrevokable?

Maybe one can resubmit it at some point :x

Dumb decisions like this shouldn't be

in French we say "only idiots never change their minds" :) ✏

nicoco, it's tricky

Especially if it's not the same 5 idiots :p

there was one situation where council considered reconsidering a decision of previous council, but they were a bit cautious to set a precedent for that

then again, for protoxeps, "times are a changeling" and I guess reconsidering those should always be an option

I guess it's understandable that the same decision should not be discussed at every meeting, or we never move on…

It depends the impact it has on the community really

nicoco, I think this one would be the one to revive: https://xmpp.org/extensions/inbox/muc-avatars.html

but maybe ask Link Mauve

jonas': I will probably settle for what's working in gajim, movim and conversations, is that the one?

I think so, but better ask someone who has implemented it

i.e. talk to the respective client devs or the spec authors ( Link Mauve, edhelas if I'm reading the names right )

using vcard-temp on the bare JID is what s.j.n does anyway

I'm not so sure about the presence-based advertisment in that XEP really being phased out in the wild though

nicoco: https://modules.prosody.im/mod_vcard_muc.html that's the prosody module

thanks pep.

> pep> "how hard would it be" to allow binding another jid midstream? And using it alongside the first one. I'm thinking this might be more useful than opening another stream (burner jids, multiplexing c2s? what else?). As I've never really heard of clients doing this ?

pep., some stuff relies on specific semantics of @from

binding another resource may work, binding another localpart, tricky.

... on the specific semantics of absent @from, I meant

it also seems like a footgun to implement ✏

and specify

to prevent any misunderstandings, you'd need a lockstep operation similar to the one used for starttls

Binding multiple resources used to be a thing, but it was rarely used and added a lot of complexity

binding multiple resources allows to implement MUC as a client though .... :->

Is there any client spawning more than one stream in their daily operation? (or any?)

Multi-account clients do I guess, but it's not part of one account's action

I'm trying to see what could make the use of features like burner-jids easier (it needs implementing for a start, for sure)

I don't think so

I considered adding a feature to aioxmpp where it would try to establish a fresh stream if the existing one went to looking dead for some reason, and then do a stream-management based failover if that succeeded.

to more quickly and efficiently re-establish connections on network interruptions/switches

but I suppose that doesn't count because the two streams would be logically the same

Yeah, to put in context, we were discussing queries to s.j.n with jonas’ in another channel and that made me wonder if it was possible not to use the current stream but burner jid or sasl anon just for the query

I still stand by the (for me) rare stance that HTTP is the better way to solve that problem.

likely much less resource intensive and an http client lib is likely already involved for HTTP Upload anyway.

I feel it's just that we're not used to do these things so it looks harder

I was talking about computing resources, roundtrips, and latency, not about difficulty.

something boggles me in https://xmpp.org/extensions/xep-0313.html#filter: > Six further fields are defined by this XEP and MUST be supported by servers [...] > start, end, with, before-id (*),after-id (*),ids (*) > Servers supporting fields marked with an asterisk (*) MUST advertise the disco feature 'urn:xmpp:mam:2#extended' Do I understand it right that all servers MUST implement all 6, so all servers must advertise both 'urn:xmpp:mam:2' and 'urn:xmpp:mam:2#extended'? There is no case where a server only advertise 'urn:xmpp:mam:2'?

No, ONLY those servers that support those (*) fields MUST advertise 'urn:xmpp:mam:2#extended'.

Holger: thanks. isn't this contradictory with the sentence: "Six further fields are defined by this XEP and MUST be supported by servers"‽

> "how hard would it be" to allow binding another jid midstream? And using it alongside the first one. I'm thinking this might be more useful than opening another stream (burner jids, multiplexing c2s? what else?). As I've never really heard of clients doing this pep.: this is one of the advantages of QUIC, you can open unlimited independent streams in the encryption context you already have started, and no head of line blocking etc

Think of it as multiple TCP connections inside one TLS connection

nicoco: Ah sorry, you're right. End result is the same though: Older revisions of the XEP used the mam:2 namespace but didn't have those fields, hence the separate :2#extended feature, so clients wanting to use them must check for that feature. So I'm not sure that MUST has any effect :-)

Holger: thanks! I also tought that the end result was the same and this "MUST" is weird, but was wondering if I was missing something.

If so then I'm missing the same something!

wild guess: this "MUST" means "servers REALLY REALLY REALLY SHOULD implement all 6, but there are implementations supporting only the first 3 out there, let's not shame them by calling them non-compliant"