-
doctorhue
hey
-
doctorhue
isnt there a "general" convo place
-
moparisthebest
doctorhue: many, check https://search.jabber.network
-
doctorhue
thank you
-
edhelas
removed by moderator
privacy
-
edhelas
I am also limited by MySQL 3072 bytes key length
-
edhelas
With composed keys it means that JIDs cannot be longer than 256 or even 128 characters (in UTF8)
-
edhelas
I found that https://xmpp.org/extensions/xep-0029.html
-
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.
-
edhelas
Looks like it's not the case for the JID above
-
Guus
(did you anonymise those phone numbers š¬)
-
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.
-
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.
-
Link Mauve
In every library Iāve worked on, we do limit every part to 1023 bytes, according to RFC6122 section 2.1.
-
jonasā
edhelas, then mysql is probably not suited to store JIDs.
-
Guus
You can store them just fine. You can't put a full index on them.
-
edhelas
Sounds the same to me :D
-
jonasā
you need to be able to handle bare JIDs of up to 2047 bytes(!) and full JIDs of up to 3071 bytes(!).
-
a moderator
removed a message
privacy
-
Guus
That value that ed posted seems to be < 3k (it's not even 300 characters?)
-
jonasā
I think so, too
-
jonasā
FTR, I've had someone moderate the initial message so that the phone numbers aren't forever archived.✎ -
jonasā
FTR, I've asked someone to moderate the initial message so that the phone numbers aren't forever archived. ✏
-
Guus
Thanks
-
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.
-
Guus
or is that a different thing?
-
Guus
https://dev.mysql.com/doc/refman/9.1/en/innodb-limits.html
-
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 ↺
-
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 ↺
-
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.
-
edhelas
Guus if I do that, then I have a composed primary key... that is having the same limit ;)
-
jonasā
but 3072 bytes is enough for even full jids, so it's a non-problem?
-
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]
-
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.
-
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.
-
edhelas
Or just assume that 3072 for a JID is just too long and I don't accept those
-
Guus
exactly
-
jonasā
edhelas, oh!
-
jonasā
you can actually assume that
-
jonasā
at least as long as XMPP exists only in the internet
-
jonasā
DNS limits the total host name length to 255 bytes
-
jonasā
so pratically, even though allowed by RFC6122, the domain part will never be longer than 255 bytes.
-
jonasā
might break with stuff like tor though.
-
edhelas
Looks like that's why there was https://xmpp.org/extensions/xep-0029.html :D
-
jonasā
no, that's a predecessor of RFC6122, according to the metadata
-
edhelas
Ah :x
-
jonasā
or you could switch to postgresql https://www.postgresql.org/docs/current/limits.html :D
-
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.
-
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