XSF Discussion - 2019-12-29

What if you want to have a group with channels from different components?

Would not a list of channels be easier to handle? You can also do MIX like this it's not specific to MUC

(Not that I have any interest in having MIX implemented for the time being)

pep.: disco can return JIDs from other components :)

MattJ: you'd be breaking a SHOULD? (Behind a feature I guess..). "The service SHOULD return a full list of the public rooms it hosts"

I came across this but I was mostly looking at possible restrictions on the type of jid you can put in there

It doesn't say it may only return rooms...

It doesn't insist on it..

I wonder how many people would interpret it this loosely though

Most of them

Who cares?

MattJ: dunno, some optimisation "because the xep says so"

Disco has been used this way for a long long time, not necessarily on MUC components (that I'm aware of)

But I don't see a difference

Reminds me of https://wiki.xmpp.org/web/Client_Test_Cases

The attribute is 'jid' not 'nodepart'

In the olden days many servers would return conference.jabber.org in their disco items, or transports from another server, etc.

Clients did not and should not expect that those services are always subdomains of the domain they disco, and the same applies here

pep.: there is actual benefit in using jonas’' muc search API instead of the blunt disco#items, as it provides rich info without having to query each room individually

And that doesn't come with the expectation of all rooms being on the same domain

Ge0rG: context?

pep.: exposing a "community" room list

I don't especially think this should be restricted to being a "room" list

Well, you could stuff anything into it, but what would be useful, and not too far away from normal xmpp clients?

By "normal" you mean chat?

I mean the widely deployed ones, which is roughly the same

All clients support PEP right. Microblog is not too far away :p

Also I wouldn't be so sure our public space and enterprise have the same "norms"

pep.: now just make it mandatory for CS'21 Core IM and we are set ✏

Maybe someday people will stop assuming XMPP = IM

Speaking of which, is it too early to fork off CS'21 yet?

no

it’s never too early

It's not even 2020

oh, right

no wait

it’s never too early :)

Heh!

XEP-0412 is still in Draft though

that’s where compliance suites go to die

And it doesn't even link its predecessor. Who wrote this shit?

the same person who wrote the star wars prequels, I think. so some people would argue that makes sense.

Well then

(I am sorry)

jonas’: are you really? 😋

slightly

Hello here, I'm checking https://xmpp.org/extensions/xep-0045.html#continue to convert one2one chat to MUC, and I'm suspicious about sending the history from the one2one chat (cf. Example 63). Is there any client doing that? The text says that the <delay> element has the "from" of original message sender, but the example use the same "from" for the 2 messages (and using this, we could fake message from anybody).

Is this the actual recommanded way to convert one2one chat to a MUC?

recommended*

goffi: I haven't seen it used anywhere, also there is the obvious trust problem

goffi: one could principally send <forwarded> messages into the MUC, but there is also the privacy problem

Ge0rG: indeed. Doesn't look good to me. I think I'll skip this history sending in my implementation, at least for now.

goffi: yeah

also we would need to know how much of history to send, it's not trivial to do it right.

I've brought up those points in the context of MIX, and IIRC it lead to the removal of history upload

Is there a media type registered for XMPP stanzas?

https://xmpp.org/extensions/xep-0081.xml :/

Oh, application/xmpp+xml defined in https://tools.ietf.org/html/rfc3923#section-10

Huh, weird <xmpp> container

In case you missed Moxie Marlinspikes latest talk about why decentralized systems are inferior to centralized systems, I formulated a reply: https://news.ycombinator.com/item?id=21908712

(I hope this is not too OT for this channel)

Nice

vanitasvitae: "While this is and issue" s/and/an/ ?

fixed 🙂

vanitasvitae: great! minor typo: "called compliance suits" --> "suites"

Ge0rG, fixed as well

👍

i dont know why this is even a discussion, there are pro and cons two both ways (decentralized/centralized) and they will not go away, talking about why a particular con or pro doesnt matter to you iin some specific project is irrelevant in my opinion

there will always be people for which the pros/cons will matter

thats why there are 2 ways of doing things

sure. I just thought it was worth a reply nontheless.

*two/to

vanitasvitae, the "you" was not directed at you

i was speaking about moxie

i dont see the value in giving a talk how the centralized approach worked for signal

no shit it works, like it works for a million other projects

and it has the same cons and pros like all other projects

😀

i didnt listen to the talk, so if he brought something new groundbreaking to the discussion, ignore me

lovetox: the problem is that Signal is trying to appeal to a privacy-conscious audience that has historically always been anti-centralization, so he needs to justify why Signal is not decentralized

ah k, he should just go with, "its much easier, and we try to minimize the cons as much as possible, if you dont like it build something better decentralized"

also why would he need to appeal to certain people

what is the signal business model?

Get money from tech funds

ok but why would they invest money?

or do they invest money into openwhispersystems

for doing other stuff

and openwhispersystem just crossfinances signal on the side with it

because if their goal is total privacy, i dont see a way how signal can ever make money

I mean, much of their money probably also comes from licensing libsignal to WhatsApp, Skype etc.

its subscription or ad revenue on the internet, and with so many chat applications out there i dont think a subscription service will be profitable ✏

vanitasvitae: Well stated text. Will put ot to the newsletter I would like to say: "we do these things… …not because they are easy, but because they are RIGHT…"