Re: [Standards] LAST CALL: XEP-0357 (Push Notifications)

[Andrew Nenakhov]

вт, 7 апр. 2020 г. в 03:07, Denver Gingerich :
> Thanks for informing me.  I'll let others know about this option, as I think 
> there are people in other XMPP groups I'm a part of that would very much like 
> to test this, even if I am unable to devote much time to testing it myself 
> during specific windows.
>
> Just to be clear, does this need to be tested with an @xabber.org JID right 
> now?

No, at the moment we're running a stock ejabberd on xabber.org server.
Our fork of ejabberd which we call, you guess it, Xabber server,
currently runs on our own redsolution.com domain and on a number of
testing servers. Our new push-related improvements are not ready for
production, cause we still have to sort out the best approaches for
such things like  subscription requests. Easiest way is to pass data
encrypted right in the push, but I'm strongly inclined to avoid
including any information into push notifications, even in a strongly
encrypted form, so maybe we'll try to explore some other options.

If you want to have an account on one of our test servers, we can
arrange that (but better ask me in a week or so).

But the general rule with these new pushes is this: if it can't be
fetched from an archive, it's a problem.



-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0357 (Push Notifications)

[Denver Gingerich]

On Tue, Apr 07, 2020 at 01:52:14AM +0500, Andrew Nenakhov wrote:
> ср, 1 апр. 2020 г. в 01:59, Denver Gingerich :
> 
> > It might, but I have never found a client/server combination where both
> > have implemented this XEP that causes notifications to be delivered to an
> > iOS device.  Either the implementations I've used are broken, or this XEP
> > is insufficient.
> >
> > In particular, I have tried recent Prosody and ejabberd versions with the
> > respective "official" extensions for this XEP, along with the most recent
> > Siskin, Monal, and Xabber versions.  All have failed to provide
> > notification of incoming messages to the iPhone being tested (a 6S with the
> > latest iOS - same on cell data and wifi).
> 
> Well, it definitely did work on Xabber. However, the key here is timing.
> Latest iOS is likely the culprit - starting from iOS version 13.3 released
> in december 2019, iOS is silencing background VoIP notification that Xabber
> uses, so if you tried Xabber after december, it was unlikely to work. See
> my previous email in this thread for a longer explanation.

Thank-you very much for the detailed explanation.  It appears that was indeed 
the issue - I tested a couple months ago, using what I believe was the latest 
iOS at the time.

> Also, the app server is under development and is often switched off, so
> this could also lead to an incorrect impression of it not working. If you
> want to stage a test, I suggest you contact over email or XMPP (jid is same
> as email) and we'll provide you a window where everything will be in a
> working state. However, it will not be XEP-357 as it is written now but our
> necessary (even forced) improvements over it.

Thanks for informing me.  I'll let others know about this option, as I think 
there are people in other XMPP groups I'm a part of that would very much like 
to test this, even if I am unable to devote much time to testing it myself 
during specific windows.

Just to be clear, does this need to be tested with an @xabber.org JID right now?

Denver
https://jmp.chat/
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0357 (Push Notifications)

[Denver Gingerich]

On Tue, Apr 07, 2020 at 01:42:31AM +0500, Andrew Nenakhov wrote:
> This is our findings from a work in progress, once we have a
> production-ready working client, server and app server, we'll publish our
> protocol with more details and description of covered cases.

I am very much looking forward to that.  I will hold off on further testing of 
Xabber for iOS until I hear that the working client is ready.

This will be a huge step forward, and I am extremely excited to soon be able 
recommend an XMPP client for iOS without reservations.

Denver
https://jmp.chat/
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0357 (Push Notifications)

[Andrew Nenakhov]

ср, 1 апр. 2020 г. в 01:59, Denver Gingerich :

> It might, but I have never found a client/server combination where both
> have implemented this XEP that causes notifications to be delivered to an
> iOS device.  Either the implementations I've used are broken, or this XEP
> is insufficient.
>
> In particular, I have tried recent Prosody and ejabberd versions with the
> respective "official" extensions for this XEP, along with the most recent
> Siskin, Monal, and Xabber versions.  All have failed to provide
> notification of incoming messages to the iPhone being tested (a 6S with the
> latest iOS - same on cell data and wifi).


Well, it definitely did work on Xabber. However, the key here is timing.
Latest iOS is likely the culprit - starting from iOS version 13.3 released
in december 2019, iOS is silencing background VoIP notification that Xabber
uses, so if you tried Xabber after december, it was unlikely to work. See
my previous email in this thread for a longer explanation.

