jdev - 2020-10-05

hi guys, can any one help me on best xmpp client to use in react native application?

chr: there is no ready-made client with UI, but you can use xmpp.js

hi can we add xmpp to laravel 5+?

or we want to use any nodejs and react js only?

I might've asked, is there anything on par with xmpp.js for typescript?

marmistrz: I'm not aware.

https://github.com/legastero/stanza mayhaps

bala to Laravel ?

(author of xmpp.js here) xmpp.js has the best RN support AFAIK but is very low level compared to stanza https://github.com/legastero/stanza/blob/master/docs/React_Native.md

if you're not that familiar with xmpp or need builtin TypeScript I'd recommend stanza

some people have shared their TypeScript definition for xmpp.js https://github.com/xmppjs/xmpp.js/issues/542

hm is just a localpart a valid JID?

hm my parsing logic says JID("asd")

is a valid jid

what JID parsing rule should prevent that?

lovetox: not

ah i think its recognized as domainpart

and IDN2008 allows that?

a domain is a valid jid

hm yes seems its a valid domain

yes is know

but i didnt think "asd" is a valid domain

seems i was wrong

why wouldn’t it be?

because a rule exists that says otherwise

with the ICANN going wild with gTLDs, you can't sensibly restrict what a domain name is.

Also you can have local hostnames without a TLD

and things like xmpp.server.local

or localhost

and IP addresses.

IP addresses are legitimate XMPP domains.

lovetox> but i didnt think "asd" is a valid domain it is a valid DNS name

it's mapped to "asd." fwiw

yes edhelas

laravel

bala laravel is mostly an async framework, good for rest and stuff like that

if you want to do XMPP stuff in PHP there's not a lot of choices afaik

okay edhelas thank you very much.

where do you want your XMPP connection to sit ? server side or browser side ?

edhelas need both

🤔

We need to integrate chat feature on our mobile app.

How can we get started with XMPP?

what is your mobile app architecture ?

We are going to have iOS and android apps. What do you mean by architecture in specific?

well, so two native apps, with a REST backend ?

Yes,Its a Rest backend

the app is an enterprise one, with different types of users.

We need to enable chat among users.

and the android app and ios app are writen in Java/Kotlin/Swift/ObjectiveC ?

Yes, exactly. Java for Android and Swift for iOS

well, then I advise you to use native Java and Swift XMPP libraries then :)

you'll have to figure out how to create accounts/authenticate them in sync with your REST accounts ones

why ?

Well.We need to integrate XMPP on our backend, right? ✏

is you backend connecting with other XMPP servers ?

what is the goal of XMPP here for you ?

nope. We need an XMPP server which can be used for iOS and Android apps, right

For user creation, maintaining chat history and all

how can we configure our XMPP server?

so this xmpp server will be standalone, and it's only for those app users to communicate together

then you setup the XMPP server next to your REST app, with ejabberd you can create/configure accounts using their internal REST API directly https://docs.ejabberd.im/developer/ejabberd-api/

and you add a native XMPP lib in your mobile apps to connect to those accounts

the only big thing I see is to figure out how to authenticate properly using server generated accounts

okay thank you very much edhelas

on the backend, you can use ejabberd with https://github.com/processone/ejabberd-contrib/tree/master/ejabberd_auth_http or an other xmpp server supporting some kind of similar integration

sonny 👍

edhelas 👍

so domain.org is a bare jid?

lovetox, yes

domain.org/foo is a full-jid

ok do we have a name for localpart@domainpart ?

that’s also a bare jid

yeah, but library wise, if i want to test for localpart@domainpart, what would i call that method

is_bare_with_domain sounds a bit long

has_local_part?

(what do you need that test for, anyway?)

that does not exclude that it has a resource part..

And http://www.example.com/ is a horror (host="http:",resource="/www.example.com/") ✏

sometimes for example for bookmarks

what do bookmarks have to do with that?

it makes no sense if a jid as a resource, or is only domainpart

a bookmark should be localpart@domainpart

why?

because thats how it is, only domain can not be a room

and resource describes a certain resource

that’s wrong

a domain can be a room

XEP-0045 forbids it IIRC?

Each room is identified as a "room JID" <room@service>

either way, I don’t think it’s the job of clients to enforce that, unless it makes things more complicated to *not* enforce it

and I think in this case, it might be more complicated to enforce it that not enforcing it

as i said i was talking from a library standpoint

i just wanted a name for a property that reflects that this

I was curious and asking because I haven’t had use for such a property yet

I think I’d just use jid.is_bare and not jid.has_localpart or something like that

it seems like a rare use case

is_bare := not has_resource ?

yeah, thats what i was using, just was curious if there is a technical name for that

or .. :-?

but it seem it is not

Zash, yes

lovetox, here are the terms that jxmpp uses: https://github.com/igniterealtime/jxmpp#jxmpp-jid beware, you may not like them

http://jxmpp.org/releases/1.0.1/javadoc/org/jxmpp/jid/Jid.html has some examples

thanks flow

jid-rs uses only FullJid and BareJid (and Jid { Full(FullJid), Bare(BareJid) })

pep., then your API methods can't express that they require a full jid with localpart as argument, right?

