XSF Discussion - 2024-02-05


  1. MattJ

    mathieui, (sorry for the delayed response) the current state of hats is that I updated the XEP to focus primarily on the syntax of how hats are represented. There are some examples of ad-hoc commands in there, but they are mainly examples.

  2. mathieui

    NP, I know firsthand you were kinda busy at fosdem :p

  3. MattJ

    In my experience the mechanism of hat assignment varies widely between deployments, and many do not want/need the ability to modify them (e.g. they are pulled from LDAP or some other data source)

  4. MattJ

    If we want to do some kind of "hat catalogue" and stuff like that, we can, but I think it needs to be based on actual use cases

  5. Kev

    Like Spaces? :)

  6. MattJ

    The original XEP was not really, and e.g. it defined commands for users to assign themselves arbitrary hats, which is something I think nobody wants

  7. MattJ

    Prosody has a plugin to add ad-hoc commands for MUC, but e.g. we have hats on muc.xmpp.org and we don't even have the ad-hoc commands enabled

  8. Seve

    > assign themselves arbitrary hats I haven't followed conversations about that so my bad if I'm saying the same as other people, but Discord users (if I'm not mistaken) use a similar system to put themselves in categories within a chat. Also it can provide roles as in, which rooms can you join and so on, without an admin assigning them (maybe a bot, not sure, but definitely without privileges apart from the ones of a normal user)

  9. MattJ

    From what I understand, in Discord this is usually done with a bot (which can implement restrictions on what can be self-assigned, etc.)

  10. edhelas

    Is there an actual tool to write XEPs in Markdown and convert them to the XML format ?

  11. jonasโ€™

    (there is, somewhere)

  12. edhelas

    Before working on the Stories XEP I'll work on another one that allows Pubsub/PEP services to keep track of which JID have "seen" an item.

  13. edhelas

    This is required to propose a proper experience with the Stories and allow "read" sync between clients.

  14. mathieui

    edhelas: I think Kev started the "spaces" thing with that but I don't know where the tooling is

  15. edhelas

    Pinging Kev then :)

  16. Kev

    I note that I started writing in markdown, and still haven't got a build environment that's capable of actually using the Lua scripts, so I'm not the right person to ask about this.

  17. Kev

    Maybe Zash or MattJ would be willing to pop a readme into xeps.git that says what's needed to install/setup to be able to run the scripts, and how to use them?

  18. singpolyma

    > This is required to propose a proper experience with the Stories and allow "read" sync between clients. So stories usually show you which of your contacts have viewed it?

  19. edhelas

    As well, but you don't want to read a story twice, the "read status" is important. If on your mobile you saw the latest 3 stories of your contacts you don't want to have the notification status again on your desktop :)

  20. moparisthebest

    Surely your server should store your read status? Not some remote server?

  21. edhelas

    My idea is pretty simple, send a specific read status element when requesting the Pubsub elements, and be notified by the service when the element has been read by one of my resources

  22. edhelas

    > Surely your server should store your read status? Not some remote server? This would be more complex and induce more traffic

  23. moparisthebest

    I'm not sure it would be, but it'd certainly be more private

  24. edhelas

    The Pubsub item author would then also be aware of who read their items

  25. moparisthebest

    > The Pubsub item author would then also be aware of who read their items Yes, and that seems like a bad thing

  26. edhelas

    > I'm not sure it would be, but it'd certainly be more private Both can be possible actually, and the client can choose to not add the specific tag to declare the item as read

  27. moparisthebest

    Like Twitter and reddit's recent "you must log in to read things" anti-feature

  28. edhelas

    This is not related to that thing

  29. moparisthebest

    It is if the posting server is expecting to see and record everyone who viewed it

  30. edhelas

    Again, the server already knows who had access to their items, this is by design in Pubsub. I'm just proposing to add some metadata to keep track of that and ensure that a JID can be aware that it has already accessed the item. So far I was able to do this without doing more traffic (the specific XML tag will be passed along the current Pubsub stanzas).

  31. moparisthebest

    The server routing something is different than the server storing it forever

  32. edhelas

    I might repeat myself, but if you don't want to be "tracked" by the XMPP Pubsub service for that... you just don't implement the XEP.

  33. edhelas

    I might repeat myself, but if you don't want to be "tracked" by the XMPP Pubsub service for that... you just don't implement the XEP, or don't use it (client toggle for example)

  34. moparisthebest

    >> I'm not sure it would be, but it'd certainly be more private > Both can be possible actually, and the client can choose to not add the specific tag to declare the item as read This let's the user pick between read state being synchronized or sharing what they've read with whole world, and why?

  35. moparisthebest

    Because it might be easier for some XMPP devs? To save 1kb traffic over a month? Pretty weak reasons

  36. edhelas

    > This let's the user pick between read state being synchronized or sharing what they've read with whole world, and why? Where did I said that this information is shared with the whole world ?

  37. edhelas

    > Because it might be easier for some XMPP devs? To save 1kb traffic over a month? Pretty weak reasons I can assure you that regarding the traffic that I have, it's a bit more than that

  38. moparisthebest

    Let me rewind to basics: 1. IMHO services shouldn't store any info they don't need 2. The server hosting the "story" doesn't need to know who read it, therefore it shouldn't store it

  39. singpolyma

    I'm not saying this is a useless feature to have, but it definitely seems orthogonal to the goal

  40. pep.

    "2. The server hosting the "story" doesn't need to know who read it, therefore it shouldn't store it" < Well it can, just like chatmarkers it a thing, but it's not necessary (and I would certainly deactivate it)

    ๐Ÿ‘ 1
  41. dwd

    Someone could pick up and finish PAM, and store the read information there of course.

  42. edhelas

    I see that some XEP in the inbox are now actual XEPs https://github.com/edhelas/xeps/blob/master/inbox/pubsub-social-feed.xml https://xmpp.org/extensions/xep-0472.html Is it normal to keep them there or could we "cleanup the inbox" ?

  43. pep.

    We've always kept them yeah. Someday I'd like to have a "This spec has been accepted and it now available at XXX"

  44. lbocquet

    edhelas: Not new, there is ticket about: - https://github.com/xsf/xmpp.org/issues/421

  45. moparisthebest

    Good catch, so... Do we want a redirect or text in the inbox? Personally I'd prefer a redirect. Also who gets to make the final decision? Board or ????

  46. moparisthebest

    (a redirect is also simpler and therefore more likely to be implemented)

  47. pep.

    I'm not sure a redirect is simpler. In any case you need the new spec number, and that can be used for both redirect or warning

  48. pep.

    I don't know if the inbox version is interesting to keep, technically it's exactly the same file minus a XEP number right?

  49. pep.

    If so maybe a redirect would be better yeah. Or a redirect in any case and a version in the attic?

  50. Guus

    There is a minute value in keeping the original content on the original URL. I suggested using a banner for the attic files once. That could also apply to inbox. https://github.com/xsf/xeps/issues/1266

  51. Guus

    No hill for me to die on. In inbox, a redirect works too for me.

  52. pep.

    TIL preview.xmpp.net

  53. pep.

    Is this listed anywhere

  54. Guus

    Apart from in my PR? ๐Ÿ˜

  55. pep.

    Yeah..

  56. Guus

    I dont think so

  57. moparisthebest

    My thoughts on "easier" is a script to generate nginx config vs modifying HTML, but, it's "just" different I suppose

  58. pep.

    I fear nginx rewrite is less trackable? But I'm not in iteam so.. whatever works

  59. guus.der.kinderen

    If you can prepare the script, then iteam can pick & choose what they prefer without another roundtrip

  60. lbocquet

    Note: Attic is not complete too, a lot of missing versions :/