XSF Discussion - 2018-05-29

... but?

Nobody does it. Maybe most client developers don't care about UX, nor about corporate use cases

I feel that org setup is more of a server side thing?

Server developers don't care about corporate either.

I think the ignite folks do

But that doesn't matter because the client UX sucks

reminds me to make things even harder for clients by specifying the IBR flow for ToS

even though I’m inclined to simply say "ToS setups where consent is required before signing up are not supported by this XEP, but may be handled by a future specification"

"use a web form or something"

jonasw: so what you are trying to invent has no value over web forms but compatibility issues?

As opposed to everything else

Ge0rG, it has; for GDPR, you don’t need consent anyways :)

consent-requiring services will need that, but that’s #notmydepartment right now

(but the spec can be extended to support that, so that’s good)

Kev, MattJ, can some of you help me with an issue on jabber.org (the xmpp service)? ✏

Not sure if I'll be able, but shall if I can - what's up?

there’s a room with an invalid JID on conference.jabber.org: @conference.jabber.org (yes, with empty node part)

I think Anu touches an interesting point and I have to agree with him on the specific idea he mentioned. Discord, for instance, does a very similar thing. Where you create a 'server' (I think they call it that way) and you can create as many as MUCs you want under that 'server'. Do we have a way in XMPP to do this? Like a top level node where you add MUCs under it? Maybe with MIX this is possible?

Seve/SouL, apt install prosody, echo 'Component "sub.domain.example" "muc"' >> /etc/prosody/prosody.cfg.lua ?

it would be great if that room could be nuked, MattJ

jonasw: don't forget prosody-modules and two days of surfing the web to find out which versions of which modules are needed

Ge0rG, MUC is luckily built-in :)

Seve/SouL: I've argued for a long time that we need a two-click server deployment that integrates with LDAP, has all the nice modules... and a usable web client

Ge0rG, do that!

don’t argue, make it

that being said, I think I mentioned that Guus is doing things in that direction. not only with a web client, but with WebRTC conference things

jonasw, haha, no no. I mean, unless you want to have this component for every user x) They call it a server but it's just like the root. Let's say we join Discord. I create a 'server' called XSF. And under it, I create offtopic, board, council, etc.. and everybody that joins the XSF 'server' can check the list of MUCs I've created for the XSF.

but nobody is looking in that direction for some reasn.

jonasw: but it's real work. Work for people who are more skilled in Lua and mercurial

Seve/SouL, you mean like a separate MUC namespace for each user?

All of that, is under the same service

jonasw: I'm looking for corporate clients who would ask for that. None found so far

Seve/SouL, this won’t be possible with MIX either, and I’m not sure if it makes sense at all. A corporate deployment would have a domain anyways and host their services under that domain.

Hmm, I didn't have companies in mind now, but imagine a large company. They would have an xmpp server, and each department would create their own MUCs inside the department's namespace. Like: IT namespace> Frontend dev, Backend dev, DevOps, etc

Seve/SouL: that's great. Except that's not how large companies work

Seve/SouL, you can have as many MUC domains as you like

Seve/SouL: today's bigcorp want a cloud-based / private-cloud deployment that's fully integrated into their CMDB and AD and stuff

Which just about any XMPP server provides

MattJ: are you speaking of AD integration or of "as many MUC domains as you like"

Both

(conference.jabber.org really could use some cleasing)

I understand what you say MattJ. But I think it would be interesting to explore that feature, as Anu said Slack works that way and Discord too. Of course they have this feature because they provide this service, and this feature maybe would not be useful for someone using XMPP just to talk with friends, but...

MattJ: so you can write the instructions to set up a prosody for modern clients, including AD integration and a web client, on a napkin?

Most likely, yes

And if you ask why not already done - everyone has a different set of requirements

You may think it, but not every organisation uses AD, or needs/wants a web client

Seve/SouL, I agree that a hosted thing which allowed to easily add a domain, have a tickoption "[ ] Federate with other servers" and otherwise just deploys a modern XMPP server would be great, but time & money

I doubt that one can write down the instructions for integrating with LDAP on a napkin.

picking auth_ldap vs. auth_ldap2 is a non-trivial choice to start with :)

MattJ: I know how complex it is to set up a prosody instance for non-commercial users, with less strict requirements. And it won't fit on a napkin.

jonasw, Prosody's LDAP module was designed to work with no-to-minimal configuration a typical Debian/Ubuntu LDAP setup

What I'm saying though is that there is no "standard set-up" (for anything)

Everyone has their own requirements and stuff they want to configure, including Ge0rG

