-
Neustradamus
Problem in the ML, like I have said here previously, two times for the same part "XEP-0363"
-
bantumi
good morning to everyone
-
bantumi
i have a problem
-
bantumi
anyone ca help me ? i can explain my issue ?
-
pep.
“Zash: not changing state” idempotent?
-
Zash
That's the word
-
bantumi
can i explain my issue ?
-
Zash
What's it about?
-
pep.
bantumi: don't ask to ask. I'm afraid you might not be at the right place though
-
bantumi
sorry, i'm creating a xmpp chat with iOS and Android app
-
bantumi
i implement everything
-
bantumi
on server i have ejabber installed
-
bantumi
but i have last issue with remote push notification for offline message
-
bantumi
since 2 weeks ago we use Openfire but we decide to switch to ejabber
-
bantumi
on openfire we use a plugin that redirect message to a serrver trought API and all works fine
-
bantumi
but now with ejabber i dont find any way to do the same things
-
pep.
what does that plugin do exactly? not sure I understand
-
Daniel
bantumi: ejabberd has support for xep-0357
-
bantumi
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" }
-
Daniel
It should behave roughly similar only that the communication between the push server and the xmpp server is xmpp and not http
-
bantumi
and this other our server send the request to FCM that phisically send the push to device
-
pep.
bantumi: don't think that's standard is it
-
bantumi
Daniel i know but i dont understand how to send push notification to user
-
pep.
you can probably write your own ejabberd module that does about the same thing
-
Daniel
What you call 'our server' is called 'app server' in the lingo of 357
-
Daniel
So you have to rewrite 'your server' to be a 357 app server
-
Daniel
Or use some stock 'app server' like p2
-
bantumi
https://github.com/iNPUTmice/p2
-
bantumi
this ?
-
Daniel
Yeah
-
bantumi
you are the creator !!!??? great!
-
bantumi
can you help me install this module on my server ?
-
bantumi
i try today but i have some issue
-
bantumi
we have 3 server ....
-
bantumi
1- server xmpp with openfire that we want to leave✎ -
bantumi
2- server for user details✎ -
bantumi
2- server for user details based on windows ✏
-
bantumi
3- debain server where now we install ejabber
-
bantumi
1- server xmpp with openfire that we want to leave based on windows ✏
-
Daniel
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
-
Daniel
Otherwise reading and understanding the Readme and xep 357 should bring you a long way
-
bantumi
i send you an email
-
bantumi
email sent
-
bantumi
confirm me that you receive it
-
Daniel
bantumi: Got the email. Will respond to it later today
-
bantumi
thanks a lot
-
Zash
Did we ever discuss having the server send caps for its own local componends to clients during session startup?
-
Daniel
caps as in presence?
-
Zash
Caps as in the thing that's most often sent in presence, yes
-
Zash
It can also be found in <stream:features/> sometimes
-
lovetox
yes that would be useful, would spare a few disco info requests
-
lovetox
on startup
-
Daniel
i think we discussed a need for it
-
Daniel
not that particular solution
-
lovetox
was this not in entitycaps 2
-
Zash
Not from what I can see
-
flow
Zash, we did discuss
-
eta
what are the current standards in use for client nicknames?
-
eta
(I'm implementing a transport; I tried sending <nick> in presence subscription requests but neither gajim nor conversations seemed to care)
-
Zash
Oh boy
-
Zash
There's that, usually in PEP. And vCards. And in MUC it's its own thing using the resource.
-
lovetox
eta most clients support nicks via PEP
-
lovetox
so UserNickname XEP
-
eta
lovetox, but not the <nick/> fallback in that XEP?
-
eta
I'd ideally like to avoid implementing the whole of PEP just for nicknames in my transport
-
lovetox
i think Gajim respects the nick in presence on the subscribe
-
lovetox
so it shows nick wants to subscribe to you
-
lovetox
but dont think afterwards
-
eta
ah
-
lovetox
let me look through the code
-
eta
could I get away with just sending PEP events as demonstrated in XEP-0172 on nickname changes and not implementing the whole of PEP/
-
eta
?*
-
Daniel
Yeah I think it's the same in Conversations. It supports nicks in subscribe presences.
-
Daniel
And pep
-
lovetox
hm how does you transport add the contact
-
lovetox
do you maybe send a roster item exchange ?
-
lovetox
because that has a nickname attribute and this would be pushed to the roster
-
eta
lovetox, it sends regular presence subscribe
-
eta
I must be doing something wrong then; neither Conversations nor gajim seem to like my nick in presence subscribe :<
-
eta
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>
-
lovetox
eta if you send a subscribe, a dialog in gajim pops up that says add this jid to roster
-
eta
lovetox, no it did that, just not with the nick
-
lovetox
in gajim 1.1.3?
-
eta
lovetox, reasonably fresh git, but conversations also didn't get the nick
-
lovetox
thats a bug then in Gajim
-
eta
does the stanza look okay to you?
-
lovetox
could be forgotten in the redesign of the dialog
-
lovetox
yeah looks fine
-
eta
if transports are supposed to use roster push, I can use roster push I guess
-
eta
but currently I haven't used any transport-specific APIs
-
lovetox
just leave it like that i take a look into Gajim codebase
-
lovetox
but i think this way works
-
lovetox
because if you propose the nick in the presence, we fill it on the user add to roster dialog
-
lovetox
and if the user accepts it, then the nickname is permanently in the roster saved
-
lovetox
to should be fine
-
Ge0rG
eta: you should just automatically add all transport contacts automatically, not let the user approve every one of them
-
Zash
eta: Make sure you're testing this with the client connected if you're using Prosody < trunk
-
Zash
Relevant: https://xmpp.org/extensions/xep-0144.html
-
eta
oh right, that looks like the thing I should be bothering with
-
Zash
also https://xmpp.org/extensions/xep-0321.html might be of interest
-
eta
how widely implemented is XEP-0144 though?
-
eta
I mean I know gajim does it
-
eta
but dunno about, say, conversations
-
Zash
I don't know
-
eta
hmmm
-
eta
I think it's still worth keeping the old "spam user with presence subscription" code then, no?
-
Zash
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
-
Zash
And that's the point when there'll be a whole bunch of contacts to add at once
-
Ge0rG
0321 is how spectrum does it, right?
-
Zash
Yes
-
Zash
If supported by the server (there's a prosody plugin).
-
Ge0rG
It had a great UX. Maybe just add support into conversations?
-
lovetox
144 is only good though on register
-
lovetox
afterwards if a legacy user adds you, then subscribe is probably better
-
lovetox
i think C understands 144 aswell
-
Zash
Has anyone other than Spectrum and Prosody (non-core module tho) implemented XEP-0321? @editors CFE mebbe?
-
Guus
Zash: Openfire does not.