XSF Discussion - 2018-01-30

There was a piece of news indeed.

Neustradamus, where would we have to have announced that information? we announced it on the jdev@ mailinglist, in this muc, on the xmpp.org blog. what was missing for people to pick this up? ✏

english is hard

My clients will expire in March. Need to resubmit urgently.

ah, are we already a year in?

time flies

fruit flies too

like an arrow, or like a banana?

Unspecified fruit.

Like a sparrow.

I always forget I have merge power on xmpp.org. I should recall that more often while Guus is busy with SCAMing.

JONAS STOP PRESSING BUTTONS MILLISECONDS BEFORE I DO!

*click* miss *click* miss (<-- me, this morning)

Guus, I think you’ve set OLCUC in your termin… oh you fixed it

:)

I only merged one thing, didn’t I?

and closed an issue :)

ah right

that’s going to be a fun discussion

oh sweet, the build failed

Guus, or someone else with power, could you take a look? https://hub.docker.com/r/xmppxsf/xmpp.org/builds/borgns4wfclmgndzdyqvnjc/

the CI passed

a simple re-trigger may do the trick

(I don’t have the power for that)

again? Same thing happened yesterday

I pushed an empty commit now :)

https://hub.docker.com/r/xmppxsf/xmpp.org/builds/

right, a new build is already queued

I wonder why it errors out occasionally

Do you see a non-empty log or something?

no

I was hoping you might, with your additional permissions etc.

weird

nope

jonasw: here some days ago

Neustradamus, well, the policy has been active for nearly a year now

so clearly we haven’t done a good job communicating it

but I’d like to know what we could’ve done better

yes I managed before (some years ago) ^^ The lists were more importants

Neustradamus, cf. https://xmpp.org/2017/03/new-xmpp-software-listing-rules/

thanks jonasw

The idea behind that rule is btw that *application authors* enlist their software, as long as they consider it as maintained.

(I for one don't care much about _who_ is doing the listing, as long as _someone_ is keeping it up-to-date - that's enough to keep the really old, unmaintained and undesireable stuff out of the list)

Guus: the effect I want to avoid is that loyal users of a client abandoned a decade ago insist on keeping it listed.

well, if it has loyal users, it probably has at least some reason for being listed

arguably not the best of reasons, but I'd be able to live with it

(if it has loyal users, it's by definition not completely abandoned)

Guus: and then you'll end up with Pidgin/OTR, which breaks the experience both for the newcomers and the people they are trying to talk to.

Ge0rG: if people want to use pidgin / OTR, then that's an issue that's to be addressed seperately.

I think we shouldn't put to much thought/motivation in the decision we make to list something. What we have now is something that I'm pretty happy with.

Guus: the list is obviously for newcomers. If you have a friend who insists on you getting abused with pidgin/OTR (just to stick to the example), that's fine with me. But please keep it off the official list.

let's not overthink something that works 95% well.

Ge0rG, I’m planning to write an XMPP bot that reminds subscribed people about the expiration from the list of clients/servers/libraries (when I have 15 minutes and enough motivation)

that would help

mathieui: that would be awesome.

perhaps we should _not_ do that

as that will facilitate automatic, no-brains-used, renewals

mathieui: I suppose all the proposals of client maintainers having a structured metadata file somewhere are way too complex

which would cause the list to fill up with stale data again.

Ge0rG, I don’t

but it would need to be done (we discussed it briefly at 34C3)

I do disagree with there being a need for automatic renewal, or a reminder facilitated by the XSF.

Guus, I wasn’t planning of having it being any kind of official

the thought behind the forced expiry is that people need to actively be maintaining the software listing. Any form of automation fights that principle.

it’s automation of reminder; when doing things once a year, it’s very easy to forget

mathieui: you really don't need to wait a year to apply for a renewal. I think I've renewed my stuff about three times, last year

(pushing the expiry date by a couple of months every time)

Guus: just because you can directly commit to the repo, everybody else needs to make a PR

the PR can be made in github (which is exactly what I do)

PRs get accepted within a couple of hours, typically

Guus: by yourself? ;)

