XSF Discussion - 2018-03-21

Dave Cridland o/

Morning.

Wake-up calls via XMPP? Where do I sign up?

Can I have an XMPP-controlled coffee machine too?

zash: qmacro's "programming jabber" has a chapter on that

Zash, HTCPCP over XMPP? sounds like a protoxep to me!

Zash: you don't have a XMPP controlled coffee machine yet? How are you able to function in this society?!

just sent a little remark for Bookmark 2 https://mail.jabber.org/pipermail/standards/2018-March/034673.html I think that we need to discuss about those limitations and format for JIDs, node ids, item ids…

Guus: Barely

I though that Tox.im was about Tea Over XMPP

Argh. That's bound to cause interop problems.

<error code='418' type='cancel'><i-am-a-teapot xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error>

:p

Oh no, out of coffee

I'm out of a coffee machine, for weeks already.

I think I've used up my emergency backup beans too

All I have is a ten-pack of instant coffee portions, and that is down to eight already.

edhelas, You wrote lots of words which I mentally summarised as "Yes, I think the XSF should work on this proposal".

edhelas, And having caught up on that thread - lots of people have written the same thing in many ways (ie, yes, let's work on that spec in the XSF). So if the Council accepts it, I'll go over those and respond and/or update as needed.

Or JC can, of course.

so this could lead to a new XEP-**** Formats of Identifiers in XMPP or updating the existing XEPs to define those formats and limitations (for 0060 at least)

Surely you can apply stricter restrictions for local data?

I am, I need to define the structure of my data in my SQL DB

and I can tell you that I cannot define a really long Pubsub item id at the moment (depending of the encoding of the characters as well)

And then there's the thing where hostparts in JIDs are allowed to be 1023 bytes but DNS doesn't allow more than ~255 bytes

oh I wasn't aware of that

And Prosody by default doesn't allow anywhere near that long JIDs

Or, default storage implementaion won't accept it.

would be nice to open a wiki page or notepad to list what limitation we put in our softwares regarding those things :)

it can give a nice overview

Personally, I think pubsub-using-specs should just say 'in normalised form'.

?

I still don’t understand peters point that we need to specify a normalization for pubsub nodes (in contrast to specifying to NOT use normalization)

When putting JIDs into nodes :)

I'm also using those pubsub identifiers to craft urls, so you have URLs limitations in there

Or into IDs, rather.

(in the general case, that is)

maybe somenoe can help me out with that?

Why is resource locking out of fashion now?

Is there a XEP on that?

Conflicts with the model in which all messages are available on all devices all the time

Zash, got some more details? :)

Not really

SaltyBones, see Ge0rGs XMPP 2 slides

Resource locking was only a small part of that, though

SaltyBones, https://wiki.xmpp.org/web/Georg%27s_Talk_on_Message_routing

SaltyBones, search for "resource" in that

Wow, I've got a wiki article of my own!

Ge0rG, don’t you already have User:Ge0rg? ;-)

jonasw: yes, I'm used to having written all the wiki pages with my name in the title. This one is a welcome exception

It's a bit brief considering that it is contradicting xep-0296 ;)

Ge0rG, council.agenda.append("Obsolete XEP-0296") :-)

Obsoleted by Carbons and MAM

jonasw: yes, but only for messages, not for IQs

SaltyBones: search the ML archives for "resource locking" and "burn with fire" :P

Sorry, I've got real work to do now. BBL

you can’t eliminate use of full JIDs for IQs obviously? ✏

Ge0rG, I think the ML archive has no search function. O_o

SaltyBones, use your favourite search engine with `site:mail.jabber.org "Standards" your search terms here`

Anyone get anywhere with borrowing the IETF mail search thing?

https://mailarchive.ietf.org/arch/

jonasw, doesn't seem to work :)

jonasw: Dave's last mail just inspired a feature request for JabberCat: announce <show>chat</> whenever a cat is walking over the keyboard.

<show>cat</>

CSN should have a <cat-on-keyboard/> state

How can we ever compete with Skype without such a critical feature?

Does skype have that?

It did in 2009 or so I've heard.

Wow, we are almost a decade behind!

No idea if the Linux version had it, but it was crime-against-humanity levels of bad.

Skype overall or just that feature?

Skype on Linux was bad

regarding the muc discussion on the mailing list

why is it that every client has to join a muc separately in the first place?

Because it's designed like that

fair

The concept of a chatroom/conference is pretty old, and it includes the idea of presence (i.e. people are currently in the room or they aren't)

That list is separate to the list of people who theoretically have access to the room

Now people have multiple devices, and all of them are online/offline at different times, and we have the storage capabilities to store messages indefinitely, people care less about presence

SaltyBones: Because it's not MIX yet.

This concept that you are always online and you have access to everyething everywhere is fairly new

I think the ideal flow goes: User enters room on any client: gets bookmarked autojoin User leaves room: gets un-autojoined Client gets autojoin for room it's not in: joins Client gets un-autojoin for room it's in: leaves

Which is, I believe, a paraphrase of what Sam said.

Kev: For normal people perhaps.

Yup, that's a clearer way to say what I was trying to say.,

I have an interest in XMPP for normal people :)

I have an interest in not getting annoyed by things.

What aspect of this would be annoying?

There is the thing where desktop clients might want to join rooms where the mobile wouldn't.

Computers doing things without permission annoys me. Clients joining rooms without my direct action is already annoying me.

Dave Cridland: I don't think that's a thing, I really don't. I think wanting to avoid wasted bandwidth on mobile clients is a thing, but I don't think that's the same.

Kev, Not bandwidth, actually, but visibility and interrupts.

Interrupts are a general question, yes, but not limited to MUCs.

I'd say that we need some kind of centralized per-JID notification settings

That and useful traffic limitation for mobile.

As was said recently, we could auto-leave all no-notification MUCs on a mobile client and only join+MAMsync when the user taps the MUC

We could, although I think no-notification MUCs are relatively rare.

Saying that, mind, I have several channels in Discord that I've Muted.

the interesting challenge is solving CSI and push notifications in the presence of E2EE

I normally only want notifications in muc's when my name is highlighted

really on mobile and desktop

moparisthebest: so how is that supposed to work with OMEMO?

the server would just send all those

ie, it wouldn't

good bye battery

or you intentionally leak the recipient

it's nice to be able to have omemo mucs, but I'd say most aren't

and the ones that are I believe should be a small number of people and not that busy?

I'd also argue that most OMEMO MUCs are private and low traffic

flow, you read my mind :)

e.g. your family

Is that because it simply doesn't work (yet) with larger groups or because some other reason?

I think most are like this room, public, probably even logged

I mean, is it because technical reasons that are very likely to change in the future or because of social reasons that will likely stay the same?

Assuming how things will work in the future based on how it works now isn't the most reliable

my gut feeling is social reasons that are likely to stay the same

Also, people tend to challenge limits.

well, right now *all* muc messages are sent to the phone all the time right? (for ones you are joined)

if Ge0rG is saying this situation will remain the same in the future with omemo, that's right, I don't see a problem with it

> Kev> We could, although I think no-notification MUCs are relatively rare. On Work Mattermost I disabled every single notification, and I'm joined in a handful of rooms (~ 20). I don't think it's that rare ✏

ha nginx just recently got ability to multiplex based on alpn http://mailman.nginx.org/pipermail/nginx/2018-March/055798.html

guy in the conversations muc said he'll bug someone here for a wiki account to document it soon

9 days ago http://hg.nginx.org/nginx/rev/79eb4f7b6725

Nice

Hm, didn't know nginx used hg

Me neither