Conversations / XMPP as Provider

[genofire]

I have already a permanent connection to my XMPP-Server on my device.

[genofire]

I would write an XMPP-Component as UP-Server. If somebody else write the provider.

[p1gp1g]

The distributor may be done via a MAXS module. The project seems interested in (I've talk to them some time ago)

A standalone app as a distributor is also a good idea

[genofire]

@p1gp1g do you have any contacts? i do not find any way - forum down, the webseite and so one, looks unmaintained

[p1gp1g]

The website is there : http://projectmaxs.org/homepage/ . I've reached the dev a few times ago on the IRC channel #maxs on freenode. The dev is also reachable with the email address used on the git project

[genofire]

I found a Mail-Address from FLO and write him - let's see if we get an project together

[genofire]

PS: Should the XMPP-Part an own software or is it thinkable to put it in: https://github.com/UnifiedPush/common-proxies ?

[karmanyaahm]

PS: Should the XMPP-Part an own software or is it thinkable to put it in: https://github.com/UnifiedPush/common-proxies ?

Unless it's super complex being a module of common-proxies ought to be fine.

[genofire]

Sadly, flo (MAXS-Developer) has not time to develop it-self - he offers a little bit time to guide.

Has somebody else interests to take this Job of developing an XMPP-Provider (as MAXS Module or in Conversations, or fork like blabber.im) for Unified Push? (I myself do not like developing for Android Java + kotlin - so it will take years, till i got an first version) has somebody else interests?)

[p1gp1g]

I won't have time soon to do it personally :/

[karmanyaahm]

https://dev.sum7.eu/genofire/unified-push-xmpp

[genofire]

An gateway is there in golang (and still running under https://up.chat.sum7.eu/), which is stateless (it generates JWT-Token with the needed informations).

There is also an dbus linux client / Provider (with some reconnect bugs -> no time and not used by myself ...), with an fallback to up.chat.sum7.eu, if the own xmpp server has no UnifiedPush support.

There is missing an Android Provider, if there is one i will be motivated to maintain it (and go away from ntfy.sh)

[iNPUTmice]

Conversations is now a UnifiedPush Distributor¹. Not compatible with @genofire’s push provider though. I only learned about that when my own push server was almost finished. Interestingly we made very similar design decisions. (Stateless with tokens)

¹: https://codeberg.org/iNPUTmice/Conversations/commit/b1f95d2e39e64f3f066afa410c69d0704b1fdfb5

[genofire]

@iNPUTmice Is there any documentation of you xmpp transport format? (https://gultsch.de/xmpp/drafts/unified-push leeding to a 404)

Is there any OpenSource Server/Gateway implementation?

In the first look, i do not find any fallback to your UnifiedPush-Gateway Service (if the own XMPP-Server has not this XMPP-Service ... ). Do you plane somehing like that?

[iNPUTmice]

https://codeberg.org/inputmice/up (code + protocol spec)

Currently there is no automatic discover but a user setting for which push server one wants to use. (Setting defaults to up.conversations.im)

Automatic discovery (making the push server part of your home xmpp server) has a different set of privacy implications.

[iNPUTmice]

Automatic discovery is something I’m interested in. Especially - but not just - because I don’t necessarily want to run and maintain up.conversations.im. But shipping something that works to gauge interest in UnifiedPush is a priority for now.

[genofire]

yes of course - so if the settings of an server is set you should disable the discovery ...

i make here an disco on the server (and check if the unifiedpush.org namespace is promoted by any service), if not fall back to the own one (here an variable with name XMPPUPDemoJID ):

https://dev.sum7.eu/genofire/unified-push-xmpp/src/commit/612d577b21c9755dc5af90212cdc169c635b4eec/distributor/xmpp.go#L193-L238

[genofire]

Your implementations looks also very well:

but could you generate an random new public token instatt of transmitting the application (and instance) to your UP-Gateway?

And if you recieve an push notification with that random "public token", you could lookup in your table for the application and there instance.

On this way the UP-Gateway host would not know the applications (with UP-Support) which you run on your phone :)

---

In golang we have this code for the logic -> maybe somethink for java exists already (e.g. in ntfy.sh client) https://github.com/NoProvider2Push/dbus/blob/main/storage/storage.go

[iNPUTmice]

On this way the UP-Gateway host would not know the applications (with UP-Support) which you run on your phone :)

It doesn’t. application and instance are salted and hashed.

[genofire]

On Client i only found that: https://codeberg.org/iNPUTmice/Conversations/src/commit/b1f95d2e39e64f3f066afa410c69d0704b1fdfb5/src/main/java/eu/siacs/conversations/services/UnifiedPushDistributor.java#L145-L152

Sorry but does i miss something or is your salt just your account/jid ?:

that is a static value, which is also in the xmpp iq (and messages) which you got in an UP-Gateway hoster from the from field of your stanzas.

that is really easie to get it recalculated (if you has an list of possible applications).

So just your instance is hidden safe.

[iNPUTmice]

No, the salt is a UUID (the internal DB key)

[genofire]

oh nice, that was i am missing ;) (the uuid of your account not the jid) - that is better - thanks

Another Question: Does the IQ are retransmitte if the client is temporary offline (e.g. during an change of your network - e.g. wifi to mobile data)? otherwise the push notification got lost ...

[iNPUTmice]

Does the IQ are retransmitte if the client is temporary offline (e.g. during an change of your network - e.g. wifi to mobile data)? otherwise the push notification got lost ...

Currently no. See issue #1 for a discussion on whether or not that’s a good idea.

[p1gp1g]

https://codeberg.org/iNPUTmice/Conversations/src/tag/2.12.0/CHANGELOG.md