I'm just saying that it would be impolite for any non-editor to make updates far more often than strictly necessary.

two / three times a year is hardly 'far more'

I'm not saying that individual authors should have some kind of reminder - but please lets not facilitate that - it defeats the purpose of our expiry mechanism - that's all I'm saying.

Ge0rG, this is only a one-line change with an explicit title, so it’s essentially a two-three clicks effort for editors

I guess I’ll just put that in the topic of the poezio room

fwiw: the readme provides links that allow you to directly edit the files: https://github.com/xsf/xmpp.org/tree/master/data

There are only nine warnings in clients.json. Apparently nobody cares about the `platform` field.

WARN: entry 'GreenJab': undefined platforms: 'IBM i' (the allowed platforms are listed in platforms.json. If you think a platform is missing add it and mention it in your Pull Request)

WTH is IBM i?

jonasw: time to swing the Hammer of Enforcement!

Guus: thanks very much :)

So, what's with all those clients running on undefined platforms?

what do you mean?

https://xmpp.org/software/clients.html <-- looks okay?

I'm guestimating that we kept the old list intact, including the no-longer-supported-platforms, only to enfore platforms when the entry is actually renewed?

Guus: oh, thanks for the explanation.

Guus: interested in a s/unsupported/"other"/ PR?

well, if the entries with unsupported stuff have not been renewed and therefore are not being displayed anyway, I don't really see the point - but let me not stop you putting in effort to improve things :)

Guus: is the list on the page autogenerated?

rion: yes it is

it'll probably take some minutes

yeah, it takes some time

psi is on there now though

rion: what's the difference between Psi and Psi+?

Ge0rG, don’t bother with replacing unsupported platforms with "other". we’ll deal with it when they’re renewed, I think that’s most sane.

Ge0rG, admit it, you spoofed the timestamps of your renewal!

jonasw: I wanted to see if anyone notices.

ha

I do

(but I only did because you lured me into the diff with the trademark remark)

Ge0rG: Psi+ includes some experimental patches not yet merged to Psi.

I happily accept anything that passes the parser (which does have a check for forward-dated renewals)

also, I happily accept stuff from people I deem trustworthy.

not sure if that is a good glance or not

rion, when psi will support carbons, mam, SM and so on?

rion: which one would you recommend to normal users?

you should really hate users to recommend them Psi :P

zinid: carbons and SM are supported. mam is in progress.

Ge0rG: stable one.

rion, supported in which version?

zinid: one on https://psi-im.org

rion: maybe you shouldn't be advertising psi+ then? ;)

Ge0rG: It depends on users. Some of them like new features.

rion, the question is, is Psi+ stable?

Less then Psi. But mostly yes. We don't make releases for it. So it's possible to have something broken with each next build.

rion, I’d argue don’t advertise this on the client list then

I agree with jonasw - if you don't have releases, you shouldn't be advertising it to normal users.

rion, I'm suprised you saying that about Psi+

I've been using it for... I cannot remember

And I would not say is not stable or anything

I'm really surprised. And features don't come to Psi quickly in any way.

Or have that changed?

for example if you enable multi-row tabs you can have rare crashes and kind of bad rendering on hidpi.

I use Psi+ all the time. It's works pretty stable for me. But usually I don't use the features introduced by those patches.

SouL: My goal after all to merge these projects into one. And I already merged quite a big chunk of patches. Psi+ keeps only those I considered bad-designed, useless or unstable. I'll refine and merge them all with time or may be some of them will be converted to plugins.

One of the XSF's earliest GSoC projects :)

