XSF Discussion - 2019-09-17

was there some protocol which allows a MUC to announce a URL where a web chat to join it can be found?

or did we just agree that there should be such a thing but nobody did it yet?

jonas’: the latter

also: 'now, you touched it last.'

*sigh*

Zash, you do a prosody thing for xmpp.org, I do a muclumbus thing and an update for '45, deal?

I suggest `roominfo#web_join_url`

if you update 0045 anyway you could also fix example 10

it cointains muc#roominfo_changesubject which is non existent

I bike-shed `roominfo#webchat_url`

Ge0rG, wfm

Is it implied that this would be some anonymous webchat setup?

Zash, yes

I think?

is there a use in a non-public webchat? ✏

Ge0rG, as an alternative to firing up your client if you know your credentials... but I think that’s not useful to have on each and every MUC of a service

jonas’: so it's a server config then?

probably?

what if I want to have a nicer webchat on my MUC?

which is custom-hosted

I don’t care ;)

I think that’s a different use-case anyways

I remember that was mentioned in a sprint (Düsseldorf), and then we faced member-only channels and we figured we needed something like 401 but for MUCs? And never did it

typically you need some kind of web space and xmpp / BOSH / CORS magic.

Step 1: Only do it for public (not members only) non-hidden MUCs

what Zash said

as a server admin, I'd like to have a default webchat proto-URL where you only need to fill in the MUC name

as a MUC owner, I'd like to see that / have an opt-in / override it

Ge0rG: a few services have that already, the former

Look at chat.jabbefr.org's JS for example

> chat.jabbefr.org’s server IP address could not be found.

There's a link from jabberfr.org somewhere probably ✏

(I can point to something more specific when I get a laptop)

https://chat.jabberfr.org/converse.js/some-jid-here ?

Ge0rG, s/jabbefr/jabberfr/

tres bien

Or we could go full generic and figure out how to link arbitrary URIs from MUC metadata

Zash: roominfo#metadata_json

xep-0157? ;)

heh

seriously though, how about we solve this thing at hand right away with the obvious solution?

+1

`hg cp mod_muc_lang.lua mod_muc_webchat_url.lua`

MattJ, excellent. my offer stands: you do this for prosody on xmpp.org, I do it for muclumbus and an update for '45.

jonas’: what is the obvious solution? A per-room manual setting? Defaulting to the server's webchat, with some kind of placeholder?

Zash, ==> mod_muc_generic_additional_options.lua

muc#room{config,info}_* eh?

https://www.xkcd.com/974/

Ge0rG, the obvious solution is that if a server is configured with a muc log and converse and anon login, it should be published in a form field. ✏

jonas’: on the MUC domain or on individual MUCs?

on both?

Ge0rG, on the individual MUCs

jonas’: what if some MUC owners don't want that?

Ge0rG, make it members-only?

make it password-protected?

apply the typical access control measures for your MUC

Agreed, if it's open then anyone can point a web chat to you and advertise it somewhere, whether you like it or not

so if you don't want that, it shouldn't be open (or make it hidden, and we'll default it to disabled for hidden MUCs)

MattJ, so I think the conditions should be: anon webchat configured && open && not password protected && public(?). ✏

+1

MattJ, `roominfo#webchat_url`?

In the case of Prosody, the anon webchat isn't attached to the MUC component, which complicates things. Implementation detail tho.

I'm okay with a server config

I think it's easy enough to add a config option to the MUC component to supply the web chat URL

Zash, in that case I suggest a config option on the MUC component which is something like 'webchat_url = "https://chat.example/join?room=%s"' ;)

I'm in fact typing this out right now

<3

you need to a way to pass the block of an anon user in a muc through to the anon domain and block the ip

otherwise you won’t be able to block users anymore

We already have that

cool

s/roominfo#/muc#roominfo_/

code for muclumbus is ready for testing :)

jonas’: %s would be the room jid or the node?

Zash, node?

what node?

localpart of room JID

ah

orrr "https://chat.example.com/join?room={node}"

