jdev - 2023-01-01


  1. EOF

    roberty0979, checking back in before i do some new years activity; however, rust is probably the least 'functional' of the bunch. xmpp (and most other things really) is very pleasant to implement with pattern matching and functional languages tend to be extremely easy to reason about. i used to write a lot of java and currently write a lot of ruby at work but would very seriously like it if the rest of the engineering staff weren't so enamored with go as the 'next step' in scaling. i've become rather sick of having to spend time figuring out just what the hell people were trying to accomplish with some of the wild stuff you see in 'OOP' or procedural/imperative languages. functional programming doesn't stop people from doing it, but it's like giving children the "big legos" so that they can't swallow them or stab each other.

  2. qy

    :)

  3. qy

    what is it that means read state doesnt sync between conv, dino, and gajim? it's chat markers that would do it right, and they all implement that?

  4. qy

    or is it that it does, but only at reconnect

  5. pep.

    qy: there's no protocol for this. Clients generally use a mix of chat markets, chatstates and maybe read receipts to work around this but that's not what they're for

  6. qy

    wow a feature that doesn't have an XEP

  7. qy

    that's a first

  8. qy

    but i feel like chat markers are right to use for this

  9. pep.

    chat markers yeah, not markets :D (autocorrection..)

  10. pep.

    qy, chat markers are destined to all recipients (your other devices included). I'd rather have something that is explicitely for your clients only.

  11. pep.

    Typically chat markers is a feature I disable for privacy reasons. I do want read state sync though

  12. pep.

    (Yes I could also hack around it with mod_firewall but not everybody has their own prosody and is knowledgeable enough to do this.)

  13. qy

    pep.; well ok, chat markers is still experimental, perhaps we can amend it and allow for configurable visibility?

  14. qy

    if done at server level, wouldn't require mass updating of clients

  15. qy

    just ejd and prosody (who even uses the rest :p)

  16. pep.

    I guess so

  17. qy

    Zash; Holger; thoughts?

  18. menel

    I think it would be important, that they don't spam the server and clients, because it would slow down bigger groups very much. I wonder if that change is to big a change.. A cleaner way would be to store it in a client controlled pep node? And other clients can look it up there?

  19. menel

    I think it would be important, that they don't spam the server and clients, because it would slow down bigger groups very much. I wonder if that change is to big a change.. A cleaner way would be to store it in an account ~client~ controlled pep node? And other clients of the same account can look it up there?

  20. qy

    and subscribe to it

  21. qy

    sounds reasonable

  22. menel

    Talking about slow transition to mix...

  23. pep.

    That's independent of mix anyway. As it should be usable in 1:1 too

  24. pep.

    Or of any groupchat component really

  25. menel

    Yes, thats nice.

  26. qy

    so, this needs an XEP?

  27. qy

    or at least us to agree on how to do it