(Although I doubt there's much relationship between the current code and the original)

rion, that sounds great! I understand now then :(

:)*

or may be I'll join Swift team instead )))

Ha :D

I hear that's a thing Psi devs sometimes do.

Is remuneration involved in that process?

rarely

> (12:03) test: is xmpp providing gradle ?

what

that's form our support muc just now

I've lost motivation to report issues in Swift rather fast, because all my tickets were closed immediately with either "moved to private tracker" or WONTFIX.

Guus: the right answer is: "no, because gradle is not based on XML. But we offer ant"

maven?

Can do.

rion, didn't work for me

zinid: you were a Psi developer?

Ge0rG, no

I tried last version and it didn't have any carbons or sm support

You don't need Carbons on a desktop client. Just configure it to priority 127 and beg that nobody does resource locking.

lol

typical jabber

zinid: no idea. I believe this code wasn't changed since the release. and both features work good for me.

I'll check later

I only remember that this time last year, Psi didn't have support for Carbons.

so CVE-2017-5593 only affected Psi+

rion, just checked 1.3, seems like SM and Carbons are working indeed, thanks

still MAM is lacking...

and modern UI would be much appreciated

wow, captcha support

I'm impressed

:)

rion, Psi doesn't close a stream correctly, which leads to stalled resumed session ;)

it must send </stream:stream>

Yes. I know. I remember this bug and in fact Psi has code sending stream close. I had no spare time to debug yet.

I see

the main problem of jabber is that development is done in spare time only ;)

+1

and when it isn’t, it actually flies, kinda. see c.im

zinid: do you have a vacancy in ProcessOne? =)

rion, no :) We already fired a half of staff

Why?

Now they will keep working in working on xmpp in their spare time...

mimi89999, because the number of customers has decreased drastically in recent years since XMPP is degrading

so we don't need an army of developers anymore

🙁

But why people don't like XMPP? I guess FB hidden marketing and network effect is really strong...

It's neither HTTP nor JSON.

mimi89999: because it has a reputation of outdated protocol

I think it would be a mistake to pin a company's success on a protocol's reputation

One may argue, but the problem is that reputation is not a technical term, you cannot improve it by creating a better protocol

SMTP isn't exactly cool nowadays either, but it still does the job it was designed to and many successful companies are based around it still

MattJ: sure, but protocol degradation is a part of this for sure, I know that because you cannot attract new customer because they don't want xmpp

So we actually stopped mentioning xmpp at all

MattJ: SMTP is a special case because it was so ubiquitous, no? I bet business around it is declining as well, just from a very high level.

Point them to good articles about XMPP.

Like that Json API on HTTP is better (not).

Holger, as far as standard IM protocols go, I'd say XMPP is fairly ubiquitous

MattJ: not in the sense of user base

Combine WhatsApp with Google and (once...) Facebook and that's a fairly large user base

What failed is that none of these federate(d) in the way they were essentially forced to with SMTP

It's hard to call whatsapp's protocol an xmpp 😁

It's derived from it, at least, and I think that counts enough for the purposes of this discussion

It used to be so (because based on ejabberd), but not anymore

MattJ: Well the discussion was about the business perspective, where I think WhatsApp & friends are irrelevant. If you build your business around SMTP, you can still reach many users; with XMPP, you reach nobody.

I'm not into p1's business but I would assume the typical customer isn't doing s2s at all.

Most business uses of XMPP are not interested in federation

Holger: there was only a single customer with s2s: Nokia 😁

so, if you wanted to replicate the success of WhatsApp, why would not not start with XMPP, as they did?

MattJ: Right. So the alternative is XMPP vs. random other chat solutions and the open aspect is irrelevant except in that it leads to library/infrastructure code being available.

I don't think anyone expects to take any off-the-shelf tech and scale it as far as WhatsApp have done without customisation

MattJ: many do: every our customer wants to become WhatsApp 😁

Let's rename XMPP to WhatsApp2 protocol

Well WhatsApp's success wasn't due to federation, or its protocol - these things are irrelevant to users

MattJ: then there is no point in using xmpp? Because it's irrelevant

There's similarly no point in *not* using it

HTTP!

JSON!

what Holger says

Which is the point I'm trying to make - if you're solving a problem for your customers, why do they care about the protocol?

MattJ, because HTTP passes through all firewalls, XMPP won’t.

and like many other problems, XMPP already solved that

did it?

(in many ways, as usual)

BOSH?