there is no standard LDAP setup, from what I can tell :)

but maybe that’s just me

There is not, but there are many. The one that Debian tries to encourage you into is one

If anyone thinks that enterprise deployment of any integrated software fits on the back of the napkin, they're plainly wrong

The reason things like Slack succeed is precisely because they tend to bypass all that in the beginning

yeah

MattJ: then people realize how expensive Slack is and want a single-click deployment. And end up with Mattermost

or rocket.chat

MattJ, any luck with the MUC nuking?

MattJ: there are some requirements that you can't argue are optional, like 0198, carbons and MAM

I haven't used Mattermost, but I don't find rocket.chat very high quality software

MattJ, still it replaced XMPP at the company I work for.

because of -- among others -- rich text messages (beyond markdown-ish things) for integrated services...

(I was mentioned here, but can't find the mention in recent history)

(or my client is acting up)

Guus, I was talking about the webrtc-conference-integration work you are doing

jonasw, I don't seem able to access the server, so... no

MattJ, aw, pity

I’ll try annoying folks in iteam@

ah, yeah. We have Jitsi Meet as an Openfire plugin.

Technically iteam doesn't manage jabber.org, but there is, umm, significant overlap...

yupp :)

(checked the volunteers site on jabber.org, found half of iteam there :))

so now I’m abusing the better signal/noise ratio in that room for my cause!

on a different but related note: I launched https://muclumbus.jabbercat.org/ into public beta today. It’s a replacement for http://search.wensley.org.uk/ , so it’s a "search engine" and listing service for public MUCs . criticism, improvement suggestions, bug reports etc. welcome ✏

replacement? ha! hardly... no comic sans! just kidding of course, looks very professional, will it provide a JSON endpoint?

Wiktor, thanks, and yes, some type of JSON endpoint which allows to enumerate rooms is on the TODO list

gotta run now though

great, see ya

Lync is now appending ads to the "missed messages" email. Ads for the Lync mobile app.

jonasw: great ! Is there a way to query this by XMPP ?

jonasw: how comes there is no info about many MUCs?

jonasw: it's also missing the room name from disco#info :(

something like "Name (<jid>)" in the first line?

I know it's the localpart in 99% of the cases, but I have an agenda to change that.

I think we'll be ready to show a working prototype of proper groupchat replacement this week

With client that will support it too

jonasw for servers/rooms supporting muc vcard would be nice to include that in the room stats.

Andrew Nenakhov: that reminds me of the promises the ejabberd team made back then instead of implementing XEP-0198.

Ge0rG will never forget that.

Yes, we replaced those too and implemented them in forked ejabberd

Just not supported in clients yet

Holger: feel free to provide me with a bettter example of XMPP vaporware. MIX doesn't count.

Groupchat is a much easier problem.

Except it's not.

It's an easy problem. It's the solutions that are easy to get wrong :D

It is. You might join our group chat when now.

I can send you invitation if you want

Ge0rG: They tried stuff and it failed, that's all. I still fail to see the drama.

Ge0rG: And it's not like 0198 works well.

Holger: the drama is about to making empty promises for years about a feature that's really needed for mobile clients.

Holger: it's got its rough edges, but it works much better than not having it.

Yeah, they've been busy with other stuff.

Who hasn't?

But I know I'm a highly controversial ultra progressive revoluzzer regarding XMPP support for mobile devices.

...or reliable message delivery.

Actually, we do have progress on this front too.

;)

Andrew Nenakhov: I'm curious to see your design

Ok

Give me a minute

Ge0rG, add xsf@xmppdev01.xabber.com to your contact list

Andrew Nenakhov: what will happen then?

You'll be in our group chat

Best accessed with Xabber for Web, https://web.xabber.com/develop/

But we've added backwards compatibility for old clients too.

Andrew Nenakhov: I'm interested in the protocol design :)

Document is in Russian, will take some time to translate

But basic idea is simple

Andrew Nenakhov: I can handle Russian

Member sends message to jid of group chat, server resends it to other members

That sounds like GC1 ;)

For old clients it adds line with name of sender, like, GeOrG: Whatever

> That sounds like GC1 ;) I actually didn't find specification for that

Only mention in muc-0045

What is received by new clients? is there an extra xml?

But yeah, so far we didn't encounter anything that would be game breaking by this approach

Wiktor, yes

Sounds interesting, and simple, also looking forward for the spec

Every message is accompanied by jid of sender, and his avatar hash

Server also fetches username and avatar from members vCards

User can replace them