I guess that makes more sense since if your webchat needs the bare JID, it’s easier to tack a @hostname behind the %s than to try to pry the @hostname off whatever %s substitutes

whatever works :)

Zash: what if I have multiple MUC domains?

(on the client side, I expect a perfectly working URL)

Ge0rG, since that’s a per-componetn/domain setting ... ;)

Right

I made {jid}, {node}, {host}

awesome

now for the most important question. which emoji/icon should I use in the muclumbus web interface?

🚪? ✏

With what motivation?

jonas’: 💬 or 🗪

the former then, the latter shows as box only

jonas’: your Unicode is too old.

(Mine is, too)

Ge0rG, let’s not get into that PRECISe discussion now

time is PRECIouSE

what kind of sauce?

jonas’: done and deployed everywhere I have access :)

yay

Zash, deployed on search.jabbercat.org \o/

Shiny!

jonas’, avatars?

Zash: there is an open issue about avatars (and how to manage/whitelist them)

Zash, first I’ll redesign the list view (which I’m on right now), then I’ll consider how to implement whitelisted avatars for good

https://sotecware.net/images/dont-puush-me/gIIcKn27Z91Q07XV3VUHrhuAL0mmuMqFQjolfOJsCc4.png

jonas’: Nice.

bummer about the whitelisted avatars, some real troll potential lost there :'(

jonas’, which one of the various non-standard muc avatar methods will you support?

The best one

The one implemented by everyone? The one implemented by Prosody and Gajim? The one not yet invented or implemented? 🙂

s/Prosody/a 3rd party Prosody plugin/

Zash, I query vcard right now

https://sotecware.net/images/dont-puush-me/LxeXdDdI4QY5NYUNVjL2JZVHlccAp73LsrACuwGsYNs.png

it happened

Pretty

someone should set the XMPP logo as avatar for this room

I like that you rescale the ~200 byte Prosody SVG logo to ~1400 bytes of PNG

is it an SVG?

if it was SVG, I would not parse it at all

Unless whatever I used to set it converted it to PNG at that time

... Gajim?

I only parse image/jpeg and image/png

Hm, PNG indeed

Wow, this looks nice :)

jonas the black banner looks a bit boring

otherwise great job

and how can i whitelist the gajim muc avatar?

How do you convert SVG to PNG even?

The GNU Image Manipulation Program doesn't have the slightest idea what aspect ratio xmpp-logo.svg has

Gtk can do that

and yes Gajim does that at the moment

C for example has no support for svg

`viewBox="-3277 648.6 176.5 134"` ???

Zash, inkscape -z --export-png=/path/to/out.png /path/to/in.png

Would it pick up a vcard for xsf@ if one had set one?

yes

muc.xmpp.org is in the whitelist

Entire domain?

yes

Wouldyoulookatthat

jonas’: so gajim.org is probably on the whitelist but it fails to provide its avatar the right way?

wurstsalat, refresh

wurstsalat, it just took a while to re-scan the MUC

ooh entire domain you say, can I create mucs here?

moparisthebest, no

You also can't set vcards.

off to bed now

jonas’: I do like the new layout!

jonas’: I'm currently getting internet server error from the api

Newbie question: "After SASL negotiation, the parties MUST restart the stream." why is that?

pep., iirc to be sure that any sensitive SASL data can be wiped from memory.

And so that you can offer new features.

new features? ah, after being authenticated

post-auth only stream features

yes. it would not make sense to offer you any stream features that require authentication prior to auth ("try this! ah sorry, you need to be authenticated") so the rule of thumb is to only offer what has a chance to work

and you can't re-send stream features without a stream restart for whatever reason

this is one of the reasons dialback is awkward, since there's no stream restart involved, so you have to offer post-auth features before auth.

yeah that's what I was wondering (why not "just" send new features)

becasue.

resetting the parser and wiping pre-stream restart data has some value one might think

So using a mobile client actually has some benefits. This way you can see new features your server advertizes quickly (/s)

Now go implement SASL2 and/or BIND2 :)

"just" sending new features might break backward compat

Call it XMPP2!

(i suspect this is a mostly theoretical concern)

or 3, or 4

XMPP 99