by bother with BOSH+XMPP when you could use HTTP+json on your own?

BOSH works perfectly through firewalls

(in addition to BOSH being ugly and you’d want to use websockets nowadays)

Well, we can do that too

There's JavaScript frameworks everywhere to throw JSON at a web service.

I still don't think BOSH is ugly compared to websockets though :)

A new framework every other day!

Is that true? That you'd automatically want WSS instead of BOSH?

And all your devs have done this stuff several times.

Kev, tbh, I don’t know a lot about web

None of them ever touched that XMP-what?! thing.

but the concept of BOSH always irritated me

Holger, and all the darn myths about XML aren’t helping

Right.

(even though it is amusing to see how the JSON folks reinvent the XML data model)

Absolutely.

MattJ: bosh is much more complicated for sure and infact replicates SM behaviour

295 is funny because it's true :p

Kev, oh yes

zinid, sure - I've written multiple BOSH implementations, client and server-side

MattJ: I'm not saying the typical business decision against XMPP is purely rational. Though I'm not sure it's purely irrational. But either way it doesn't help to just ignore those business reasonings.

MattJ: same here and I hate it

I actually don't understand why wss+sm is not enough

zinid, because ws is rather new-ish and people haven’t gotten around to implement it yet?

(spare time developers)

I think jcbrand mentioned that Converse.js supports both but he prefers BOSH. He didn't really explain the reasons though, IIRC.

jonasw: newish? The RFC was accepted in October 2014, it will be 4 years soon

zinid, yes.

that’s newish in spare time developer terms

Ok

or maybe it’s just me because I don’t follow web technologies a lot

But can we start recommending it instead of bosh?

Clearly we have several specs with the same functionality again

The working group that created websockets looked at BOSH and considered it, or something very like it, to be the foundation of websockets

And "IE9 doesn't support WS" is not terribly convincing 😁

I think ultimately BOSH is something you can already do in JS yourself, a binary-safe guaranteed persistent connection is not

I didn't get that, but whatever

Seems XEP section anchors such as this one aren't stable? -> https://xmpp.org/extensions/xep-0313.html#sect-idm139605353378912

I've always assumed they are not

I don't know where they come from though

Sigh.

Holger, normally, the anchor is set in the code

I referenced that section (in an ejabberd issue) yesterday and it seems the anchor has changed since then.

it’s not been set there :(

we can now either set the current id as persistent, the old id as persistent or an arbitrary new identifier.

pick one

Sometimes there's human-readable identifiers, right? They're much nicer of course.

+1 for human-readable identifiers :>

Holger, yeah. as mentioned, those are set in the XEP XML

when they’re not set, they’re generated "randomly" apparently

so I can now either set a human-readable one or one of the random IDs

Humans in XMPP detected

jonasw: set a human readable one

Then make a linter script to check all XEPs. Then crowdsource slugification

I wish I had time to finish xeplint

Holger, fix pushed, will be live in ~1.5h

new anchor is #business-storeret-user-archives

jonasw: Thank you!

Should a MUC-PM notification follow the rules for message notifications, for MUC notifications or have a dedicated notification preference?

...regarding the notification sound

I would use the same as 1to1 chat

I'd say from a user perspective they are the same, both messages I want to see

unless I silenced notifications for that muc/user

moparisthebest: "they" = what?

"they" = muc-pm / regular message

so different from MUCs.

yea mucs too

moparisthebest: please re-read my question.

Ge0rG, I would follow the rules for message notifications.

^

SouL: thanks, I got your answer.

I also think MUC-PM and regular contacts should produce the same notification

MUCs are different if only they also have a "only notify on mention" setting

Ah, it seems like MUC-PMs are already handled in the same way.

So you don't see a need for their own category? Great.

special notifications could be set to special contacts ❤️ =)

I'm planning to have a per-contact-group ringtone, but what do you do if a contact is in multiple groups?

alphabetically first group wins?

play all at once :-D

rion: you are evil :P

jonasw, what is (or was) c.im?

usually people abbreviate conversations.im that way

moparisthebest, ah ok then