Also server sends a specially formatted presences so clients can differentiate group chats from regular contacts

why wasn't resource part of JID reused as a nick? so that this group chat was somehow distinguished from 1:1 chats?

Because we didn't think it is necessary )

got it :)

And also too many ears were fought on this issue

goffi, re querying muclumbus via XMPP: not yet, but that’s on my todo

Andrew Nenakhov: do you have a (Russian) spec you can share?

Ge0rG, many MUCs don’t publish a description, that’s why there is no info

Ge0rG, regarding using the room name, many of the top 25 MUCs have a horrible room name (e.g. room name == description); I haven’t found a layout which makes that look nice. I have the data though.

jonasw: cool

muppeth, could you be more specific regarding the vcard thing? I am reluctant adding third party images on the listing because of the huge potential for abuse.

Ge0rG, I can share it tomorrow if you don't mind. Too many dirt right now,

Ge0rG, maybe ellipsizing the room name after 50 characters or something would, but meh.

We do a room name and separate jid. Jby default client is doing a slug of group name, but it can be redefined

jonasw: yeah, name, description and topic are handled in weird ways. I still think we should promote the name, and my favorite layout would be: > Room Name (jid@domain) > romm description (if different from room name)

that looks awful, trust me

Andrew Nenakhov: slug-of-groupname is a great way.

jonasw: one day you'll end up with uuid MUC JIDs.

there are a few already :)

Swift generates those.

Kev: for public MUCs as well?

Of course not :)

this is luckily public MUCs only :)

Ge0rG, hm, reverting to the current layout for room name == room description could work though

jonasw: I agree with you that most people can't properly define the room name.

There is a bunch of positive exceptions, though.

Ge0rG, really bad is the case for kuketzblog, which has no description, but a string which should be the description as name

Kev, while you’re here, can you fix the room name for this room please?

it is equivalent to the subject

I think it's symptomatic for the XSF to not be able to properly apply our own standards.

I imagine it's someone using a client that's doing silly things.

Although what the name *should* be, I have no idea.

"XSF Discussion"?

Indeed, that's what I set it to.

"XMPP Standards Foundation"

or that

"XMPP Discussion" would be a good one as well

Ge0rG, force-reload https://muclumbus.jabbercat.org/

Ge0rG, xmpp@chat.yax.im is also a bad example regarding room name, by the way

jonasw: thanks! nitpick: name of conversations@conference.siacs.eu is "Conversations", so not strictly equall

Ge0rG, no, it’s "conversations"

identities: category='conference' type='text' [en] 'conversations'

jonasw, list of chats should say "XMPP discussion", and whatever yax.im part is not really important for users once they are in room

jonasw: changed the xmpp@chat.yax.im name. When will it refresh?

hmm... hiding jids in case there is name... it would look like google :)

Ge0rG, the about page tells you it takes something about one hour

Wiktor, I’m considering hiding the JIDs in case there is a name, but then I’ll have to consider how to handle matches inside the JID in the search list

personally I would move online users count closer to the name / description. On bigger screens it's hard to read the room name description and count without excessive eye movements :) maybe that's just me :)

one way or another big 👍, this service is really good

thanks

regarding the online user positioning, I don’t think there’s a good way for that since this is a table :/

(and I don’t want to move the online count into the text field because it’ll be hard to discover it)

yeah, I mean on mobile the data is compressed and it looks good, on laptop the important info (user count) is far away

on my laptop it’s fine

Have the number to the left

Ge0rG, would have to trick CSS to make that happen

not sure if browsers support that

jonasw: what about reordering the table items? Too easy?

Ge0rG, not accessible

although, with a table it’d probably work

there doesn’t seem to be a way to do this with CSS, but I’ll look into how bad reversing the columns would be

did I get this right that there is also planned "room language" to be displayed?

Wiktor, yes

once servers support that

great ✏

yes, and once it's set up by room operators

follow https://github.com/processone/ejabberd/issues/2436 and https://issues.prosody.im/1149 :)

sure

I need to get back to work on my thesis now though

good luck :)

(which unfortunately isn’t "Enumerating chat rooms in a federated chat network")

jonasw: you need a better thesis supervisor then.

Ge0rG, dunno, I find "port this thing so that we can run it on a satellite which’ll be shot into space next year" fine, too

Nobody can compete with satellites...

(also, my supervisor is actually an XMPP fan)

jonasw: I'm an xmpp fan as well, despite what I'm writing, and I'm a certified thesis supervisor. But I don't have satellites... 😒

aww

I've just spent ten minutes debugging ahy this app isn't using SASL2.

