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)

[Denver Gingerich]

On Tue, Mar 31, 2020 at 08:38:20PM -, Jonas Schäfer wrote:
> 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.  Something is needed to solve the APNs (and possibly FCM) problem.  I 
don't know if this specific XEP is that thing, though (per below).

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

(apologies if this does not conform to the Last Call conventions - I'm new to 
this)

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).  Specifically, a message is sent to the client on the 
iOS device, but the message is not received by that device until the client is 
manually opened (i.e. the user has no idea a new message is waiting for them 
until they open the XMPP client manually).

If I am testing incorrectly, please let me know.  I would be very interested to 
hear of anyone that has gotten this XEP to work correctly on an iOS device, as 
I haven't yet met someone who has (and I've asked quite a few people).  
Especially helpful would be if such a person could tell me of a specific public 
known-working XMPP server, and specific client name/version to test with.

I'm happy to provide any clarifications or other details if they would be 
helpful.  Thanks for everyone's work on this - I am very hopeful we can have a 
solution in the near future, whatever that may be.

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

Re: [Standards] Call for XEPs to Advance in the Process - XEP-0066 (OOB)

[Denver Gingerich]

On Wed, Jan 22, 2020 at 05:37:51PM +, Denver Gingerich wrote:
> On Wed, Jan 22, 2020 at 12:13:13PM -0500, Sam Whited wrote:
> > On Wed, Jan 22, 2020, at 11:42, Jonas Schäfer wrote:
> > > - Is in Draft and you think should move on to Final
> > 
> > Similarly to carbons, XEP-0066: Out of Band Data [3] should move forward
> > or be deprecated. Given how well it works in the simple case, I'm
> > tempted to say move forward even though it doesn't have all the features
> > one might wish. Having a simple way to say "here's a URI, you can do
> > something with it" seems very valuable to me.
> 
> Agreed.  In our SMS/MMS bridge, we are planning to use the OOB "hint" that 
> Conversations provides for HTTP-uploaded images as an indication that the 
> user wishes to send the contents of the URI as an MMS (e.g. a picture 
> message) instead of just sending the URI itself in a text message.  So OOB is 
> useful for us, though we're happy to be informed of better ways to do this.

Here's a link to the relevant tracking ticket for this feature (meant to 
include in the last message, but forgot):

https://gitlab.com/ossguy/sgx-catapult/issues/16

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

Re: [Standards] Call for XEPs to Advance in the Process - XEP-0066 (OOB)

[Denver Gingerich]

On Wed, Jan 22, 2020 at 12:13:13PM -0500, Sam Whited wrote:
> On Wed, Jan 22, 2020, at 11:42, Jonas Schäfer wrote:
> > - Is in Draft and you think should move on to Final
> 
> Similarly to carbons, XEP-0066: Out of Band Data [3] should move forward
> or be deprecated. Given how well it works in the simple case, I'm
> tempted to say move forward even though it doesn't have all the features
> one might wish. Having a simple way to say "here's a URI, you can do
> something with it" seems very valuable to me.

Agreed.  In our SMS/MMS bridge, we are planning to use the OOB "hint" that 
Conversations provides for HTTP-uploaded images as an indication that the user 
wishes to send the contents of the URI as an MMS (e.g. a picture message) 
instead of just sending the URI itself in a text message.  So OOB is useful for 
us, though we're happy to be informed of better ways to do this.

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

Re: [Standards] XEP-0394: too weak to replace XEP-0071 - colouring

[Denver Gingerich]

On Sat, Mar 17, 2018 at 08:33:54PM +, Tedd Sterr wrote:
> In search of clarity, here are all of the reasons against that I can think 
> of, and replies to those. Please correct me if I've misunderstood anything; 
> and additional sensible reasons are also welcome.
[...]

At the risk of further drawing this out, I want to outline a possible 
additional issue that may have been hinted at in previous posts, but as far as 
I can tell hasn't been stated explicitly:

8. "People whose clients support colouring are confused when recipients don't 
see their colours"

This may be largely an issue of how far we wish to cater to users' 
expectations, especially users new to XMPP who have primarily used proprietary 
chat applications in the past (which I suspect would be the vast majority).  I 
personally think this is an important consideration, but I'm ok if the general 
opinion disagrees with me.

