Re: [Standards] 0174 Serverless Messaging: Discovering Capabilities

[Christian Schudt]

Hi,

my original question quickly drifted away to a discussion about the use case of 
serverless messaging.

But I feel my concern was not addressed:

1. Why can’t the receiving entity include its Entity Caps as stream feature as 
described in XEP-0115?
2. Why should we instead use disco#info? I don't consider disco#info in stream 
features an optimization which justifies the additional implementation overhead:
- Deal with Entity Caps in TXT records. It's only to potentially know an 
entity's capabilities before having initiated a stream with it, right? Sounds 
ok then, but unreliable.
- Deal with yet another stream feature which covers an existing use case: to 
know an entity's capabilities (Entity Caps, Caps 2.0, disco#info)
- Nowhere else is disco#info mentioned to be included in stream features
Thoughts?

I'd prefer the following:
The receiving entity includes Entity Caps in it's stream features. If not known 
by the initiating entity, it may request disco#info and proceed normally 
(verify and cache the result). Most, or even all of an existing Entity Caps 
implementation could be reused then.


3. Can the section be updated although the specification is final?

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

Re: [Standards] 0174 Serverless Messaging: Discovering Capabilities

[Peter Saint-Andre]

On 3/8/18 9:12 AM, Denver Gingerich wrote:
> 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.

The XEP-0174 use case was originally for people connected to the same
WiFi hotspot or other link-local network. The technology was driven
forward by Apple (remember when Bonjour was called Rendezvous?) and
hasn't received much attention since they stopped featuring it in iChat.

> 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.

Yes, I'm familiar with such technologies, having worked on peer-to-peer,
end-to-end encrypted, long-range radio communication devices for IoT (no
longer my current project). There are significant challenges involved in
building such things - battery life, power consumption, sleepy nodes,
firmware size, OTA updates (!), bandwidth limitations (our devices
operated at ~900 MHz), eliminating a dependency on centralized towers
(LoRaWAN, LTE-M, etc.), strong security including use a secure enclave
and a proper manufacturing process to bootstrap trust (hardware is
hard), protecting privacy over a radio frequency transport through
techniques like channel hopping and seemingly random time schedules,
etc. I am not convinced that XMPP is the right approach for such
applications. Something like Apache Mynewt might a more appropriate
foundation (it's being driven forward by some of the original technical
minds behind Silver Spring Networks), but even then there's a lot of
work required to build a true mesh protocol in a private and secure way
(e.g., the native LoRaWAN security is not strong and that architecture
depends on towers anyway).

> 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.

Those are great aspirations. However, I am skeptical that XMPP meets the
design goals in this space.

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] 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] 0174 Serverless Messaging: Discovering Capabilities

[Dave Cridland]

On 8 March 2018 at 15:47, Peter Saint-Andre  wrote:
> On 3/8/18 2:33 AM, Dave Cridland wrote:
>> On 7 March 2018 at 16:26, Peter Saint-Andre  wrote:
>>> On 3/5/18 3:37 PM, Christian Schudt wrote:
 Hi,

 I find the whole passage „Discovering Capabilities“ of Serverless 
 Messaging [1] a bit confusing.
>>>
>>> Are people still using this technology? In my experience, it was a fun
>>> experiment in ~2006 but didn't work well in practice: too chatty over
>>> the network, presence never worked correctly, you'd send a message to
>>> someone and it turns out they weren't available, etc.
>>
>> 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?
>

Amazingly, yes.

>> 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?

Well, that's certainly not the current use-case.

The problem they're trying to solve is where you have a number of
people and/or vehicles that are moving about, and you want structured
conversations between them, and some of these vehicles have uplinks to
a stable network. So there are gateways between XEP-0174 and S2S
floating about too.

My understanding is that it's working quite well, experimentally. But
really I'd be surprised.

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

Re: [Standards] 0174 Serverless Messaging: Discovering Capabilities

[Peter Saint-Andre]

On 3/8/18 2:33 AM, Dave Cridland wrote:
> On 7 March 2018 at 16:26, Peter Saint-Andre  wrote:
>> On 3/5/18 3:37 PM, Christian Schudt wrote:
>>> Hi,
>>>
>>> I find the whole passage „Discovering Capabilities“ of Serverless Messaging 
>>> [1] a bit confusing.
>>
>> Are people still using this technology? In my experience, it was a fun
>> experiment in ~2006 but didn't work well in practice: too chatty over
>> the network, presence never worked correctly, you'd send a message to
>> someone and it turns out they weren't available, etc.
> 
> 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?

> 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?

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] 0174 Serverless Messaging: Discovering Capabilities

[Dave Cridland]

