XSF Discussion - 2018-01-03

does anyone have any idea why a fetch from github xsf/xeps is failing?

I want to get the latest, so I can start on Dave's comments

care to give more details?

error messages etc ✏

Git GU says it is fetching, works for ages, and then complains connection timed out

Has been fine before

fatal: unable to access 'https://github.com/xsf/xeps/': Failed to connect to github.com port 443: Timed out

hmm works for me

can you open that https url manually in your browser?

fine in my browser

pushes of commits to Guithub was working fine yesterday

I did the fetch from a different network two days ago, so I guess it could be our proxy

Proxies seem like a sensible thing to blame

yup - proxy

I'm thinking of extending 0277, having 2 nodes, one for public publication, one restricted to presences

edhelas: we have since talked in private, but for the record I have tried the 2 nodes options years ago, and it doesn't work that well. The fine permission tuning (aka items permissions) is the best option from my experience. I still need to propose a protoXEP, but lacking time to write one.

I'd like to know if we can deprecate 0084 and go back to the good old "presence notification" for vcards

we have 2 solutions and I though after 5 years that everyone will move to a full PEP solution

that didn't worked

also it doesn't work for MUC vcards

also barelly no client is implementing it https://nl.movim.eu/?about#caps_widget_tab

edhelas, did you see inputmice's talk about it?

I was at the 34c3

which talk ?

might have been that one, doesn't that fix the problem server-side ?

I didn't been to his talk then

what was it about

I'm trying to find a link but not having any luck yet

https://github.com/iNPUTmice/talks/blob/master/2017_12_27_-_jabber_xmpp_the_past_the_presence_and_the_future.md

yep that's it specifically https://github.com/iNPUTmice/talks/blob/master/2017_12_27_-_jabber_xmpp_the_past_the_presence_and_the_future.md#avatars

it's not perfect, but you see what happens when we try to create perfect, we get MIX, and it never goes anywhere

yup

can I officially propose the future cut-down-to-useable-proportions MIX replacement be called MUX ?

I just read about MUC-SUB https://docs.ejabberd.im/developer/xmpp-clients-bots/proposed-extensions/muc-sub/

it's quite great, also retro-compatible

ah will read, I was only aware of https://xmpp.org/extensions/inbox/muc-light.html

but retro-compatible sounds great

We could probably make a MUC-actor thing where your account joins MUCs on your behalf.

Maybe even without changing the protocol.

and requiring all user's servers to be updated would be a good test for how feasible mix is :)

There are voices saying that the big servers will update fast.

is there any server MIX implementation based on current specs ? I know about the one from Ejabberd but it was on first draft and I don't think it has been maintained.

same

Muc/Pub is used by several clients in production as well

which ones?

moparisthebest: Commercial ones.

goffi, We have a MIX implementation, but it's not quite the current spec.

dwd: is it public, can we test it ?

goffi, It is public-ish - in surevine's github in our Openfire fork. You'll need a real database, though - the embedded one doesn't work.

goffi, Also, no presence, since we didn't need that.

dwd: ok cool. Would be nice to have a simple wiki page with links to current implementations, so the day I want to start client implementation I can select a server one.

you need 2 server implementations though

uh, in that your server needs support, as well as a mix component

so when looking for server support you need those 2 different things right?

It means MIX is going to take years (that's years + whatever time it takes to get implementations released)

Because MIX is not usable by the ordinary user if they can't just invite anyone on their contact list, and most people are going to be running from OS packages

years or never, like privacy lists, original archiving etc

Privacy lists was pretty widely implemented, back in the day, actually :)

Just with a terrible UI

Damn, where's my "told you so" stamp?

especially if you have something simple that solves 99% of use cases and is backwards compatible, like maybe this muc-sub thing, haven't read it yet

Ge0rG you didn't had enough ink to stamp last time, need to buy more

muc-sub seems to be a good 50%-50% between the two XEPs

moparisthebest: which "future cut-down-to-useable-proportions MIX replacement"?

-____-

Flow, all I know is it should be called MUX

I'm just assuming there will be one in the great tradition of the XSF