No matter what I did, it kept using the urn:xmpp:sasl:1 namespace.

then you realized that that IS the SASL2 namespace?

while the other one would be urn:ietf:something?

jonasw, Exactly.

jonasw, One day I'll figure out some non-trivial update to SASL2, so the namespace can align properly. :-)

Until the next one.

which will be the bugfix release.

what about using `urn:xmpp:sasl2:1` instead?

what about urn:xmpp:sasl2000

Ge0rG, Still a namespace change. No, I think it's doomed to be sasl:1 forever.

"Status: Experimental". Doesn't look very doomed to me.

I wouldn't be surprised if dwd turned out to be the (co)owner of all existing implementations.

actually XMPP is only made by dwd, everyone else in this chatroom are just multi

I have a question regarding 0045

we all do

Ge0rG, Surevine is, I think, for now. Phil Roberts did one in Stanza.io, and I did one in Openfire. Neither's been pushed upstream, which I'd like to rectify.

muc#roominfo_pubsub, it's not specified in the XEP where this is exposed when set, it would be nice to say that somewhere

(Man there are times I want a +1 for '45, and jonasw, that was one of them)

edhelas, roominfo_pubsub is a disco#info form field

ah :D

let me check that on ejabberd

edhelas, I'd take that one with a pinch of, well, anything. I don't think it has sufficient semantics defined to be useful in an interoperable manner.

Ge0rG, your update to the xmpp@chat.yax.im room has propagated :)-

I don’t find it a good name still, though

jonasw: I still think it should be printed on a t-shirt.

It's a much better description of MUC than anything you'll find in '45

but not a good descrition of the room

jonasw: I might reconsider a more on topic name once the current name gets painted onto some official XSF property.

there is official XSF property?

Like this MUC

jonasw, All the XEPs, for one thing.

right, for some reason I was picturing Ge0rG with a spray can in front of a house wall in my head

SCHRÖDINGERS CHAT would be a cool tag

jonasw: and a black hoodie. And the only light comes from a MacBook screen

itym the apple thing on the back side of the screen

which you taped over with a matrix sticker

jonasw: that, too

Are we speaking of Matrix or of *the* Matrix, though? 🤔

that one movie, of course

those three movies which actually are just one movie?

It's complicated™

nah, the one movie where people always thing sequels exist

but they’re wrong

do you folks think it would be good to add a specified disco#info/disco#items response (part) which allows things to discover anonymous ways to access MUCs?

I’m thinking e.g. a disco#info form field which gives the XMPP domain of a service which allows ANONYMOUS login and access to the room ✏

that would allow to add a "join in browser" button e.g. for support MUCs where such a facility is available.

Yes yes yes

well I think that Movim is now the first XMPP client to make use of muc#roominfo_pubsub /o/

edhelas, from which spec?

0045

Ha, what... that's been in there since 2006?

looks like :D

But there are no details on what it contains

(More or less what I said earlier)

I suspect it was from the days of "LETS PUBSUB THIS PUB SUB THING!"

So it's a reference to a pubsub node containing a list of the pubsub nodes associated with this MUC?

Ge0rG, Well, that'd make it a collection node, and those are unfashionable now.

because nobody can figure out if it's an item of elements or a list of items of one element each?

for me it's just pointing to a pubsub node

that's it

look, ma! a pubsub node!

:p

So who volunteered to re-do XEP-0357 with messages instead of pubsub, again?

Ge0rG, I don't think XEP-0357 really does use pubsub

Well I see no real problem with the PubSub-like syntax except that it misleads people to believe they could use a standard PubSub component to implement an app server.

It's misleading and it's adding overhead to understanding the protocol

And it isn't even actual PubSub.

I agree, but the question is whether cleaning this up is worth the compat foo you run into.

Then again the number of public app servers isn't too large I guess ...

Holger: who would use a public app server anyway?

Er what?

Holger: most clients are bound to use their specific one.

I meant app servers for publicly available clients.

Holger: if the XMPP server component supports both protocols, there won't be any compat issues

Holger: client devs who start at zero just implement the simple protocol in their app server / clients and be done.

legacy push installations remain as is

legacy authors sick of the pseudo-pubsub switch to the new protocol on a separate host name.

But yes, it's good enough™ and nothing will happen about the status quo.

at least it doesn't have a siacs namespace.

It will if someone cares enough to write up the new protocol

If they don't, then sure, it will stay the same because it's deployed and working

and working(*)

I just think we have more pressing issues than this syntax weirdness but I won't stop anyone of course.

Rough consensus and running code?

