XSF Discussion - 2020-04-04

Problem in the ML, like I have said here previously, two times for the same part "XEP-0363"

good morning to everyone

i have a problem

anyone ca help me ? i can explain my issue ?

“Zash: not changing state” idempotent?

That's the word

can i explain my issue ?

What's it about?

bantumi: don't ask to ask. I'm afraid you might not be at the right place though

sorry, i'm creating a xmpp chat with iOS and Android app

i implement everything

on server i have ejabber installed

but i have last issue with remote push notification for offline message

since 2 weeks ago we use Openfire but we decide to switch to ejabber

on openfire we use a plugin that redirect message to a serrver trought API and all works fine

but now with ejabber i dont find any way to do the same things

what does that plugin do exactly? not sure I understand

bantumi: ejabberd has support for xep-0357

pep. this plugin is called "CallbackOnOffline" that send a json to another server with this format { "token":"21uh9d1h91d", "from":"user@mychatapp.com", "to":"user123@mychatapp.com", "body":"Message body, so what user's typed" }

It should behave roughly similar only that the communication between the push server and the xmpp server is xmpp and not http

and this other our server send the request to FCM that phisically send the push to device

bantumi: don't think that's standard is it

Daniel i know but i dont understand how to send push notification to user

you can probably write your own ejabberd module that does about the same thing

What you call 'our server' is called 'app server' in the lingo of 357

So you have to rewrite 'your server' to be a 357 app server

Or use some stock 'app server' like p2

https://github.com/iNPUTmice/p2

this ?

Yeah

you are the creator !!!??? great!

can you help me install this module on my server ?

i try today but i have some issue

we have 3 server ....

2- server for user details based on windows ✏

3- debain server where now we install ejabber

1- server xmpp with openfire that we want to leave based on windows ✏

If you look up my contact details on the internet and send me an email I can give you a cost estimate for commercial support for p2

Otherwise reading and understanding the Readme and xep 357 should bring you a long way

i send you an email

email sent

confirm me that you receive it

bantumi: Got the email. Will respond to it later today

thanks a lot

Did we ever discuss having the server send caps for its own local componends to clients during session startup?

caps as in presence?

Caps as in the thing that's most often sent in presence, yes

It can also be found in <stream:features/> sometimes

yes that would be useful, would spare a few disco info requests

on startup

i think we discussed a need for it

not that particular solution

was this not in entitycaps 2

Not from what I can see

Zash, we did discuss

what are the current standards in use for client nicknames?

(I'm implementing a transport; I tried sending <nick> in presence subscription requests but neither gajim nor conversations seemed to care)

Oh boy

There's that, usually in PEP. And vCards. And in MUC it's its own thing using the resource.

eta most clients support nicks via PEP

so UserNickname XEP

lovetox, but not the <nick/> fallback in that XEP?

I'd ideally like to avoid implementing the whole of PEP just for nicknames in my transport

i think Gajim respects the nick in presence on the subscribe

so it shows nick wants to subscribe to you

but dont think afterwards

ah

let me look through the code

could I get away with just sending PEP events as demonstrated in XEP-0172 on nickname changes and not implementing the whole of PEP/

?*

Yeah I think it's the same in Conversations. It supports nicks in subscribe presences.

And pep

hm how does you transport add the contact

do you maybe send a roster item exchange ?

because that has a nickname attribute and this would be pushed to the roster

lovetox, it sends regular presence subscribe

I must be doing something wrong then; neither Conversations nor gajim seem to like my nick in presence subscribe :<

my stanza looks like: <presence from="REDACTED@ig.theta.eu.org" id="71de7ae4-2dc4-4e69-9c2d-536474106c49" to="eta@theta.eu.org" type="subscribe"><status>I'm someone from your WhatsApp contacts! (via whatsxmpp)</status><nick xmlns="http://jabber.org/protocol/nick">eta</nick></presence>

eta if you send a subscribe, a dialog in gajim pops up that says add this jid to roster

lovetox, no it did that, just not with the nick

in gajim 1.1.3?

lovetox, reasonably fresh git, but conversations also didn't get the nick

thats a bug then in Gajim

does the stanza look okay to you?

could be forgotten in the redesign of the dialog

yeah looks fine

if transports are supposed to use roster push, I can use roster push I guess

but currently I haven't used any transport-specific APIs

just leave it like that i take a look into Gajim codebase

but i think this way works

because if you propose the nick in the presence, we fill it on the user add to roster dialog

and if the user accepts it, then the nickname is permanently in the roster saved

to should be fine

eta: you should just automatically add all transport contacts automatically, not let the user approve every one of them

eta: Make sure you're testing this with the client connected if you're using Prosody < trunk

Relevant: https://xmpp.org/extensions/xep-0144.html

oh right, that looks like the thing I should be bothering with

also https://xmpp.org/extensions/xep-0321.html might be of interest

how widely implemented is XEP-0144 though?

I mean I know gajim does it

but dunno about, say, conversations

I don't know

hmmm

I think it's still worth keeping the old "spam user with presence subscription" code then, no?

Hm, during transport setup you know the full JID of the user doing the thing, so you can find out via disco#info if they understand '144

And that's the point when there'll be a whole bunch of contacts to add at once

0321 is how spectrum does it, right?

Yes

If supported by the server (there's a prosody plugin).

It had a great UX. Maybe just add support into conversations?

144 is only good though on register

afterwards if a legacy user adds you, then subscribe is probably better

i think C understands 144 aswell

Has anyone other than Spectrum and Prosody (non-core module tho) implemented XEP-0321? @editors CFE mebbe?

Zash: Openfire does not.