Flow: is it possible that smack will never cache entity caps for JIDs it didn't previously receive presence from? https://github.com/igniterealtime/Smack/blob/master/smack-extensions/src/main/java/org/jivesoftware/smackx/disco/ServiceDiscoveryManager.java#L510

moparisthebest, i'm not sure about it, but I would really like a little competition

Ge0rG, possible, I think Smack should maybe calcucate the version itself

Flow: yeah. Just noticed that in smack3, I only have persistent cache items from my own caps

I can tell from the variable naming that this is veery old code ;)

it's actually the same in smack3:P

looks like a good incentive to start on caps2

on a second look, that code locks correct, and is covered by integration tests

reading daniel's talk re avatars. Does 0153 really requires you to download your own avatar on every connection? If you have it locally you can just hash it and compare to what the server is sending you, right?

pep.: how do you know it hasn't been changed by another client?

You hash the one you have locally and compare it, if it's not the same your redownload it

I mean there's not need to download it _everytime_

right?

don't you have to download it to calculate the hash?

You have a copy locally right?

What's different from PEP here?

how does that tell you what's on the server?

"A client MUST NOT advertise an avatar image without first downloading the current vCard", that's meh

Indeed.

Isn't there a way that the server sends back a hack of the current avatar instead?

what do you mean with is there a way

like with a current xep?

no, but it would probably be trivial to add to 0153 that the server sends the hash on request

Well, not 0084, as it doesn't work in groupchats

..

yeah

but downloading a vcard is really nothing i would sweat about

I don't know, daniel put it in "downsides" in his talk

i guess on mobile it is sometimes a downside

and its not particular pretty

yeah but it's not like it couldn't be fixed

but nothing that would stop me implementing it

pep., more trivial than not changing the xep and having a server plugin just do it all for you? :P

either way you are writing code and deploying it to a server

I like daniel 's approach better

moparisthebest, sure, things take time. But 153 has been out for a while now

but 153 is historical

i dont think these are meant to be changed

Hmm.

How do you change that? You fork it?

what problem are you trying to solve

and do a pr, but i guess this will not make it :)

why would you try to solve it with a xep change, client change, and server change

when you could solve it with just a server change, and end up with a simpler client using less bandwidth?

lovetox, yeah, honestly I don't really care

I have enough GB on my plan so that it doesn't matter at all

it's not really that, it's the added time a connection takes in my opinion

I just find sad that we have to go through convoluted ways (PEP -> vcard) to fix this kind of things

the other way sounds far more convoluted

How so? Making people update their software? ✏

> I just find sad that we have to go through convoluted ways (PEP -> vcard) to fix this kind of things I find that extremely simple and straightforward

And it's already supported by the important servers

pep., again "xep change, client change, and server change, and clients use more bandwidth" vs "server change (major servers already support it)"

which sounds easier and more preferable?

So that means if I want to implement a server, I'll have to support both 0153 _and_ 0084 (and PEP) for avatars? Plus also the PEP -> vcard thing

How isn't this convoluted

(No I'm not planning to implement a server, still I hope you get my point)

ok, well you have to support both 0153 _and_ 0084 anyway

I guess you might complain about converting, but a sane structure would have you storing them in the same place anyway?

I'm complaining about the workarounds mostly. I'm not sure how fixing a historical XEP works, but adding a "Server returns vcard hash" wouldn't be difficult

heh, the compliance suite doesn't state 153 at all?

also your argument seems to be make it slightly easier to write a new server by making all existing servers add features to existing historical plugins

still not buying it

when in doubt go with the simplest thing that works

KISS

moparisthebest, not "historical plugins" no, just "mostly used solutions", just like edhelas showed above, 0084 isn't really implemented anywhere

Also 0084 doesn't work anyway, re groupchats

I'd rather you not write a new server in the first place

daniel, sure

s/mostly/most/

I'm just waiting for Link Mauve to write a server in rust so I can switch

I don't think xmpp-rs is going to be designed for servers

I don't care what library he uses :)

heh. I don't think he's mad enough to do that anyway

You never know!

I know you're mad, don't worry

on a side note, why are the majority of major xmpp servers written in crazy esoteric languages :)

:p

does that say something about the people who use xmpp :'(