With virtually all proprietary chat applications, "what you see is what 
you(/they) get" is effectively guaranteed.  But with XMPP, a sender using 
XEP-0071 or XEP-0394 definitely does not have that guarantee, and so they may 
be confused when they send a beautifully-coloured message that uses colours for 
emphasis and then later end up having to say something like, "didn't you see 
all the important points I highlighted in red?!"

This is further confounded by the UI that most XMPP clients have, where 
messages you send are displayed right next to messages you receive, which may 
suggest more strongly to the sender that the recipient sees the message as they 
do (unlike with email, where there is more space between messages and more of 
an understanding that clients differ than there is with chat applications).

I realize that this is very similar to issues one might have with HTML email 
(senders may assume receivers see their colours).  However, I think the issue 
is more severe in the case of chat for the above reasons.

I have already seen a couple instances of this problem with XEP-0071, but 
fortunately it is rarer than it might otherwise be since I happen to chat with 
few people whose clients support XEP-0071 (XHTML-IM).

I'd like to emphasize that I am generally very happy with the wide variety of 
XMPP clients and their widely differing sets of supported XEPs.  For example, 
XEP-0085 (Chat State Notifications) and XEP-0184 (Message Delivery Receipts) 
work great when one side has support and the other doesn't - they behave as you 
expect and the fallback is not confusing.  But I feel that with colouring, the 
"fallback" (no colours) is different - it is both unexpected and confusing for 
many existing XMPP users (and for the vast majority of prospective XMPP users).

To be clear, I'm not necessarily suggesting that we definitely disallow 
colouring for the above reason (though I would probably lean toward that (and 
thus XEP-0393) myself), but I want to ensure that we at least consider this 
issue, as I'm not sure it's been adequately discussed so far.

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

Re: [Standards] 0174 Serverless Messaging: Discovering Capabilities

[Denver Gingerich]

On Thu, Mar 08, 2018 at 08:47:50AM -0700, Peter Saint-Andre wrote:
> On 3/8/18 2:33 AM, Dave Cridland wrote:
> > I'm aware of people experimenting with this on ad-hoc networks such as
> > emergent vehicle networks.
> 
> I heard about such things years ago, too. Are those active projects?

I can't speak for emergent vehicle projects, but ad-hoc networks are becoming 
increasing popular for person to person communication given new hardware 
technology (more on that below).  I suspect related XEP-0174 projects will soon 
be quite active.

> > While I agree that it's probably flaky as hell in practise, I think it
> > remains our best shot at this.
> 
> Do *we* need to take a shot at this?
> 
> What scenarios are we or other folks trying to solve for these days?
> 
> The original use case was ad-hoc 1:1 chat at conferences and local
> networks not connected to the wider Internet. While that was interesting
> 12 years ago, is it interesting now? Is there some other interesting
> problem that serverless messaging can solve?

I believe "local networks not connected to the wider Internet" are definitely 
still interesting, perhaps even more interesting today than before.

There are a number of new devices that allow people to create their own 
networks when away from an Internet connection.  In particular, see 
https://www.sonnetlabs.com/ and similar projects.  Sonnet creates an IP network 
with other Sonnets within a few kilometres - this would be a great place to be 
able communicate via XMPP without a server, i.e. using mobile XMPP clients on 
wifi-connected phones.

Similar devices include https://gotenna.com/pages/mesh - goTenna does not 
create an IP network like Sonnet, but instead uses its own proprietary 
protocols over the air and with connected Bluetooth devices.  I suspect we'd be 
able to go far beyond goTenna's capabilities by using XMPP with a less 
proprietary device like Sonnet.

It is the long-term goal of the Soprani.ca family of projects that I'm working 
on (which includes https://jmp.chat/ among others) to build and/or integrate a 
device like Sonnet into existing phones so that we can replace some of the cell 
network functionality with something that gives people a bit more freedom.  See 
https://wiki.soprani.ca/ThePlan#Long-range_radios (where we explicitly call out 
XEP-0174 as a way of doing this) for more details.

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

Re: [Standards] Message-IDs

[Denver Gingerich]