Ge0rG: I totally agree 0357 isn't good enough. It's not enough to implement working push notifications.

Whenever I start reading 0357, and I arrive at the first mention of 0060, my brain phases out.

Ge0rG: As for the syntax issue, you then need to decide whether to stick to (non-PubSub) IQs or rely on https://xmpp.org/extensions/xep-0357.html#sect-idm140285094926944 for error processing.

Unfortunately, that first mention is in §1 Introduction.

Yes that §1 'Note:' is insane.

Ge0rG, in the simple-protocol world, what would your next steps be? How would you implement your app server?

Ge0rG: Purging that 'Note:' would be a good first step IMO.

PubSub supports added payloads in the notification, at least for a <body>

MattJ: I don't understand the current XEP enough to make proper suggestions.

Probably actually implementing the protocol will improve my understanding enough to pinpoint the issues other develoeprs are highlighting for a year or so.

> The full process for enabling notifications requires initializing two separate push services: between the App Client and App Server, and between the App Server and the user's XMPP server. The XEP isn't actually helpful in making its point, either.

The Note in §5 is even more absurd than the one in §1

I need IBR to provision the push service node? What?

"possible, but not required"

Yes I'd ditch that sentence too.

Holger: please send PRs

Yaxim needs to register with push.yax.im somehow. That's all.

The XEP doesn't tell you how because no need for standardization.

ChatSecure uses some REST calls, Conversations some ad-hoc commands.

Nobody uses IBR, AFAIK :-)

Holger: somebody needs to streamline that XEP, then.

Yup.

I offered to maintain it back when Lance quit.

Holger: what happened next?

Kev took over -> less work for me -> Holger happy!

Seve happy to see Holger happy

Kev: XEP-0357 sucks big time. Please fix.

Holger: you still could send strategic PRs.

Not enough happiness to go around apparently

Probably happier community because I would've suggested adding business rules and whatnot. While I think the general consensus is rather to keep things unspecified in order to not loose flexibility.

Like.. PubSub and IBR

> It is NOT RECOMMENDED to allow in-band modification of push notification content settings. Such operations SHOULD be done out-of-band to prevent privilege escalation. What?

Holger: business rules would be great.

Ge0rG: Forget that configuration stuff. Should also be ditched. It's per-account rather than per-device and the idea seems to be that *users* configure things.

Nobody implements this.

So the XEP creates a smoke-screen of distractions for how to do irrelevant stuff, is using an overengineered protocol for the parts that it *does* specify, and is lacking a description of how to be applied properly?

Am I missing something?

Yeah the xep is a lot harder to understand than to implement

You can write an app server and the client code in a few hours

But it's pretty bad at communicating what you have to do

I don't _mind_ the overhead of pubsub. It actually allows you to reuse parts of your library which was probably the reason it does use pubsub Syntax

But it's really distracting and leads you on the wrong path

daniel: you mean it allows you to reuse parts of your *pubsub library*, provided you have one?

daniel: as a client developer who implemented it, maybe you can provide some strategic PRs to the XEP to make it less horrible?

well after three years of trying to get the business rules in and failing i don't really feal like it tbh

so my general recommendation to new comers is just to ignore the fact that it uses pubsub *syntax*

daniel: what was the issue with the business rules?

It can't be *that* hard to get a PR merged?

well if we had a mailinglist / forum / archive that would be searchable it'd be really easy to dig up those threads

https://mail.jabber.org/pipermail/standards/2016-February/030925.html

Date: Tue, 16 Feb 2016 13:32:16 +0100 From: Daniel Gultsch <daniel@gultsch.de> To: XMPP Standards <standards@xmpp.org> Subject: [Standards] XEP-0357: Push Notifications is missing business rules section

I don't see any refuseniks on that thread

From reading that, it appears to say that every message added to the archive should generate a push? (i.e. almost every chat message)

Is it meant to imply that's only for when the client is offline?

MattJ: that implies the question what "offline" exactly means.

I think we can agree that we need a push when the client is in 0198 hibernated state. But what if our server stack hasn't noticed a client hibernation event yet?

I've been thinking about pinging more aggressively after an "important" stanza was sent to a client

i.e. after an important stanza is sent, follow it with a <r> and have a low <60s timeout waiting for the <a>

That's what ejabberd does, except after any stanza (except when it didn't receive the responce to the previous <r/>equest yet).

MattJ: yes, following important stanzas with an <r> is great anyway

MattJ: yes that's the third rule or something

The offline one is the first

So to clarify, you're saying it should send the message via push even if it believes the client is actively connected?