c.im is the new jcd.

what is the old jcd?

jabber.ccc.de

ah :)

c.im is available for sale!

I bet it's cheap.

For $$$$, I guess

I was able the get back mov.im last year <3

Sorry, c.im has already been registered.

edhelas: congrats! :)

The one I want is only $2600

so.ul?

I was eyeing moparisthe.best but not worth it nowadays

I have two domains with my lastname on dubious TLDs.

People are always surprised when I tell them on the phone

.xxx?

Not even close

Gr.org

Ge0rG, I have the same, tell people on the phone my first name @ my last name dot org

Ge.org

then they go 'at gmail?' and I go 'no'

moparisthebest, :<

I know that feel

but I think it’s because many people are stupid and confuse . with @ when spelling their mail address

moparisthebest: and .org is pretty well-known

I actually get odder looks/questions now that I switched to mostly giving like, if the company is BobWorks I'd give first.bobworks@last.org

moparisthebest: that's crazy talk!

I like it because while a human could figure it out and strip off the part after the .

first.bobworks@last! yay!

a computer program totally couldn't because it's a perfectly valid email, and they don't know that's my policy like they know + is strippable from gmail

reminds me of the "io" tld which had A records for a while

moparisthebest: do you think they actively strip +postfix from gmail addresses?

I assume spammers do, why wouldn't they?

moparisthebest: dunno

or sleazy companies that would sell an email address

moparisthebest: maybe because they are careless sleazy bastards?

if only I could get a saner way to handle such aliases in xmpp

but it looks like far too much work to be worth it

Yeah, XMPP sucks.

go matrix?

OTOH, this feature prevents domain / user impersonation.

this module is 'good enough' in that it fixes discovery https://modules.prosody.im/mod_alias.html

but doesn't avoid the 'giving randoms your jid' problem

XMPP alias please!

When are we starting with the XEP?

I'm sure there are two or three already.

it's perfectly doable with just changes on *your* server

it's just super annoying, like if a@a.com sends a message to both b.alias1@b.com and b.alias2@b.com, and b responds, which jid do you send it from

and it involves a lot of jid rewriting, databases and such

b.alias1+alias2@b.com

I guess maybe if you added client support too that would make it easier, but meh

moparisthebest: I would assume that you use proxy JIDs for different aliases on your side, so it would be something like a%a.com@b.alias1.b.com

the advantage of support just on *your* server is you don't need a XEP because there is no interop to document :)

Ge0rG, in my case I'd want it to match all my email aliases, which are a defined list of specific ones, plus me(\.|+|-)[^@]*@all-the-domains

moparisthebest: your server could just track the alias the other user contacted first.

moparisthebest: and auto-route accordingly

yep that's an option, probably the best one, still not perfect

probably good enough.

reminds me of resource locking

sounds like a can of worms

it's totally a can of worms

🐛

hence "This type of aliasing is well supported in the email world, but very hard to handle with XMPP, this module sidesteps all the hard problems by just sending the user a helpful message, requiring humans to decide what they actually want to do."

oh, it's basically a standardized auto-reply

or jid squatting ;)

Wow.

Impressive.

We need more JID mobility.

Do we, really?

Zash: I'd like to have an easy and fully automated way to move all my contacts from my old JID to my new JID

I just have a number of emails, 2 main ones, and I like all my emails also being JIDs, isn't that the ideal situation?

kind of moved, but automatic

Ge0rG: How often do you move JIDs?

Zash: whenever the 6-month free period on c.im expires

lol

This ties back into the question of what identity is.

Ge0rG: haha

Ge0rG: Why can't we automate moved again?

Zash: because SECURITY11!!1!! > In order to prevent other users from maliciously altering contacts the client SHOULD NOT automatically subscribe to a <moved/> JID when it receives an unsubscribe and SHOULD NOT automatically unsubscribe to a <moved/> JID when it receives a subscribe.

Then followed by some constructed attack vector where some JIDs are auto-approved and others are not.

xep#?

https://xmpp.org/extensions/xep-0283.html#security

