XSF Discussion - 2024-08-21

I'll start to implement Muji in Movim, I was wondering about the state of that PR

https://github.com/xsf/xeps/pull/1139

(and the related XEP)

https://github.com/xsf/xeps/pull/1155

I'm wondering if it would be nice to also have the XEP support table directly on the XEP pages somewhere, I always naigate back to the list to check that info

https://upload.movim.eu/files/9d94237298995552fa13436420195fbca436dce7/BuzR957qQv1l/image.png

edhelas: yes, would be nice indeed. Link Mauve once had a PoC for that

Oh also I just found out that an old PR of me wasn't handled yet

https://github.com/xsf/xeps/pull/824

To me the change is pretty clear, is it possible to ping the Editors about that ? Or know what is the next step for it ?

How can XMPP ever be taken seriously unless we keep up with features like "leaking contents of private chats" https://promptarmor.substack.com/p/data-exfiltration-from-slack-ai-via smh

moparisthebest, don't worry, people are working on that, I'm sure.

The *Government* is working on mandating that.

On Swift 4 work.

Key XMPP devs out for much of Sep. So in practice start is going to be late Sep. End Oct is realistic commit, based on this start time

Steve Kille was that for this room?

In context of XEP-0198 Stream Resumption, is a server to answer 'enabled, resume=false' when a client requests to enable SM with resume?

Guus, well, that would be the server saying "hi, we can do the req/ack game, but you won't be able to resume your session, sorry"

jonas’ I'm aware that it's not very useful (then again, the client doesn't even need to request resume-functionality, which lands you in the same waters).

Guus, I'm wondering whether your original question misses a negation toward the end.

but my question is: if a client requests SM-with-resume, must the server fail rather than enable-without resume if it only can doe the req/ack dance?

ohh

now I get it.

Guus, I'd say that the server should reply with resume=false

rationale: clients must not make more than one <enable/> request per stream. so if you replied with <failed/>, they would be stuck without even req/ack ✏

rationale: clients must not make more than one <enable/> request per stream (as per XEP-0198). so if you replied with <failed/>, they would be stuck without even req/ack ✏

Ah, right, that makes sense

I don't think the XEP is overly clear here. I'll suggest a change in wording.

sounds reasonable

Thanks!

good thing I just impemented '198!

In what?

Oh, clientside?

sure

working on making stream management happen in xmpp-rs

code works, waiting for dependencies to get reviewed & merged

had the first resumed stream on sunday I think :)

I briefly assumed that everything is server-sided and was wondering what you were involved with.

:D

I know that feel

I sometimes tinker with prosody, but it already has a '198 implementation :)

https://github.com/xsf/xeps/pull/1376

Would it be possible somehow to have the TableOfContent of a XEP highlight the section that's currently being viewed? Unsure if this HTML/CSS foo is possible, but it would be a helpful feature in larger XEPs

hello, is it possible to do a sort of "redirection" or notification, if accountA receives a message, that accountB can be notified "there is a new message on accountA" ?

Yes, prosody has mod_firewall and mod_alias that can do this