On 7 March 2018 at 16:26, Peter Saint-Andre  wrote:
> On 3/5/18 3:37 PM, Christian Schudt wrote:
>> Hi,
>>
>> I find the whole passage „Discovering Capabilities“ of Serverless Messaging 
>> [1] a bit confusing.
>
> Are people still using this technology? In my experience, it was a fun
> experiment in ~2006 but didn't work well in practice: too chatty over
> the network, presence never worked correctly, you'd send a message to
> someone and it turns out they weren't available, etc.

I'm aware of people experimenting with this on ad-hoc networks such as
emergent vehicle networks.

While I agree that it's probably flaky as hell in practise, I think it
remains our best shot at this.

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

Re: [Standards] 0174 Serverless Messaging: Discovering Capabilities

[W. Martin Borgert]

Quoting Peter Saint-Andre :

Well, it worked OK at small conferences when universal connectivity
wasn't so common in the pre-smartphone days (folks had a lot of fun
using it in Adium and iChat back then), but I haven't seen it used since
2010 or so.

It went to Draft and Final quickly (perhaps we were more efficient about
moving things forward back then), but it doesn't seem relevant anymore.


I didn't use this feature for some years, but I can imagine, that
it might be a relevant niche. Having a protocol that can survive
certain desasters like "no mobile internet available" still sounds
interesting and worthwhile to me. Might even be interesting in the
field of humanitarian aid or when privacy is more relevant.

Cheers

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

Re: [Standards] 0174 Serverless Messaging: Discovering Capabilities

[Peter Saint-Andre]

On 3/7/18 9:48 AM, Christian Schudt wrote:
>> Are people still using this technology? In my experience, it was a fun
>> experiment in ~2006 but didn't work well in practice: too chatty over
>> the network, presence never worked correctly, you'd send a message to
>> someone and it turns out they weren't available, etc.
> 
> I was considering implementing it also as a fun experiment.
> 
> Too chatty? It looks less chatty than normal XMPP (no presence, less stream 
> negotiation), where's the issue?
> And maybe the presence issue was only an implementation error?

The chatty part is figuring out if people are actually available on the
local network.

> If it was a fun experiment, why is XEP-0174 in status Final instead of 
> Experimental then?

Well, it worked OK at small conferences when universal connectivity
wasn't so common in the pre-smartphone days (folks had a lot of fun
using it in Adium and iChat back then), but I haven't seen it used since
2010 or so.

It went to Draft and Final quickly (perhaps we were more efficient about
moving things forward back then), but it doesn't seem relevant anymore.

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] 0174 Serverless Messaging: Discovering Capabilities

[Christian Schudt]

> Are people still using this technology? In my experience, it was a fun
> experiment in ~2006 but didn't work well in practice: too chatty over
> the network, presence never worked correctly, you'd send a message to
> someone and it turns out they weren't available, etc.

I was considering implementing it also as a fun experiment.

Too chatty? It looks less chatty than normal XMPP (no presence, less stream 
negotiation), where's the issue?
And maybe the presence issue was only an implementation error?

If it was a fun experiment, why is XEP-0174 in status Final instead of 
Experimental then?

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

Re: [Standards] 0174 Serverless Messaging: Discovering Capabilities

[Peter Saint-Andre]

On 3/5/18 3:37 PM, Christian Schudt wrote:
> Hi,
> 
> I find the whole passage „Discovering Capabilities“ of Serverless Messaging 
> [1] a bit confusing.

Are people still using this technology? In my experience, it was a fun
experiment in ~2006 but didn't work well in practice: too chatty over
the network, presence never worked correctly, you'd send a message to
someone and it turns out they weren't available, etc.

Peter




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

[Standards] 0174 Serverless Messaging: Discovering Capabilities

[Christian Schudt]

Hi,

I find the whole passage „Discovering Capabilities“ of Serverless Messaging [1] 
a bit confusing.

1. Why can’t the receiving entity include its Entity Caps as stream feature as 
described in [2].

2. I can see the slight optimization of including disco#info data as stream 
feature (similar as with including Entity Caps), but the reasoning here is 
far-fetched: "full stream negotiation already can require a large number of 
packets“.
(a) Stream negotiation should already be less expensive than in a real 
client-to-server session and
(b) I can’t imagine that a single additional IQ-get request for disco#info 
would have a performance impact in a serverless messaging environment or would 
justify the additional implementation complexity:

3. disco#info as stream feature adds unnecessary burden to developers, which 
must now:
- Deal with Entity Caps in TXT records (publish and read Entity Caps to/from 
another source)
- Check stream features not only for Entity Caps, but also for disco#info.
(otherwise we could simply reuse existing logic from [2])

Am I missing something here?
What are your thoughts about it?
Can the section be updated although the specification is final?

— Christian

[1]: https://xmpp.org/extensions/xep-0174.html#caps
[2]: https://xmpp.org/extensions/xep-0115.html#stream
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___