XSF Discussion - 2019-03-03

I also wanna make a high-level-ish language on top of sed to re-implement the echo bot in that

and then maybe a libc implementation with a shim wrapper around sed to invoke syscalls

Whatever floats your boat.

Hi, for people who have read/written MIX, what is the story with user PEP?

If I join a MIX channel and want to obtain e.g. the User Tune of all members, will the MIX service subscribe to everything I have a +notify for, or does it rely on the participants explicitly publishing their User Tune to each MIX channel they’re in?

My basic model is that the primary goal of MIX sharing of participant info is to share who are the participants. With JID hidden, this is typically going to be minimal information. With JIDs shared, I see that sharing further info can go directly, and should not be involving the MIX channel.

So in my case, a participant interested in the User Tune of each other participant should subscribe manually to all of them?

Or retrieve it as the user scrolls in the list, or something like that, depending on the UI of the client.

I've been assuming that the server can straightforwardly proxy PEP, but I might be being naive.

Well, semi-straightforwardly.

Would PAM imply that the MIX channel is auto-subscribed to all PEP items?

Or something like that.

That was my assumption.

Great, thanks.

PEP nodes*

Details TBC.

Link Mauve: are you implementing mix?

zinid, I’m actually thinking about PEP proxying for MUC.

Link Mauve: ah

Somehow.

Details TBC too, I’m just playing with a poc.

whatever, I decided to stop fiddling with muc in ejabberd and focus on mix

fiddling with both is too taxing

It was prompted by https://github.com/xsf/xeps/pull/760 and the idea to finally deprecate 0153.

I know the idea

I’m trying to see if it’s viable before I push this PR to standards@.

Link Mauve: well, the council decided to start the discussion 😁

before voting

Yes.

I am honestly not sure why you are worried about it so much 🤔 ✏

I really don't like the situation when we cannot decide where to move, we will end up with incompatible implementations

Yeah, I guess I could just send my proposal instead.

either we continue muc necromancy or focus on mix.

I’m fine with both so far.

With a slight preference towards fixing what we have.

well, I am not 😀

Neither clients nor servers will be able to go MIX-only for quite a while, even if all implementations got MIX support today.

So, fixing MUC will be useful during the transition period anyway.

> Neither clients nor servers will be able to go MIX-only for quite a while, even if all implementations got MIX support today. True. My approach in ejabberd is to implement very tiny muc subset above the mix code. Like joining/leaving and message sending.

Only that? :/

And then tell users MUC is bad because you implement only 3% ? :P

Link Mauve: I didn't decide what exactly to implement.

yet

I just want to make sure the chat is usable in at least popular clients.

configuration/moderation won't be supported for sure

zinid, is your current MUC code not reusable at all?

Link Mauve: no, it's total garbage

zinid, sounds pretty bad. :x

and strictly speaking it's not my code 😋

zinid, “your” as in Ejabberd’s. :p

I only patched that trash

Link Mauve: I mean technically I didn't write it

Prosody recently got a rewrite of its MUC code, it now is very easy to extend and could maybe become the basis of some kind of MIX.

But I have yet to read a recent version. :x

Link Mauve: yes, but I don't want to rewrite it. this was the basic dilemma for me: either rewrite it or go mix.

Ok.

That’s sensible.