Only if you haven't received the ack

What Holger said basically

Ok, just your business rules don't mention anything about acks

It makes it seem like the push is unconditionally sent for any message that gets added to the archive

right. yeah that should be clarified. for each push token only one of (a), (b) or (c) applies

Don't it send when CSI is on as well

Don't send the push? Why not?

right. or only for stanzas that actually move down stream

I mean, I'd assume you should send a push whenever a CSI queue flush happens

not for those held back by csi

Surely you want to push especially when CSI is active?

Ge0rG: Send all the time, for every stanza!!!

Because then the user gets to see the notification and can bring their client up to view it.

Doesn't it* maybe

Anyway Holger or Tilo are probably the better people to write it down having actually implemented it

Kev, you mean "inactive"? :)

I mean I still have it in my head somewhere but I might be forgetting details

When the client is inactive, when CSI is active.

Whatever.

Kev: would you mind giving the XEP over to Holger so we can clean up the mess?

Moar ambiguous!

And by "we" I mean "he" :>

Ge0rG: Patches welcome.

Holger: ^

I think the basic logic is "Wait a bit after a stanza, see if you get an ack from the client, if you don't then send a push notif", right?

Kev: My impression was that you're not happy with business rules.

Kev: https://mail.jabber.org/pipermail/standards/2017-May/032701.html

I think I said that I was in favour of them, just not normative, didn't I?

Yes, I did :)

> I came up with a somewhat different scheme, which I’d like to also be allowable Yay!

Another thing that needs addressing is the "ChatSecure case" where the app server basically wants to know whether the notification was triggered by a human-readable message or not.

Or some per-client configuration to limit notifications to only specific types of stanzas.

Holger: what kind of non-human-readable events should trigger push?

Chris suggested this: https://mail.jabber.org/pipermail/standards/2017-July/033085.html

There is really no excuse for low-priority pushes.

Ge0rG: Jingle calls, any other IQs, or if you try to keep a 0198 session alive, actually any stanza.

Cache stuff maybe?

Holger: jingle calls are high prio

Then again you could argue that keeping the session alive is an ugly hack that needs to be fixed anyway.

Like disco

the only excuse I can see is "okay client, I haven't heard of you in a day now, and I have those 10000000 stanzas for you in my 0198 queue. Please come and fetch them any time soon"

Ge0rG: Yes, except that I will do this with a way lower number of stanzas.

Ge0rG: Why not just drop the stanzas?

At that point you're almost guaranteed most are stale.

Kev: because the Gods of XMPP will be mad.

Ge0rG: So IQs should just time out?

Kev: you can't simply drop stanzas from mid-stream, you'd have to terminate the 0198 hibernated session.

Yes, that's what I mean.

Holger: I have no easy answer to that.

Ge0rG: Sending clients should cope with such timeouts? (Currently they don't.)

Ah.

Holger: somebody should write Business Rules.

Holger: the path of least breakage would be to low-prio-push the client on an incoming IQ, yes. The better long-term solution would be to respond from the server.

Maybe a mid-way would be to kill the 0198 zombie on an incoming full-JID IQ ;)

Long-term I'd ditch the 0198 session.

Right now we this will break notifications for MUC messages.

Holger: but session establishment is expensive

That should be fixed.

In addition to roster versioning, we'd need presence versioning.

I think Kev argued that way and I agree on this.

But I'd like to make push notifications work before the year 2025 and I think we need the 0198 hack until then.

I think somebody proposed to treat XMPP IM as a database synchronization problem, some time ago

Holger: I agree

By the 198 hack, do you mean sending of <r/> or killing sessions?

Kev: Keeping sessions alive for disconnected push clients.

So yes, I'm convinced we need two push priority types.

Kev: Mostly to get MUC notifications.

> I think somebody proposed to treat XMPP IM as a database synchronization problem, some time ago Isn't that matrix?

Sorry, I've suddenly realised I've missed a whole part of this.

Ah, MUC, right.

Yes, MUC doesn't work with multi-client. We should replace it. Let's call the replacement MIX )

:)

daniel: I didn't say *distributed* database sync.

An alternative might be implementing some other hack to keep you joined.

Kev: "But I'd like to make push notifications work before the year 2025"

Kev: yes, let's also add a dozen of unrelated features into it to make it hard to implement.

I don't think anything in it is unrelated :)

But yes, we don't have MIX right now. Hacks until then seems likely.

Are there any experience values on the delivery jitter of low-prio pushes on iOS? They are deemed "unreliable"