Also, the app server is under development and is often switched off, so
this could also lead to an incorrect impression of it not working. If you
want to stage a test, I suggest you contact over email or XMPP (jid is same
as email) and we'll provide you a window where everything will be in a
working state. However, it will not be XEP-357 as it is written now but our
necessary (even forced) improvements over it.

-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0357 (Push Notifications)

[Andrew Nenakhov]

ср, 1 апр. 2020 г. в 01:42, Jonas Schäfer :

> This message constitutes notice of a Last Call for comments on
> XEP-0357.
>
> Title: Push Notifications
> Abstract:
> This specification defines a way for an XMPP servers to deliver
> information for use in push notifications to mobile and other devices.
>
> URL: https://xmpp.org/extensions/xep-0357.html
>
> This Last Call begins today and shall end at the close of business on
> 2020-04-08.
>
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
>

Yes. Push notifications are necessary to make XMPP work on one major
computer platforms: iOS/iPadOS. To a lesser extent, it is useful on Android
and Web platforms.

2. Does the specification solve the problem stated in the introduction
> and requirements?
>

No, it does not. It used to, but not it is completely useless where it
matters most, on iOS.

I repeat: *current XEP-0357 is completely useless with the current policies
of Apple*.

3. Do you plan to implement this specification in your code? If not,
> why not?
>

We have implemented this specification in our upcoming iOS clients with
great results, using background VoIP notifications. However, Apple changed
policy on using such notifications, making them unusable for anything but
incoming voice calls. The other type of background notifications have very
low priority and are very heavily throttled, and developers are supposed to
deliver 1-2 such notifications per hour *or less*. This rules out any use
of it for any kind of real-time communications.

As a replacement, Apple provides so-called service extensions, which allow
some code execution. HOwever, it is generally not enough to establish a
full-blown XMPP stream, and access from such extensions to app data is very
limited. Also, while you *can* modify an 'alert' type message to display
actual data, you can not create a call interface of it. So to make
everything work you need to make the app server use different types of
notifications for VoIP and regular messages, and, consequently, XMPP server
has to send more verbose notifications to the app server.

My team and I have spent a better portion of last two months circumventing
all these problems, and we have an almost working prototype. Problems are
aplenty and make you rethink most of the things we generally do in XMPP. We
basically have these tasks:
 - show call interface for call, chat message for chat
 - cancel call interface if call was accepted on another device
 - clear notification about message if it was read on another device
 - correctly work with carbons
 - display incoming subscription requests (and hide accepted subscription
requests)

and you have to do all of it *WITHOUT AN XMPP CONNECTION*. This is hardly
possible without putting more meaningful payload into push notification.

In short, we changed the process for registration for push notifications,
client and xmpp server exchange a symmetric encryption key to encrypt
payload. Key is to be frequently updated.

In the payload, we pass an ID of message (for chat messages), or and ID of
a read message, or details about incoming subscription requests (BTW,
PubSub Avatars suck badly, curse those who invented them). If it is a VoIP
call, there is a flag telling the App server to use VoIP notification
channel, else it uses a regular 'alert' notification channel.

Yes, the app server is now aware if someone calls the user, not just
sending the message. It's a privacy risk we were unable to remove.

Next, the app server gets a push notification and passes the payload to the
client via an appropriate channel.

The client receives this message, decrypts it with an encryption key and
establishes a very limited xmpp connection that does just one thing:
authenticates and fetches just one message by ID from a message archive
(XEP-0313 MAM). It happens rather fast, in seconds. Then it changes the
default push notification text to text fetched from the archive. This is
done without launching an app.

Once a user interacts with a notification, an app is launched and can
establish an XMPP connection in a regular way.

This is a mostly working scheme right now on our test servers with our test
app builds. There are still some problems we didn't yet fully overcome,
like notifications are delivered to devices regardless of an app state, and
if it is already active, the notification does not have clear way to know
if the app is actually running, potentially leading to conflicting
resources and one of the connections being dropped. We have some ideas how
to circumvent this.


This is our findings from a work in progress, once we have a
production-ready working client, server and app server, we'll publish our
protocol with more details and description of covered cases.

To an extent, this technique can be used for browser 

Re: [Standards] Registrar: disco-categories: Add 'telegram' gateway type

[Peter Saint-Andre]

