XSF Discussion - 2019-08-06

Ge0rG: sure, but I don't think it is good to write the XEP without implementing at the same time

marc_: yes, and it's had to motivate people to implement a XEP full of TODOs

Ge0rG: it's also hard to motivate somebody to write a XEP if no client will implement it *this* way ;)

Ge0rG: solution: talk to client devs and agree on some user stories, UI and UX

marc_: I'm a client dev. I know how I'd implement the code, the UI and the UX

marc_: I need somebody from the prosody team to stand up and to hack the server side support.

Ge0rG: there are other clients as well ;)

marc_: this is a lie.

I mean, yes, there are other clients. But so far I haven't found one where the developer is interested in good onboarding UX and has the time to tackle it.

The only maybe-exception is Quicksy, which is sacrifices the most important selling point of xmpp

Ge0rG, or you hack the server side support yourself

or find someone non-prosody-team to do it

prosody is quite hackable in my experience

jonas’: I read that as "I volunteer" from you

you can certainly do that, but I’d question whether that’s correct

or rather, I would actually volunteer, but there’s no way I can make any deadline commitments

Ge0rG: onboarding is only important if the UX is good afterwards ;)

jonas’: see, and this is why there hasn't been any progress for a year now

jonas’: I'm not picky about the who, but somebody needs to stand up

Ge0rG, please avoid passing judgement on my time scheduling

(or anyones really)

Ge0rG, I’m not saying "I can’t give you any deadlines" because it’s not important to me or because I want to annoy you or I want to stop progress. I’m saying that because it’s the only realistic thing I can say as things stand right now.

jonas’: I'm not criticizing you at all.

maybe I’m overly sensitive about that right now, that’s surely possible. sorry

jonas’: :)

Ge0rG: try to discuss this topic on froscon, please

marc_: this is a topic for mobile devs. I'm not sure whether dino qualifies ;)

not only mobile devs IMO

> not only mobile devs IMO +4

And the developer of the well-known and widely popular android client seems to disagree with me in most UX questions.

marc_: desktop clients already fail at taking xmpp: URIs. How are you supposed to make them scan a QR code?

> And the developer of the well-known and widely popular android client seems to disagree with me in most UX questions. Maybe not in this case... just try it. We don't need another XEP only half of the clients implement

This makes UX even worse...

> marc_: desktop clients already fail at taking xmpp: URIs. How are you supposed to make them scan a QR code? Can be fixed?

marc_: requires motivation.

There has to be room for experimentation and all clients don't need to be identical.

Zash: are you going to implement the server side of 401 for me?

but please not in a quirky hacky way but as a proper module.

I can't promise anything right now

> There has to be room for experimentation and all clients don't need to be identical. Yep

marc_: scanning a QR code requires a camera.

Ge0rG: displaying QR codes not ;)

I demonstrated a modified Gajim Version a year ago? 🤔

█▀▀▀▀▀█ ▀ ▄█▄▄▄ ▄ █▀▀▀▀▀█ █ ███ █ █▄ ▄▄██▀ █ ███ █ █ ▀▀▀ █ ▀█ ▀ █▀ █ ▀▀▀ █ ▀▀▀▀▀▀▀ ▀▄▀ █ ▀ ▀ ▀▀▀▀▀▀▀ ██▀▀▄ ▀ ▀▄ █▄ ▀▀█▀ ▄▀▀▀▄▀ ▀█▄▄▀█▀█▀ ▀ ▄▄▄▀█ ██▄▄ ▀█▄▄▄▀▀▄▀█▄▀▄██▄ ▀███ ▀▀█ ▄▀▄█ ▄▀▀█▀ █ █▄▄ █▄█ ▀▀▄ ▀▀ ▀▀▀▄▄▀█▄█▄▀█▀▀▀█▀█▀█ █▀▀▀▀▀█ ▄ ▄ ▀▄▄█ ▀ █ ▀██ █ ███ █ ▄ █▀ ▀ ▀▀█▀██▄██ █ ▀▀▀ █ █ █▀ █▄ ▀██ █ █▀ ▀▀▀▀▀▀▀ ▀▀ ▀ ▀ ▀▀▀▀▀▀ ✏