Not for the moment no, because we haven't found a place where it's necessary yet

But also the xmpp library on top isn't really much used..

> because we haven't found a place where it's necessary yet MUC room addresses?

I don't think it's necessary there

I don't really want to enforce this weird restriction

(that was bascially one major motivation behind jxmpp's jid types) ✏

which weird restriction?

bbl

flow, I'm not sure why there should be a MUC component on top of a room, for example. You can disco the room itself and be just fine

(that is, not sure why you'd require a localpart to a room)

I also think that semantically, there is little difference between foo@bar and bar

not enough to enforce it on the type system level anyways

yeah

When I got xmpp.rs I wanted to have both chat@xmpp.rs (MUC room) and bot@xmpp.rs (user account, and other accounts), because it's cool and I don't see why I shouldn't be allowed to. And while it's technically possible I've seen pain around chat@dino.im and.. :x

Technically it's only really an issue for me operator. there's no issue as long as I control what gets into this namespace (xmpp.rs)

Note that this is not exactly the issue described above, but it's the kind of things that people are afraid to do because it doesn't fit exactly what the protocol mandates for weird reasons

well, there is a reason why that doesn’t work

or why it’s painful

it boils down to "how should clients discover rooms"

the written-down protocol is that it queries via disco#items and disco#info until it finds a MUC service associated with a domain, and then it uses disco#items to find rooms

subdomains are cheap, hence there’s no problem with that

"it boils down to "how should clients discover rooms" < that feels like UX straight from the 90s

with /list

all of MUC is UX from the 90ies

Yeah, so by nowadays' standards some things are weird :)

fair enough

It's not like xmpp.rs was going to host real users anyway, mostly utilities or contributors. You don't end up on chat@xmpp.rs because you found it with /list :p

Same for dino.im really

"not real users […], mostly […] contributors"

Will clients refuse to talk to user@host if host advertises the muc feature?

Welll, only a few select, not like, users you want to give proper care to because they don't understand anything about the protocol :) ✏

jonas’, we all know developers are not real users

Zash, I hear that poezio does strange things w.r.t. muc feature

Look at their clients

pep., hah

hmm I think the thing has been fixed in poezio(?)

Ah wait, no I don't remember anything about this

There was stuff related to carbons and muc lately but that's about it

(because detecting PMs is meh)

yeah, that was based on disco#info on the domain (incorrectly)

yes

Exactly this :)

The one place I'd see requiring a MUC service is when a client wants to create new rooms

quick question - should we be concerned with lenght of the stanza id? from what I gather schema doesn't limit it...

I think it's profanity that has immensely long IDs. Some kind of HMAC iirc

Wojtek, there is no specified limit beyond the limit of th eoverall stanza

I suggest to limit it to 1023 utf-8 bytes (or codepoints, if that’s easier for you) if you have to place a limit

it’s the same limit as resource and localpart have

yeah, but that's not specified, and someone may decide well I wannna have longer IDs. would have been nice to have this in the specs IMHO

> it’s the same limit as resource and localpart have yeah, that seems reasonable

Which spec?

6120?

Wojtek, yeah, it would be nice to have a limit written down in '6120

yup

> https://github.com/legastero/stanza mayhaps thanks!

> When I got xmpp.rs I wanted to have both chat@xmpp.rs (MUC room) and bot@xmpp.rs (user account, and other accounts) I also like that, but I don't see how this is related to a MUC address being a bare jid with a localpart

Wojtek> yeah, but that's not specified, and someone may decide well I wannna have longer IDs. Then you should be worried about pub sub item IDs and (pubsub/xep30/…) node name length too

Just say 1023 octets

like JID parts

Zash, note sure that simply saying it helps if we don't specify it

Someone once mentioned this issue wrt 'node' in disco and/or pubsub

we could, at least, start with recommending size limits for xep359 IDs, pubsub item IDs, and node names ✏

and lack of normalization specs

a lack of unicode normalization specs?

yes

aren't there like, a dozen of them

I mean, for stanza ids, nodes etc

apply NFC and ensure that length in codepoints is less than X?

for example

leaves the question what X sould be

1023 octets!

is there an argument for less?

where do 1023 come from anyway?

The parts of a JID

(i know it's in the jid rfc, but where does that come from?)

🤷

historical raisins?

so cargo cult at its finest

I prefer to call it Consistency

You could also argue that the limit should be 37

sure, and if nobody comes up with an argument that the limit should be different, i'd also go with conistency

which iirc is the size of the textual form of an UUID

but I could imagine that database people may have a strong feeling about the length of the primary key type

In the case of MySQL it's 20

Or 700 something.

37 seems to low, at least for node names and item IDs, as these are sometimes used to carry a little bit of text with them

are node names meant to be human-readable?

If so then fun concerns apply

duno, but there where at least two people who worked on a filesystem in pubsub

so it does not appear to be far fetched that node names are user entered strings

in some use-cases

and we don't want to be the DOS of instant messaging

cmon, no one?

Filenames on Linux are limited to 256 octets

... and can contain arbitrary binary except NUL and '/'

Or just ignore the whole thing and if you need to store arbitrary-sized IDs in your database you jam them trough a hash function

sure, but meh

effectively what jabbercat does

because of the aforementioned limit