-
nicoco
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.
-
jonas’
nicoco: I think biboumi sends type=groupchat from the MUCs bare jid
-
jonas’
and that renders sufficiently well in clients
-
nicoco
thanks jonas'!
-
nicoco
is there a XEP for group chats "pinned messages"? if not, any suggestion about how to handle them elegantly?
-
jonas’
people tend to use the <subject/> for that
-
jonas’
MIX has pinned messages IIRC
-
jonas’
(the subject is obviously limited: no encryption support, no formatting, no media embedding etc.; more IRC style)
-
pep.
And only one subject
-
pep.
Right?
-
jonas’
yes
-
pep.
You may have to write something nicoco
-
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
-
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
-
nicoco
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
-
pep.
Maybe the MUC didn't even have to be involved yeah, depending on your constraints
-
jonas’
nicoco, MIX it is then, MUC does not support that.
-
pep.
"that"?
-
jonas’
pinned messages
-
pep.
Let's define it then?
-
jonas’
or move on to a less-broken standard? :)
-
nicoco
jonas': do you think it's out of the way to submit a XEP for MUCs?
-
jonas’
nicoco, depends I guess
-
pep.
No need to switch to a whole new protocol because of one missing feature
-
jonas’
the avatar XEP got rejected by some council...
-
pep.
jonas’: yet was dumb yeah✎ -
jonas’
it was indeed
-
pep.
jonas’: that was dumb yeah ✏
-
jonas’
nicoco, you could feed the pinned messages in a pubsub node associated with the MUC to avoid having to keep them in MAM
-
jonas’
but then you're building MIX...
-
pep.
And need xeps are being submitted everyday, see bookmarks and bookmarks pinning✎ -
pep.
And new xeps are being submitted everyday, see bookmarks and bookmarks pinning ✏
-
nicoco
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.
-
pep.
jonas’: On a MUCSub node!! (316)
-
nicoco
what avatar XEP is that?
-
jonas’
nicoco, it got rejected, it has no number
-
jonas’
but essentially specifying MUC avatars
-
pep.
And it's three of them
-
nicoco
ha OK. that does work and exist though?
-
jonas’
yes
-
jonas’
devs have to find that out the hard way though
-
nicoco
are council decisions unrevokable?
-
pep.
Maybe one can resubmit it at some point :x
-
pep.
Dumb decisions like this shouldn't be
-
nicoco
in French we say "only idiots don't never change their minds" :)✎ -
nicoco
in French we say "only idiots never change their minds" :) ✏
-
jonas’
nicoco, it's tricky
-
pep.
Especially if it's not the same 5 idiots :p
-
jonas’
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
-
jonas’
then again, for protoxeps, "times are a changeling" and I guess reconsidering those should always be an option
-
nicoco
I guess it's understandable that the same decision should not be discussed at every meeting, or we never move on…
-
pep.
It depends the impact it has on the community really
-
jonas’
nicoco, I think this one would be the one to revive: https://xmpp.org/extensions/inbox/muc-avatars.html
-
jonas’
but maybe ask Link Mauve
-
nicoco
jonas': I will probably settle for what's working in gajim, movim and conversations, is that the one?
-
jonas’
I think so, but better ask someone who has implemented it
-
jonas’
i.e. talk to the respective client devs or the spec authors ( Link Mauve, edhelas if I'm reading the names right )
-
jonas’
using vcard-temp on the bare JID is what s.j.n does anyway
-
jonas’
I'm not so sure about the presence-based advertisment in that XEP really being phased out in the wild though
-
pep.
nicoco: https://modules.prosody.im/mod_vcard_muc.html that's the prosody module
-
nicoco
thanks pep.
-
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 ?
-
jonas’
pep., some stuff relies on specific semantics of @from
-
jonas’
binding another resource may work, binding another localpart, tricky.
-
jonas’
... on the specific semantics of absent @from, I meant
-
jonas’
it also seems like a footgun to implmeent✎ -
jonas’
it also seems like a footgun to implement ✏
-
jonas’
and specify
-
jonas’
to prevent any misunderstandings, you'd need a lockstep operation similar to the one used for starttls
-
MattJ
Binding multiple resources used to be a thing, but it was rarely used and added a lot of complexity
-
jonas’
binding multiple resources allows to implement MUC as a client though .... :->
-
pep.
Is there any client spawning more than one stream in their daily operation? (or any?)
-
pep.
Multi-account clients do I guess, but it's not part of one account's action
-
pep.
I'm trying to see what could make the use of features like burner-jids easier (it needs implementing for a start, for sure)
-
jonas’
I don't think so
-
jonas’
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.
-
jonas’
to more quickly and efficiently re-establish connections on network interruptions/switches
-
jonas’
but I suppose that doesn't count because the two streams would be logically the same
-
pep.
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
-
jonas’
I still stand by the (for me) rare stance that HTTP is the better way to solve that problem.
-
jonas’
likely much less resource intensive and an http client lib is likely already involved for HTTP Upload anyway.
-
pep.
I feel it's just that we're not used to do these things so it looks harder
-
jonas’
I was talking about computing resources, roundtrips, and latency, not about difficulty.
-
nicoco
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'?
-
Holger
No, ONLY those servers that support those (*) fields MUST advertise 'urn:xmpp:mam:2#extended'.
-
nicoco
Holger: thanks. isn't this contradictory with the sentence: "Six further fields are defined by this XEP and MUST be supported by servers"‽
-
moparisthebest
> "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
-
moparisthebest
Think of it as multiple TCP connections inside one TLS connection
-
Holger
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 :-)
-
nicoco
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.
-
Holger
If so then I'm missing the same something!
-
nicoco
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"