On Wed, Feb 28, 2018 at 08:59:01AM +, Kevin Smith wrote:
> On 13 Feb 2018, at 16:57, Simon Friedberger  wrote:
> > E3. Simply make the ID: FROM-TIMESTAMP.
> > Here FROM needs to be the eventual FROM after possible
> > rewriting. Can
> > that be done?
> > And TIMESTAMP has to be strictly increasing so should have
> > sub-second
> > resolution.
> > I assume this is impossible because otherwise it would be to
> > easy. But
> > why is it impossible? :)
> 
> Because timestamps aren’t monotonic? :)

Do you mean because most people use Unix time and/or other UTC-based timestamps 
(that have leap seconds)?

If so, this can be mostly solved by using TAI timestamps.  Unfortunately, it is 
tricky in most OSes to obtain a TAI timestamp, but I found some code that does 
this (on many platforms anyway):

https://ossguy.com/tai.c

We've used this code for implementing usage tracking in JMP (to ensure a day's 
length doesn't vary from day to day - it is always exactly 86,400 seconds 
long).  For details, see 
https://gitlab.com/ossguy/sgx-catapult/commit/31c2cb7c8fbea1ad4cc6753a4343dbfc65552fa5
 .  As you might suspect, we'd like to port the above TAI code to Ruby, but it 
works ok as-is for now.

I realize that clock skew could still cause the TAI timestamp that your OS 
returns to be non-monotonic (i.e. a machine issue, not an issue with TAI time 
itself); I'm not sure if that's a substantial issue for the message IDs being 
discussed here.

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

Re: [Standards] Security issues with XHTML-IM (again)

[Denver Gingerich]

On Thu, Oct 12, 2017 at 10:27:43AM +0200, Goffi wrote:
> There are dozen of flavours of [Markdown], not always compatibles, it's not a 
> syntax adapted for XML, and it's really limited (no table/color by default 
> for 
> instance). Markdown is not standardized, which make it quite a bad choice to 
> be used in a standard protocol.

Perhaps we could use Creole 1.0 instead - it is standardized to a large extent 
(see http://wikicreole.org/wiki/Creole1.0 for the spec) and has been around for 
over 10 years now.  Creole files (using the .creole extension) are 
automatically rendered by the GitHub and GitLab web interfaces.  See, for 
example:

https://gitlab.com/ossguy/sgx-catapult

There are a number of engines that support it already as well, per 
https://en.wikipedia.org/wiki/Creole_(markup)#Support_in_engines .  It also 
supports tables.

In my experience, Creole provides similar functionality to the commonly-used 
derivations of Markdown, but provides the standardization that Markdown lacks.

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

Re: [Standards] Permanent slots for HTTP Upload

[Denver Gingerich]

On Fri, Sep 08, 2017 at 02:11:06PM +0200, Philipp Hörist wrote:
> Conversations implements and uses Jingle for FT.
> And Dino is a bit new and i think there are more important things on the
> TODO list then jingle.
> Switft and Gajim also implement Jingle.

Yes, file transfer over Jingle with Gajim and Conversations has worked well in 
my experience (more on that below).

> Im with you that it is not easy to implement, mostly because i have to do
> low level socket stuff, compared to HTTP Upload where i can upload and
> download a file with one line of code in python.
> 
> My opinion is that its overkill to use Jingle for a use case where i want
> to transfer/publish a small file to a server. As i said i can do this with
> one line of code in python using http, i think its the same in other
> languages.

In the case of small files, Jingle with IBB is a bit nicer and cleaner, since 
it doesn't require a client/server to implement any "non-XMPP" things (making 
it much less "overkill" in a sense).  This is a big reason why we chose to use 
Jingle with IBB in https://jmp.chat/ (an XMPP bridge that gives you a phone 
number for text/picture messaging) - you can see how we implemented it here:

https://gitlab.com/ossguy/sgx-catapult/blob/b5902e0/sgx-catapult.rb#L406

Jingle with IBB also has the advantage of working basically everywhere.  Inband 
means you don't have to worry about firewalls or proxy servers or anything else 
that might be in the client's way.  The fact that the client has an XMPP stream 
means that Jingle with IBB will work for them.

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