jdev - 2025-01-20


  1. doctorhue

    hey

  2. doctorhue

    isnt there a "general" convo place

  3. moparisthebest

    doctorhue: many, check https://search.jabber.network

  4. doctorhue

    thank you

  5. edhelas removed by moderator

    privacy

  6. edhelas

    I am also limited by MySQL 3072 bytes key length

  7. edhelas

    With composed keys it means that JIDs cannot be longer than 256 or even 128 characters (in UTF8)

  8. edhelas

    I found that https://xmpp.org/extensions/xep-0029.html

  9. edhelas

    > Each allowable portion of a JID (localpart, domainpart, and resourcepart) MUST NOT be zero bytes in length and MUST NOT be more than 1023 bytes in length, resulting in a maximum total size (including the '@' and '/' separators) of 3071 bytes.

  10. edhelas

    Looks like it's not the case for the JID above

  11. Guus

    (did you anonymise those phone numbers šŸ˜¬)

  12. Guus

    I've never seen such long JIDs, but if their parts are longer than the 1023 bytes, you're probably fine throwing a steam error? It's invalid XMPP, after all.

  13. Guus

    Openfire doesn't process long JIDs either (even shorter than 1023), by the way, for similar reasons. If you look hard enough, I think you'll find an old stack overflow question ofine that is basically the duplicate of what you wrote.

  14. Link Mauve

    In every library Iā€™ve worked on, we do limit every part to 1023 bytes, according to RFC6122 section 2.1.

  15. jonasā€™

    edhelas, then mysql is probably not suited to store JIDs.

  16. Guus

    You can store them just fine. You can't put a full index on them.

  17. edhelas

    Sounds the same to me :D

  18. jonasā€™

    you need to be able to handle bare JIDs of up to 2047 bytes(!) and full JIDs of up to 3071 bytes(!).

  19. a moderator removed a message

    privacy

  20. Guus

    That value that ed posted seems to be < 3k (it's not even 300 characters?)

  21. jonasā€™

    I think so, too

  22. jonasā€™

    FTR, I've had someone moderate the initial message so that the phone numbers aren't forever archived.

  23. jonasā€™

    FTR, I've asked someone to moderate the initial message so that the phone numbers aren't forever archived.

  24. Guus

    Thanks

  25. Guus

    from a quick google, InnoDB now seems to support up to 3072 bytes as the maximum lenght of the index key, by the way.

  26. Guus

    or is that a different thing?

  27. Guus

    https://dev.mysql.com/doc/refman/9.1/en/innodb-limits.html

  28. edhelas

    > FTR, I've asked someone to moderate the initial message so that the phone numbers aren't forever archived. I've retracted the message

  29. edhelas

    > from a quick google, InnoDB now seems to support up to 3072 bytes as the maximum lenght of the index key, by the way. No that's the case, but its still complex to handle things with it

  30. Guus

    Can you split the JID up in its parts, and store it across columns maybe? I'm guessing that the variation in the local and resource-part are a lot bigger than that of the domain-part anyways.

  31. edhelas

    Guus if I do that, then I have a composed primary key... that is having the same limit ;)

  32. jonasā€™

    but 3072 bytes is enough for even full jids, so it's a non-problem?

  33. edhelas

    If you only a one constraint on it, composed primary keys can be. For example with a simple presences table like mine that can have [session_id, contact_full_jid]

  34. Guus

    Yeah, that's going to be tricky. I think something has got to give. Either you add a lot of complexity (like calculating some kind of hash for the JID, and use that to enforce a 'unique' constraint (which is imperfect), or maybe not enforce uniqueness at all in the database (and handle that in code instead) - stuff like that.

  35. Guus

    or break specs and don't support JIDs over a certain size. Openfire hasn't for two decades, I don't recall anyone ever complaining.

  36. edhelas

    Or just assume that 3072 for a JID is just too long and I don't accept those

  37. Guus

    exactly

  38. jonasā€™

    edhelas, oh!

  39. jonasā€™

    you can actually assume that

  40. jonasā€™

    at least as long as XMPP exists only in the internet

  41. jonasā€™

    DNS limits the total host name length to 255 bytes

  42. jonasā€™

    so pratically, even though allowed by RFC6122, the domain part will never be longer than 255 bytes.

  43. jonasā€™

    might break with stuff like tor though.

  44. edhelas

    Looks like that's why there was https://xmpp.org/extensions/xep-0029.html :D

  45. jonasā€™

    no, that's a predecessor of RFC6122, according to the metadata

  46. edhelas

    Ah :x

  47. jonasā€™

    or you could switch to postgresql https://www.postgresql.org/docs/current/limits.html :D

  48. kalkin

    > or you could switch to postgresql https://www.postgresql.org/docs/current/limits.html :D Just don't forget to vacuum from time to time.

  49. jjj333_p (any pronouns)

    autovaccum should run from time to time, which wont reduce the footprint but itll free up space for new db to be written to without expanding the footprint