XSF Discussion - 2023-03-15

jonas’: “It does support some kind of sticker-y feature, but in a protocol nobody else speaks” re pidgin, Movim does!

oh nice

Poezio also does! (Enough to say "we don't support this" :p)

Didn't Pidgin calls sorta work with Gajim, Dino etc?

jonas’: Obligatory "achshually" ;)

Yeah it's probably for the best if this post isn't corrected anymore. Movim will probably be one of the first to support new stickers anyway :p ✏

btw I have submitted https://github.com/xsf/xeps/pull/1275, I hope that might be of interest to some. goffi? (poked e.dhelas already)

Anyody else doing pubsub? (that's everybody)

hi ✏

pep.: there is a typo at https://github.com/xsf/xeps/pull/1275/files#diff-0ede34e71ae8ea7199b84fe09913b235f648e79c1549a055b3ddd90fee3211f8R2997 ("the service MUST theN retract")

otherwise, looks good to me.

For MAM, implementing the hints in XEP-0334 seems to introduce archives that have partial coverage of certain types - depending on the client that sent the message (and if it supports those hints). Is that preferable over a server-sided configuration that says "always (or never)" store a message without a body but with a child element of type XYZ?

(did that question make sense? it did in my head)

I think server-side rules are generally good, yes, but they aren't discoverable and may lag behind. If a new XEP is written tomorrow and we do/don't want that in MAM, hints can help with that.

or custom extensions that aren't XEPs, used with servers that don't understand those namespaces

I'm wondering if having _some_ clients having their empty-bodied messages stored in MAM, is introducing more confusion than having either all or none of them do that. That probably only applies to MUC archives though.

Should we advertise some kind of feature(s) wrt MAM rules?

Zash: like `<feature var='urn:xmpp:carbons:rules:0'/>`?

Kinda, sorta.

goffi, thanks! Nothing to say about "the only two options"?

Stuff I mention in the mail to standards