XSF Discussion - 2024-02-15


  1. Wirlaburla

    I noticed XEP-0191 has nothing about MUCs in it, so JIDs from blocked users in non-anon rooms aren't blocked even though we know their JID and its blocked. The JID from the MUC has to be blocked. Shouldn't there be a better way to do this or am I missing something?

  2. singpolyma

    Wirlaburla: blocking someone isn't really the same thing as killfiling them. You don't really want to go into a channel and just be missing random messages and not know why

  3. singpolyma

    well, maybe you do, but many people do not

  4. Wirlaburla

    Then in that case, I feel like it should be optional.

  5. Wirlaburla

    Because in some cases, it'd be useful. I've had some cases where people I wanted to mute from a MUC had changed their nicks just to get around my block.

  6. Wirlaburla

    Add extra option to blocklist that defaults to no if not in stanza for blocking from mucs. ez pz.

  7. Wirlaburla

    Add extra option to blocklist that defaults to false if option isn't defined in stanza for blocking from mucs. Ez pz.

  8. singpolyma

    Yes for sure, a way to mute someone in a MUC would be useful, but I think this is seperate from block command. And we can make it work even in semi-anon muc using occupant id

  9. moparisthebest

    > Wirlaburla: blocking someone isn't really the same thing as killfiling them. You don't really want to go into a channel and just be missing random messages and not know why IRC /ignore disagrees, but yes I agree clients need a good way to do this (that also works for messages from mam)

  10. Wirlaburla

    I honestly think it should be server-sided, as blocking seems to be aleady.

  11. Wirlaburla

    » [22:08:14] <singpolyma> Yes for sure, a way to mute someone in a MUC would be useful, but I think this is seperate from block command. And we can make it work even in semi-anon muc using occupant id Forgive me but I'm still learning the protocol. If we already have occupant IDs, why not revise the Blocking command to support them?

  12. Wirlaburla

    That way it is a choice if we don't want to see their messages in a MUC.

  13. Wirlaburla

    Instead of having to hope they don't go through a username change or be a bother in another.

  14. singpolyma

    Because occupant IDs are per-muc, and blocking command is for non-muc

  15. singpolyma

    they're just two totally different things that's alll

  16. singpolyma

    they're just two totally different things that's all

  17. Wirlaburla

    Alright.

  18. Wirlaburla

    Well maybe my ideas got to a professional so I'll let them do whatever. I'm still trying to learn the ins and outs of this protocol.

  19. MSavoritias fae.ve

    > singpolyma: no, just that: > 1. Rejecting files based on file extension is gonna be wrong > 2. Rejecting them on mimetype returned by server is gonna be wrong > 3. Basically have to download (being wary of all https attacks, unlimited length, massive length, zipbomb, unlimited headers, slowloris etc etc etc) and then super carefully determine validity itself is there somewhere a guide for how to be wary or what these are (the attacks that is)?

  20. MSavoritias fae.ve

    or is it just a bunch of different pages in different places

  21. Wirlaburla

    Just go through the process imagining that every single thing that can go wrong can and will.

  22. MSavoritias fae.ve

    ah great :P

  23. nicoco

    I think there is an inconsistency between the text in https://xmpp.org/extensions/xep-0424.html#tombstones and the schema in section #9. > a <retracted/> element which MUST include an 'id' attribute referring to the original message and then in the schema there is no 'id' attribute defined for the <retracted> element. Do I not understand something or is this a mistake indeed?

  24. mathieui

    nicoco: examples are not authoritative (but carry more weight than the text to most readers anyway :p)

  25. nicoco

    I've fallen in this trap before, but I'm not talking about any example here, just the body of the XEP and the XML Schema :o)

  26. nicoco

    Or is the XML Schema considered an "example"? I would have thought this was the highest level of authoritativity (hmmm that word probably does not exist).

  27. nicoco

    Or is the XML Schema considered an "example"? I would have thought it was the highest level of authoritativity (hmmm that word probably does not exist).

  28. mathieui

    Ah, no

  29. mathieui

    But our XML schemas often have bugs (and are not always provided, or sufficient for validating payloads) đź«Ł

  30. nicoco

    BTW, I haven't followed all discussions (and maybe don't receive all emails from the mailing lists anymore?), but if I want to fix that inconsistency, is the process still to discuss it in the mailing list first or is it OK to just open a PR about it?

  31. nicoco

    Also, I fail to understand what is the purpose of the "from" attribute of the <retracted> element? It's optional, but what is supposed to be in it and when does it make sense to write something in there?

  32. Daniel

    nicoco: mailing list is still the way to go

  33. Daniel

    PRs or rendered XEPs only assist in helping others understand

  34. nicoco

    Thanks for the one-liner summary :-)

  35. nicoco

    PRs also help in getting the actual updating work done, don't they?

  36. Daniel

    > PRs also help in getting the actual updating work done, don't they? I guess. Although that's really the authors job. Idk we (as a community) started to do this for clearly abandoned XEPs and then this escalated to 'a lot of xeps'

  37. Daniel

    XEPs aren't supposed to be abandoned. If they are we need a new author...

  38. Daniel

    But yes everyone is a volunteer so yeah PRs don't hurt in practice

  39. Daniel

    But it's not necessarily how the process (tm) is supposed to work

  40. nicoco

    Thanks for the details. So we have a new fancy UI for the mailing lists, looks good. I'm waiting for the confirmation email, maybe that takes time, I'll ping here again if I still have nothing in my inbox or junk folder in a few hours…

  41. MattJ

    In case anyone missed it, there was an interview with someone from WhatsApp about their plans for DMA compliance: https://www.wired.com/story/whatsapp-interoperability-messaging/

  42. MattJ

    The word "stanza" is right in there :)

  43. MattJ

    Specifically: > To send messages, third-party apps will need to encrypt content using the Signal Protocol and then package it into message stanzas in the eXtensible Markup Language (XML). When receiving messages, apps will need to connect to WhatsApp’s servers.

  44. MattJ

    So it seems like they're doing the minimum effort approach - just documenting their c2s protocol

  45. Daniel

    > “We think that the best way to deliver this approach is through a solution that is built on WhatsApp’s existing client-server architecture,” That's by the way wait I said here https://gultsch.social/@daniel/111528938093114289

  46. Daniel

    Almost as if _someone_ had read their 'api specification'

  47. MattJ

    :)

  48. MattJ

    But MIMI is, meanwhile, discussing how to make groups work when they consist of participants from multiple services

  49. MattJ

    There are significant challenges in such a thing, but it's not clear how a c2s-only approach would satisfy that requirement (if indeed it's interpreted strongly as a requirement of the DMA)

  50. Schimon

    Andriy Utkin, greeting! It is good to see you are here too :)

  51. Schimon

    singpolyma, do you know if it is possible to add menu items? I mean, move to the next dialog upon a click on an item, without having to click on "next" button. I suppose that would be significant to the feeling off topic of experiencing the bot. P.S. Psi does require to *select* and item from Command List *and* then *click* on "Execute", unlike Cheogram and Gajim which only require to *select* an item from Command List.

  52. Schimon

    My use case: Instead of having several menues for listing subscriptions: "Subscriptions", "Categories", "Index", "Tags", I intend to have only menu "Subscriptions" and it that (next) dialog there would be a selection of "All", "Categories", "Index", "Tags". So I figure it would be nice to have these items to behave like the Command List menu, without having to click on button "next".

  53. Schimon

    My use case: Instead of having several menues in Command List for listing subscriptions: "Subscriptions", "Categories", "Index", "Tags", I intend to have only menu "Subscriptions" and it that (next) dialog there would be a selection of "All", "Categories", "Index", "Tags". So I figure it would be nice to have these items to behave like the Command List menu, without having to click on button "next".

  54. Schimon

    My use case: Instead of having several menues in Command List for accessing subscriptions: "Subscriptions", "Categories", "Index", "Tags", I intend to have only menu "Subscriptions" and it that (next) dialog there would be a selection of "All", "Categories", "Index", "Tags". So I figure it would be nice to have these items to behave like the Command List menu, without having to click on button "next".

  55. Schimon

    My use case: Instead of having several menues in Command List for accessing subscriptions: "Subscriptions", "Categories", "Index", "Tags", I intend to have only menu "Subscriptions" and in that (next) dialog there would be a selection of "All", "Categories", "Index", "Tags". So I figure it would be nice to have these items to behave like the Command List menu, without having to click on button "next".

  56. pep.

    > nicoco> Or is the XML Schema considered an "example"? I would have thought it was the highest level of authoritativity Yeah no schema are also non-normative :(

  57. moparisthebest

    It's ok examples/schemas in RFCs also don't validate lol

  58. MSavoritias fae.ve

    are we sure we create standards in here oO

  59. dwd

    MSavoritias fae.ve, I'm sure we don't. We propose them, at best.

  60. pep.

    Otoh, schemas don't support all cases either..

  61. pep.

    (nor other schema solutions, DTD and all)

  62. pep.

    (neither do other schema solutions, DTD and all)

  63. singpolyma

    Schimon: yes, deliver a form with only a single field that is list-single and cheogram android will do what you want

  64. Schimon

    I will definitely try!