On 4/5/20 10:44 AM, Maxime Buquet wrote:
> On 2020/04/04, Linus Jahn wrote:
>> Hello,
>>
>> I opened a pull request more than 1.5 years ago and received a +1 from 
>> stpeter,
>> but no further interaction. The pull request was not merged.
>>
>> The pull request can be found here:
>> https://github.com/xsf/registrar/pull/30
>>
>> Can I do something to speed up this? Is writing a mail here the correct way?
>>
>> Thanks in advance,
> 
> 
> Hey Linus,
> 
> Sorry for the lack of response on this issue.
> For some reason I entirely missed this. I'm now subscribing to this
> repo.
> 
> This is editor realm. 

Yes, and handling the registries is just about the only thing I'm doing
for the editor team now.

PR merged.

> The registry has been somewhat "off" for a long
> time now. I don't know the details but I believe not easy to update
> because something something infrastructure.
> 
> As you can see in the xsf/xeps repo[0] some PRs are also blocking on
> this.
> 
> I hope iteam gets to have a look at this soon.

+1 - I haven't looked into these infra issues in quite some time so I no
longer feel competent to fix them.

Peter




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Registrar: disco-categories: Add 'telegram' gateway type

[Peter Saint-Andre]

On 4/4/20 12:15 PM, Linus Jahn wrote:
> Hello,
> 
> I opened a pull request more than 1.5 years ago and received a +1 from 
> stpeter,
> but no further interaction. The pull request was not merged.
> 
> The pull request can be found here:
> https://github.com/xsf/registrar/pull/30
> 
> Can I do something to speed up this? Is writing a mail here the correct way?

ACK.

I thought someone else was going to merge this, but with my registrar
hat on I will do that soon.

Peter

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0313: pending 0.7 update review

[Florian Schmaus]

On 4/3/20 10:51 PM, Matthew Wild wrote:> Hi folks,
>
> XEP-0313 is a well-established protocol at this point, but didn't yet
> make it to the next stage in the standards process. Time to fix that!
> […]
> The PRs are here:
>
> XEP-0313: https://github.com/xsf/xeps/pull/922
> MAM Preferences: https://github.com/xsf/xeps/pull/920
> Pubsub MAM: https://github.com/xsf/xeps/pull/921
Thanks for the update Matt. Much appreciated.
> Feedback very welcome, but I hope we can get this wrapped up and
> advanced to Draft where it should be soon!

I think links to a rendered version of the XEPs would make them more
accessible and therefore increase the amount of feedback you'd receive.

I took the liberty to import the XEPs of your PRs into my repo [1]. This
repo gets automatically build and XEPs are published in HTML rendered form:

http://geekplace.eu/xeps/xep-mam/xep-mam.html
http://geekplace.eu/xeps/xep-mam-prefs/xep-mam-prefs.html
http://geekplace.eu/xeps/xep-pubsub-mam/xep-pubsub-mam.html

There is even a HTML diff of MAM:
http://geekplace.eu/xeps/xep-mam/diff-side-by-side.html
http://geekplace.eu/xeps/xep-mam/diff.html


With that, I shall start looking at your actual proposed changes and
ProtoXEPs. :)

- Florian

1: https://github.com/flowdalic/xeps
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Registrar: disco-categories: Add 'telegram' gateway type

[Jonas Schäfer]

On Sonntag, 5. April 2020 18:44:42 CEST Maxime Buquet wrote:
> On 2020/04/04, Linus Jahn wrote:
> > Hello,
> > 
> > I opened a pull request more than 1.5 years ago and received a +1 from
> > stpeter, but no further interaction. The pull request was not merged.
> > 
> > The pull request can be found here:
> > https://github.com/xsf/registrar/pull/30
> > 
> > Can I do something to speed up this? Is writing a mail here the correct
> > way?
> > 
> > Thanks in advance,
> 
> Hey Linus,
> 
> Sorry for the lack of response on this issue.
> For some reason I entirely missed this. I'm now subscribing to this
> repo.
> 
> This is editor realm. The registry has been somewhat "off" for a long
> time now. I don't know the details but I believe not easy to update
> because something something infrastructure.
> 
> As you can see in the xsf/xeps repo[0] some PRs are also blocking on
> this.
> 
> I hope iteam gets to have a look at this soon.

With a hybrid editor/iteam hat on (fancy new stripes!): I intend to work on 
this more urgently now that I have the power to do so.

Hopefully, we have a solution before the end of April.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___