Ge0rG: Seems to vary a lot. I think it depends on things such as the current battery level, on the notification rate, on how frequently you use the app, on the moon and who knows what.

Holger: let me rephrase my question: is the median latency of low-prio push sufficient to obtain IQ results without the remote side timing out, typically?

Ge0rG: I.e. on some devices, silent notifications seem mostly reliable; other users seem to never receive them; others are in between.

Is there some kind of distribution curve on the notifications that do arrive?

Ge0rG: Dunno numbers, but either way you can't rely on it. So ejabberd actually won't let low-prio pushes trigger a timeout of the pending 0198 session. But yes the IQ will time out.

daniel / Holger: To check I understand, the rules here are basically: * Make sure the server has a list of all clients/push requirements and a map from these to sessions * On a new pushable event, send for everything that doesn't have a session, or where the session isn't sufficiently responsive And that's the crux of it?

Kev: yes

In terms of normative text, the 'know who I am' seems sensibly normative, and the 'responsive sessions' seems like a suggestion to me.

Yes.

A suggestion that could go into 0198 I guess.

Ah, no, that's different.

You both want Push to say "If it's not responsive, send anyway" and then you might want 198 to say "terminate if unresponsive", but those aren't the same.

Ok.

Don't you?

Yes I agree. Sometimes I'm easy to convince :-)

Holger: so you just agreed to write down all the biz rules? Great!

!praise Holger

^C^V Kevs sumary?

It's confusing how Conversations is both #1 and #6 of the MUC list.

will be better once we have language information

which was the dino MUC again?

chat@dino.im IIRC

this is weird

It is. And the domain isn't even a MUC domain, breaking poezio's MUC discovery.

yeah

not only poezios

-version dino.im

MattJ: dino.im is running Prosody version 0.10.0 on Linux

Component "chat@dino.im" "muc" ?

Zash, seems more like modules_enabled = {"muc"} to me

no, the domain doesn’t expose the muc feature

jonasw, don't think you can do that

jonasw, you can make a bare jid a component tho

super-weird thing

disco integration might not work tho, maybe we should fix that

at least the disco#items isn’t confusing

please don’t

-contact prosody.im

Zash: prosody.im doesn't have any contact addresses

What about forbidding such corner cases?

Ge0rG, ytho

Ge0rG, you might wanna destroy dino@chat.yax.im btw

There really is no reason to allow joining a bare JID MUC, or to have a MUC on a non-MUC domain.

Ge0rG, I agree on the former, but not necessarily on the latter

Info> Room dino@chat.yax.im destroyed

\o/

Okay, it's breaking assumptions that need to be shaken up from time to time. But I'm pretty sure we have enough corner cases for client devs to care about, without adding such oddities

Is there really anything in the protocol that forbids it tho?

No.

if the disco#items were correct (i.e. contained the MUC), it might be okay actually

jonasw, that's what I was referring to for fixing

yeah

I’m not that scared of the result anymore

I’m scared though what’ll happen when conference.jabber.org is fixed.

that’ll be some serious amount of data :)

I hope we are going to end up with less Conversations on the top 10 list.

Isn't it in dire need of some spring cleaning?

Zash, very dire, very need

Ge0rG, I doubt that

The existence of conversations@conference.confersations.im is especially confusing

covfefesations

Ge0rG, but if that bothers you, maybe you could go and find more MUC servers :)

https://xmpp.org/extensions/xep-0045.html#disco-service-features "The service MUST return its identity and the features it supports."

jonasw: what's the default nickname of Christopher?

Maybe it should be called Chatstopher?

Ge0rG, it doesn’t join at the moment, but it defaults to '-C. Muclumbus'

jonasw: did you pre-populate it with the MUC domains from the old muc search?

no, the old muc search is kaputt

GDPR’d

I used the compliance tester

added all domains and I have a recursive disco#items explorer going

jonasw: https://github.com/pfleidi/yaxim/blob/master/res/values/servers.xml#L124

neat

and xmpp.net

let’s insert those

jonasw: you can also feed the explorer with the `xmpp_servers` array as well

indeed

meh, again I wish that postgresql had a INSERT ... ON CONFLICT IGNORE thing

oh on conflict do nothing

Oh is that the thing preventing us from having nice things with postgres?

Was that the thing SQLite has?

https://www.postgresql.org/docs/current/static/sql-insert.html

I think SQLite has some ON CONFLICT that you can configure when *creating* the table

You mean ike the insert into table ... ON CONFLICT DO NOTHING mentioned?

intosi, except that I’m on postgres 9.4, yes

No time like the present for an upgrade then ;)