(which doesn't work if your terminal is white-on-black)

Or a non-fixed-width font

What's your point? You need to generate a token for 401...

Zash: s/or/and/

oh, wait. triple negation.

marc_: my point is that most desktop developers are having other problems than easy onboarding UX

But they may have valuable input...

marc_: right. Developers _always_ have valuable input on UX topic. This is why most XMPP clients are well-polished and usable.

What was the QR code for?

Zash: don't you have a faux android phone?

Ge0rG: just be a bit more constructive and think more as community ;)

Ge0rG: I just woke up and sat trough a meeting without getting coffee first, so excuse my cold context cache for this topic

What was communicated via QR? URL? Show the URL on the screen so it can be typed?

Tho it's no fun to type a long hexadecimal or base64 code 😕

Zash: http upload a picture of the QR code.

Conversations can do that.

HTTP upload to a fax service?

marc_: pardon me my sarcasm, but in the last years I have tried to ignite a better appreciation for UX in the xmpp developers, and there was no significant contribution. 0379 is a prime example, and 0401 isn't even there yet.

Zash: how much FEC do you need to survive faxing?

Did PARS require more than saving the complete original presence subscription request?

Ge0rG: I understand but my time is limited and I would like to progress as community with this XEP

Zash: from the server? no

marc_: then please invent a mechansim to force the community to participate. If you pull that off, I'd like to make use of it as well, for a number of other important topics

marc_: or you have to take the community members that are actually interested on their own, i.e. me

marc_: you could also write a mail to standards@ or jdev@, asking client developers for feedback on the UX side of things

we will figure out the protocol, it's the easy part.

The best way is probably to make a thing and show it. Takes some time and energy tho.

Zash: I can make the client side in yaxim, but 0401 needs server support

I've been asking for help for a year now, or maybe two.

But there's always a million things to do and only so much time and energy per day

“Ge0rG: then please invent a mechansim to force the community to participate. If you pull that off, I'd like to make use of it as well, for a number of other important topics”, /me thinks about all the free labor he gets during sprints :-°

pep.: how many mobile client sprints have there been so far?

one of my next ToDo steps is to make a writeup of the unwritten rules of extensibility in XMPP, since I get the feeling that there are different opinions on that and having a written down thing which is ratified by council would be good

I’m thinking along the lines of stuff like "is it allowed to put arbitrary (separately namespaced) elements in arbitrary places of existing protocols (provided you don’t do mixed content, which is always bad)?"

except into features ;)

those rules would then find their way into validating parsers which then need to deal with that type of stuff

there would be rules on how to deal with unknown content based on whether you’re the recipient (@to) of the stanza or not

jonas’ Amend https://xmpp.org/extensions/xep-0134.html and/or https://xmpp.org/extensions/xep-0143.html (maybe others)?

'134 maybe

'143 is probably not read by folks who write parsers

"Ge0rG> pep.: how many mobile client sprints have there been so far?", so far I don't think there's been anything particularly centered on mobile, but you're welcome to propose something :)

"jonas’> [..] I get the feeling that there are different opinions on [rules of extensibility in XMPP]", I agree

I don't

Cause I believe it is simply: It's ok to extend, if you can live with the entities not understanding the extension, but there are exceptions like xep30's feature

Well, the extension has to be in a different namespace, you can't shove things into existing namespaces (without negotiation).

I am even not sure if this is true, but you usually want a different namespace

Ge0rG: i'm not even subscribed to these lists ;)

marc_: to be honest, I'd like to move 0401 into a state where it has a reasonable chance to become part of Compliance Suite 2020

Where was that Logitech/XMPP/home automation again? And what happened to that?

Ge0rG: let's work on it then :)