-xep moved

Zash: Moved (Standards Track, Deferred, 2010-06-16) See: https://xmpp.org/extensions/xep-0283.html

Ge0rG, if we add a crypto identity we can base moving on that. (Sounds crazy but I am not kidding.)

Ge0rG, that seems solvable, trivially

SaltyBones: I've thought about that.

SaltyBones: that would make the public key your effective identity, and the JID just a helper string.

Which isn't really the design of XMPP

Considering how much we are thinking about those things I think we should start writing things down...

oldjid unsubscribes with <moved token='xyz' new='…'/>, newjid subscribes with <moved token='xyz' old='…'/> and only then a potential reverse-subscription is re-enacted by the target

jonasw: feel free to pick up authorship of 283, bringing it up to pace and convincing clients to implement.

Ge0rG, would that work? ^

clients or servers.

would have to figure something out for one-way (stable jid to moving jid) subscriptions

jonasw: no need for a token. you can prove ownership of both JIDs by just issuing the according <moved> stanzas.

right

that’s what happens already though

jonasw: I've written down all that, before I knew of Moved, into the wiki

but then it got lost

SaltyBones: yes, let's reinvent XMPP as something else.

so yeah, it’s really only about some weird one-way casse

maybe an "OMEMO distribution protocol".

I don’t think we should care about that too much

jonasw: the hard part is figuring out the right order of events to make it work automatically. That and server-side caching of subscribe/unsubscribe presence packets.

Don't remember the exact rules

BTW, when is PARS bound to expire?

defer, you mean?

xep#?

!xep 379

Ge0rG, is this about the crypto IDs?

Ge0rG, february 16th

SaltyBones: I'm not sure.

jonasw: wow, need to add some more meat to it until then.

I need to get some ecaps2 implmenetation in some server

Seems https://xmpp.org/extensions/attic/ has the current XEP-0363 revision (0.4.0) but not the two 0.3.x revisions.

Holger, this is not the only such XEP, I recall I couldn't find old versions of MAM or something

:-/

Holger, yes

attic is a manual process

it sucks

editors have to remember to copy them over

I don’t remember that always

:/

Nice.

is there a reason to have it with version control?

can't a xep just be looked at at any revision?

I already automated the copying-over of the changed versions, and if we ever get this scripting server-side, it should magically worked

moparisthebest, yes, but you’d have to know which revision is a specific version

if we knew that, we could generate the attic auotomatically

tags?

we don’t have those

(since they can be added later)

moparisthebest, if you did those, that’d be amazing

something like xep-0368-0.0.1 or something

yeah

but it’s tedious to do

for each revision, check the last version in the source, something something

would be kind of hard to back fill, could be easy going forward

tags sound like a sane idea

should be doable with way more scripting hackery than I have the energy for now

Zash, not sufficient; sometimes version blocks are added before the last editorial change

jonasw: would it be good enough?

oh hey, what about just checking out each version and matching sha1sum to a current attic xml for backfil?

Zash, probably

moparisthebest, except that attic doesn’t always have XMLs

that would get you exactly what is in attic now, then you could tweak later

gotta go

oh, well does it *mostly* have them?

moparisthebest: maybe, assuming they haven't been changed in any way (think character encoding or newlines) since

I would assume they were copied from version control and not touched

could be a wrong assumption

but the HTML is not under version control

those are build artefacts, copied after build

yea I think it'd only work if there was xml there

might depend on the version of xsltproc and whatnot

looks like we need editors to ping stpeter about pinging Joe Salowey again about adding xep-368 alpn IDs here https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids

since last time when he said he'd add them, looks like 'CoAP' whatever that is has been added

but still no xmpp love :'(

Why don't you do it?

it's officially an editor task

join the editor team, send an email, retire to a life of luxury

well editor team tried to ping joe salowey twice without luck, and stpeter had to take over :)

I'll probably wait until stpeter joins back and ping him again hehe

https://trello.com/c/8arSL8aD/2-vote-on-moving-xep-0368-to-draft that's the card looks like