ahaha

that is a ratstail of things for which I’ll need a weekend or so

intosi, did you have any chance to look into @conference.jabber.org?

No.

Ge0rG, thanks, that brought a few new domains

Between a server upgrade, other work things, and not stopping my beloved keyboard from drinking coffee, I had few cycles left.

(bit over a hundred or so)

intosi, no worries :)

also, sorry for your keyboard

(just wanted to make sure I finally found someone with +w on the right box)

jonasw: glad I could help

oh right

jonasw: I might also extract some (non-public?) domain lists from s2s logs, spam bot logs etc.

maybe

we need to do something about the invalid data form used by XEP-0157 though

Unfortunately I don't have the full search.wensley.org.uk dump any more.

could someone take a quick look on whether this is editorial or not? https://github.com/xsf/xeps/pull/650/files

I feel it is because the form specification in the document already specicfies list-multi

I don't think the type attr is required on type=submit (?) forms

They'd seem redundant since in most cases you are sending it to the entitiy you got the form from

indeed. type is MAY

damnit

Doesn't hurt for readability tho

jonasw: I would argue not editorial, it's changing protocol.

Or, at least, if you're ever in doubt, just throw it up to Council.

Kev, I’m also wrong, I’m going to close the PR.

I'm not even sure that change is 'right', is it?

it is not wrong (type is MAY)

One doesn't give the type on a result generally.

but it’s not required either way

> For data forms of type "form", each <field/> element SHOULD possess a 'type' attribute that defines the data "type" of the field data (if no 'type' is specified, the default is "text-single"); fields provided in the context of other forms types MAY possess a 'type' attribute as well.

Indeed.

So I'd argue that examples containing it is likely to lull people into a false sense of security that they don't have to correlate.

yay, that spawned aioxmpp issue number 200

yupp, gonna retract the PR

Hm, if a submitted form has conflicting field types, how loudly should you cry?

I'm trying to organize an XMPP sprint ("hackathon", whatever suits you) in Cambridge UK around August (dates TBD). Topics are also TBD. Please join xmpp:xmpp-sprint@chat.cluxia.eu?join if interested :)

https://cryptpad.fr/code/#/1/edit/gSOmgqjDKPIBQmeK41-Log/9wCZoyjHTNX07IrrYaJTSbcV/ as a preview, I still have a few info to put in there

hey guys, lets start our member meeting in 3 minutes

The suspense!

here is our Agenda for today: https://wiki.xmpp.org/web/Meeting-Minutes-2018-05-29

1) Call for Quorum

as you can see, 33 members voted via proxy, so we have a quorum

2) Items Subject to a Vote

new and returning members, you can see teh application page here: https://wiki.xmpp.org/web/Membership_Applications_Q2_2018

3) Opportunity for XSF Members to Vote in the Meeting

anyone here who has not voted yet and wants to do os now?

(sound of crickets)

s/crickets/suspensfullness/

looks like none, then I will start counting the vote snow ;-)

now

4) Announcement of Voting Results

Drumroll!

when you reload teh page at: https://wiki.xmpp.org/web/Meeting-Minutes-2018-05-29#Announcement_of_Voting_Results

you can see the results

all reappliers were accepted, and we had no new applicants this term

congrats to everyone

5) Any Other Business?

I'd like to say thanks to Alex for a job well done as usual.

seconded

Thanks Alex!

6) Formal Adjournment

I motion that we adjourn

Seconded.

out of curiousity has a vote ever resulted in a member not being renewed or accepted?

thanks everyone. Will update the lists tomorrow in the AM and send out the results to the lost

moparisthebest, Yes!

moparisthebest: yes

Congratulations everyone, good news

how did that happen? do you just really annoy other members or what? :P

Other than the time nobody knew bears real name?

Zash, There was that, and, erm... Solaris? I can't think of the nickname he used.

bear is the famous one ;-)

yes, I am the example everyone remembers about my membership being denied :)

bear: why so? (I do not know the story)

The tale

the membership application didn't used to have a real name part, and I go by "bear" everywhere including email

so when I forgot to update my application people properly didn't vote for me to stay as a member

my application had "Mike Taylor" IIRC and some folks were not making the connection - trying to remember all of the details

bear: ohh I completely understand. I'm glad to know it went like this and not in a bad way heh :)

Thanks for explaining!

I'm actually replying to some questions regarding XMPP on his thread, if you see some weird things do not hesitate to correct me https://www.reddit.com/r/opensource/comments/8myh78/movim_responsive_webbased_social_xmpp_client/