https://arstechnica.com/gadgets/2018/12/logitech-firmware-update-breaks-locally-controlled-harmony-hub-systems/ found it

marc_: yes. This is why I pinged you.

marc_: do you want to further improve the XEP? Or are you looking for feedback from client developers?

In the latter case, please open a thread on the standards@ ML

Ge0rG: can you open it, please? I don't have time to work on it until end of August

Would be nice to get some feedback in the meantime

marc_: I don't know what you want to get feedback on. I have a very clear vision of what to do and how to do it.

Ge0rG: post it on @standards and ask for feedback then

The "ask for feedback on standards@" thing doesn't really work either tbh :/

Sometimes it spawns a discussion here if you're lucky

If you got my idea of somehow spilt adding contacts with server side pars and server invitation you can propose this as well

https://mail.jabber.org/pipermail/standards/2019-August/036341.html for this example this. Or this https://mail.jabber.org/pipermail/standards/2019-August/036338.html (this we talked about it here afterwards..)

marc_: I'm not sure where and why you want to split things

Ge0rG: that's why I hate discussing these things via chat ;)

It's much easier to do this in RL

marc_: I'm not so sure

"just" go away, and that @id magically gets fixed?

pep.: exactly

how many IDs does a message really need?

From what I understand you need origin-id because you don't have the same guarantees with @id. And as much as I don't like legacy, that will always be a thing, and I even if we said "@id now means XXXX", you wouldn't know if what you receive actually is what you expect. At least with origin-id you "know", otherwise it just wouldn't be there

Ge0rG: have you been on a sprint so far?

(There will be incorrect implementations, but that's another issue)

marc_: yes, I think once so far

Ge0rG: are you planning to participate to one again?

pep.: in that case, you could add an element `<my-id-is-much-unique/>`

Ge0rG, I think the issue was that some entities rewrite these @id

But otherwise yes

marc_: there are none planned

pep.: in that case we should at least force origin-id=@id at the sender ;)

I don't disagree with that

That's what my implementation does

but it's a hacky legacy mess.

Now I just need to figure out if we need it everywhere or just in some specific places..

I can start sending it all the time I guess :/

pep.: I suppose they only need to be in non-ephemeral messages

Ge0rG, I agree it's a legacy mess. We need XMPP42 and proper @id

Why is https://wiki.xmpp.org/web/Sprints/2019_September_Stockholm in the newsletter but not on the wiki frontpage?

hmm. dunno why it's in the newsletter even. Not that we're telling off people, but we're already 10-11 and that's a good number

At least for the venue we have

We could probably do some more, but not a lot more

pep.: that might be a good info for the top of the wiki page.

Sure

"Cisco’s Extensible Messaging and Presence Protocol (XMPP)"

https://blogs.cisco.com/security/cisco-scores-big-with-a-new-ietf-approved-internet-standard

Looks like we can all go home now.

so say i have my last mam stanza-id, and i query mam with that every day. but server upgrades and loses the archive

so now that stanza-id is not anymore in the archive, and when i query i get a item-not-found error

should i assume now the archive is lost? and treat it like first time use, query 7 days or whatever i would do on first startup?

flow, wut. The IETF doesn't have rules against that? Especially when they're closely related? Though I guess Cisco could have infiltrated the IETF and just reversed the decision :P

lovetox: FWIW ejabberd just returns the next n messages still archived in this case, but yes as per the current MAM spec you'd get item-not-found. I guess the alternatives are either what you said or full sync in that case. Answer isn't obvious to me.

Holger, the server cant know the next n messages

ah ejabberd can because it uses timestamps as id

Gajim right now just fails forever

there is no fallback if a stanza-id is not found :D

Yeah. 0059 suggests that behavior in case the server does know, but 0313 disagrees.

lovetox: If you usually do a full sync no matter what except on first start, I would think it makes some sense to also do a full sync after item-not-found.

not sure fullsync is the answer to the ultimate question of life, the universe, and everything