XSF Discussion - 2020-11-04

Is the XMPP logo free to use in websites next to xmpp: links, the way, say, the GitHub and Twitter logos are sometimes used next to links to GitHub and Twitter accounts?

Tim, go for it :)

I just switched from subscribing to planet.jabber.org's Atom feed to the RSS feed after I noticed my feed reader was missing a number of items

They seem to be in the feed ok, but then the W3C validator throws up a handful of issues (likely issues with the source posts)

MattJ: write some Javascript to fix the issues and inject it from your own blog?

Good idea

MattJ: Thanks! It's in the footer at https://circulex.nz/

Is there any client left that depends on stuff like the crossdomain.xml file, or using the http://www.jabber.com/streams/flash namespace? From what I can tell, this is old Flash-related stuff. I'm considering to drop support.

Flash is very EOL at the end of 2020. Go for it.

Yeah, I'm all for killing Flash with fire. I'm primarily worried if something else is piggybacking on those mechanisms though.

nothing matches streams/flash in xeps

nothing matches crossdomain

kill it with fire

if anything piggybacks on it, it is wildly nonstandard and piggybacking on a technology from the previous decade (no matter which way you use to count decades) :) ✏

if anything piggybacks on it, it is wildly nonstandard and piggybacking on a nonstandard technology from the previous decade (no matter which way you use to count decades) :) ✏

Thanks 🙂

Yuk

// We need to allow the NULL character, however, for Flash XMLSocket clients to work.

No matter how I count, it's technology from two decades ago ;)

Doesn't mean that people aren't still using it though...

Grep your forum for hints maybe?

it's one of the few projects that have an even worse security track record than libpurple.

There's actually a couple of hits on 'flash' in our forum. Half of which related to people asking if that's a security issue, the other half questioning why their Flash client isn't working with Openfire. :-S

(and a gazillion of hits on notifications that are 'flashing' somewhere)

> Yeah, I'm all for killing Flash with fire.

killing it with... Openfire ?

I'm now annoyed with myself that I didn't think of that.

moparisthebest: 😁

Ge0rG: why does 389 rely on unauthenticated IQs?

marc: https://xmpp.org/extensions/xep-0389.html#sect-idm46110484684112

I don't understand this part but it is an option not necessary, no?

I mean i don't understand it's use case

marc: I haven't read it either, just saw that IQs are used after stream negotiation, which I read as before auth

or maybe before binding? Dunno

I don't know but it is not necessary IMO

but the question is: is it supported?

No, you say it is necessary for 389 which is probably not the case

Ge0rG: talked to sam, it is after auth

marc: well, I wrote that it "relies" on them, but in that case I was wrong.

👍

It's for the case an admin wants to create an account on the server, for example

I'm surprised that Sam didn't point that out

He missed that point

Ge0rG: if I understand it correctly the entire on boarding process can be based on 389

marc: that's great. Implement it, write it down, submit a XEP

We can add it to the list in the updated 0401

I'm sure that it will be added to smack 4.5 one day, which I'm going to integrate into yaxim around 2023

Ah, Sam has clarified the intended use case as well

Ge0rG: pre-auth token is not implemented in smack either ;)

marc: no, but iq is, and adding a custom element is rather simple

marc: https://github.com/yaxim-org/yaxim/blob/master/src/org/yaxim/androidclient/packet/PreAuth.java

Ge0rG: I have no comparison but smack is quite extensible isn't it?

https://github.com/yaxim-org/yaxim/blob/master/src/org/yaxim/androidclient/service/SmackableImp.java#L855-L857 is the actual implementation

marc: yes it is, but implementing one new IQ is an order of magnitude or two easier than implementing a new IBR protocol