Link Mauve, any idea what's become of Freyskeyd and his talk of writing a server?

https://github.com/Freyskeyd/xmpp-rs/tree/master/server

fn it_works() {} :)

pep., he seems to have stopped working on his library altogether.

"It's goal is to be fully tested and usable."

he is halfway there (it's fully tested)

it even says it works!

is anyone aware of any xmpp test domains for client and/or server devs to test proper srv fallback etc ?

similar to like http://www.dnssec-failed.org/ for testing dnssec

many, possibly most, clients and such don't end up falling back correctly or at all turns out

like they fallback if the port isn't listening, but not if it sends invalid xml, or doesn't support ciphers it likes, or various other errors

moparisthebest: You're suggesting Rust for an internet service and complaining about esoteric language choices?

no I think rust would neatly fall in there right now

(the esoteric lang category)

pep.: I think it's right to have the complexity on the server side.

moparisthebest, you can use OpenFire or Tigase, for a very non-esoteric language.

There is also Jabberd and Jabberd2.

People have been writing one in PHP and one in JS too IIRC.

I would know, I’ve written one in JS.

(Never again. ;_;)

I'd guess ejabberd/prosody/openfire is most of the public network though, and if so, that's 66% esoteric langs :P

and my guess is openfire is distant 3rd there

Holger, what annoys me the most is that, from what I understand, we're just choosing the path of least resistance for the features we want out there. Yes we are mostly volonteers, and I get we don't have all the time we want. Plus users are running old software (debian I'm looking at you), etc., Still I don't think we should stop here

"That only has to be implemented server-side, let's prefer that over X", I'm not really into this kind of thought

pep., good luck getting anything actually put into use then :) (looking at you MIX yet again)

daniel, do you have stats btw of what version of Conversations people are using?

Or maybe services like jabberfr do? (Link Mauve, mathieui)

pep.: no

pep., I don’t think there’s a prosody module for that yet

pep.: The amount of madness a client developer new to XMPP is confronted with is insane. Avatar support is a very basic IM feature. We should be able to show him a simple XEP he needs to implement to make avatars 'just work'. If server-side hacks help with hiding the compatibility madness from him, I'd prefer those hacks.

For this particular case I'm not sure what's best, implement PEP _and_ 0084 _and_ 0153, or fix 0153 to have the small fix we talked about earlier, and implement only that

As a client developer, maybe I'm biased :P

so implement only the historical one?

seems questionable

moparisthebest, if you come up with a non-historical just for the sake of it, that has the same features, and make people use it, why not

I'm also under the impression the pep one is easier for clients

Well but by now both are implemented.

That's why people are trying to shoehorn everything into PEP?

it's done, accept the fact and move on 😛

I don't know why they are. I would've been opposed to that if I had been around back then.

moparisthebest, I would if it worked

I'm just saying we have both now, and we either deal with that or we break interop.

omemo requires it too

probably other things I don't really know about?

Neither 84 nor 153 are particularly difficult to implement.

On the client side that is

daniel, it's just an example

For what?

For what I said to Holger above, we're just choosing the path of least resistance, "because this way we'll have it implemented and usable no matter how ugly/workaroundy that is"

That's just a feeling, I would be happy to be proven wrong

I have quite the opposite impression. The Xsf is the textbook example of perfect is the enemy of good. That's why we have so many widely deployed XEPs stuck in experimental.

if you want to fully reinvent the wheel pull a matrix :)

That's why we have been working on mix for three years now

moparisthebest, that's not my point.

daniel, true

I agree daniel my impression is we create a complex monster of a xep where all possible usecases have to be fulfilled rather than a much simpler solution that fills 90% of usecases

so.. MIX and avatars are two extremes? :p

pep., moparisthebest: fwiw I'm not trying to be overly negative towards mix here. But choosing the complex solution over the much simpler one that fills 90% of the use cases is a pattern I see in a lot of XEPs

daniel, gotcha. I guess I wasn't around long enough

Anybody implementing 0306?

-xep 306

pep.: Extensible Status Conditions for Multi-User Chat (Standards Track, Deferred, 2016-06-07) See: https://xmpp.org/extensions/xep-0306.html

pep., none that I know of