XSF Discussion - 2018-11-30

edhelas: wasn't it Dutch police that literally just did that

btw I think it was a good thing to split up the MIX specs

makes reading and understanding the important parts easier

👍

daniel: I think that repeater JID (I forget what we call it) in MIX can actually fully repeat PEP if it chooses to, can't it?

Ah, except the MIX room isn't 'both' in the user's roster, so won't be triggering +notify. Hrm.

Maybe they should be 'both', then?

there is a repeater jid?

the presence subscription will go to the channel jid

and then the channel could do something with it

however i think it might be better if my own account deals with the subscriptions. because my account (by looking at the participant node) knows what people i already have in my roster and with what other people i might be in two different rooms with

I don't remember where the JIDs are specced since the split, hang on.

Proxy JID

Where the rooms are JID visible and you have each other in your rosters, this is all straightforward.

what about room jids visible and not in each others roster

What about restricting which PEP nodes you want to make accessible to other MIX participants?

isn’t the access model we already have for pep enough?

also i'd be happy if we can get that subscription managment mess sorted out before i think about acl

PEP+ has everything you could ever want

At your service

Are there problems that are not solved by forwarding all PEP request sent to the proxy JID to the real JID?

Prosody 0.11 does that trough MUC now 😉

reads like a fantanstic sprint you had, congrats everyone :)

Ge0rG, my problem is not about 'reaching the jid' but about managing subscriptions to it

Lots of ways to improve as always but it was great yeah. Thanks jc for organizing it

Here you go, we always need a percentage of people slacking off.

So I'm the bad guy, as always.

Thanks for volunteering

It's my favorite task assignment. Can I have it in writing please, in case anybody complains about me being rude again.

We have a xep that allows muc clients to join a mix channel. Wouldn't it be cool if the mix account thing could also join us in a muc? So from a client perspective we only ever speak mix?

This could then be merged with the account joins muc concept that some people have been thinking about

An upgrade path with smaller steps might be easier to get done, yeah

In theory the account-based-muc thing could transparently translate to MIX

Probably with some painful tradeoffs, but smaller steps are easier to take 🙂

daniel are you working on implementing mix?

I'm working on *reading* mix

It's only been a couple of hours

i would be interested to develop against some server that has maybe even some basics of mix implemented

i remember ejabberd once had a module or not?

Has the rate of change slowed down enough that MIX won't change under your feet while you're implementing?

Probably

with the rate of xeps that make it to draft these days, i guess this is as far as it will ever get

> Wouldn't it be cool if the mix account thing could also join us in a muc? Awesome idea!

I have a question regarding https://xmpp.org/extensions/xep-0085.html#bizrules-gen

this says that you should not send chatstate if the other client doesn't supports it in his capabilities

what about sending messages to the bare jid ?

You can’t know. Before, we implemented resource locking, but it’s been considered deprecated for a while so we switched to ignoring this text in 0085.

so basically I can simply close https://github.com/movim/movim/issues/158 as a wontfix :p

edhelas: yes. Burn resource locking with fire

yeah i mean at least in mucs it breaks apart anyway

edhelas: because Carbons will be emitted to other clients which well might support it (or vice versa)

happy to close a 2 years bug with a wontfix \o/

dwd, you around? a one-on-one with you gives me errors

nor are you in open_chat, where our weekly festivities are about to commence 🙂

New ticket about jabber.org dh key too small: https://github.com/stpeter/jabberdotorg/issues/6

Stop the presses! Inform the government! 😁

Ge0rG: the main XMPP server of the World must to be an example ;)

Neustradamus: Conversations.im ? :P

Neustradamus, hmm doesn't say how long it was though...

It's using 1024 bit DH parameters

Recent OpenSSL is rejecting that

nice

ECDHE should work fine, if you trust that kind of dark elliptic magic.

Reminds me of my gradle refusing to download dependencies when running under Java 7

Guus: https://mail.jabber.org/pipermail/operators/2018-November/thread.html -> A guy speak about my tickets of XMPP.net Have you looked the problem since this moment?

Neustradamus: yes, part of the problem was solved, the others are being looked at by iteam.

(what my alterego said)

Guus: guusdk Nice, do not hesitated to update all the tickets...

xmpp.net has last xmppoke version?