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
Ge0rG
jonas’: so it's a server config then?
jonas’
probably?
Ge0rG
what if I want to have a nicer webchat on my MUC?
Ge0rG
which is custom-hosted
jonas’
I don’t care ;)
jonas’
I think that’s a different use-case anyways
pep.
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
Ge0rG
typically you need some kind of web space and xmpp / BOSH / CORS magic.
Zash
Step 1: Only do it for public (not members only) non-hidden MUCs
Ge0rG
what Zash said
Ge0rG
as a server admin, I'd like to have a default webchat proto-URL where you only need to fill in the MUC name
Ge0rG
as a MUC owner, I'd like to see that / have an opt-in / override it
pep.
Ge0rG: a few services have that already, the former
pep.
Look at chat.jabbefr.org's JS for example
zachhas left
zachhas joined
Nekithas left
Nekithas joined
Ge0rG
> chat.jabbefr.org’s server IP address could not be found.
pep.
There's a look from jabberfr.org somewhere probably✎
pep.
There's a link from jabberfr.org somewhere probably ✏
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
lovetox_has left
pep.
(I can point to something more specific when I get a laptop)
Or we could go full generic and figure out how to link arbitrary URIs from MUC metadata
Ge0rG
Zash: roominfo#metadata_json
jubalhhas joined
jabberjockehas left
jonas’
xep-0157? ;)
Zash
heh
jonas’
seriously though, how about we solve this thing at hand right away with the obvious solution?
MattJ
+1
zachhas left
zachhas joined
Zash
`hg cp mod_muc_lang.lua mod_muc_webchat_url.lua`
jonas’
MattJ, excellent. my offer stands: you do this for prosody on xmpp.org, I do it for muclumbus and an update for '45.
Ge0rG
jonas’: what is the obvious solution? A per-room manual setting? Defaulting to the server's webchat, with some kind of placeholder?
MattJ
Zash, ==> mod_muc_generic_additional_options.lua
jonas’
Ge0rG, the obvious solution is that if a server is configured with a muc log and converse, it should be published in a form field.✎
Zash
muc#room{config,info}_* eh?
MattJ
https://www.xkcd.com/974/
jonas’
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. ✏
Yagizahas joined
Ge0rG
jonas’: on the MUC domain or on individual MUCs?
Ge0rG
on both?
jonas’
Ge0rG, on the individual MUCs
Ge0rG
jonas’: what if some MUC owners don't want that?
jonas’
Ge0rG, make it members-only?
jonas’
make it password-protected?
jonas’
apply the typical access control measures for your MUC
MattJ
Agreed, if it's open then anyone can point a web chat to you and advertise it somewhere, whether you like it or not
MattJ
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)
jonas’
MattJ, so I think the conditions should be: anon webchat configured && open && not password protected.✎
jonas’
MattJ, so I think the conditions should be: anon webchat configured && open && not password protected && public?.✎✏
jonas’
MattJ, so I think the conditions should be: anon webchat configured && open && not password protected && public(?). ✏
MattJ
+1
jonas’
MattJ, `roominfo#webchat_url`?
Zash
In the case of Prosody, the anon webchat isn't attached to the MUC component, which complicates things. Implementation detail tho.
pdurbinhas joined
Ge0rG
I'm okay with a server config
MattJ
I think it's easy enough to add a config option to the MUC component to supply the web chat URL
jonas’
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"' ;)
Zash
I'm in fact typing this out right now
jonas’
<3
Daniel
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
Daniel
otherwise you won’t be able to block users anymore
MattJ
We already have that
Daniel
cool
jonas’
s/roominfo#/muc#roominfo_/
jonas’
code for muclumbus is ready for testing :)
patrickhas joined
jabberjockehas joined
Zash
jonas’: %s would be the room jid or the node?
jonas’
Zash, node?
patrickhas left
jonas’
what node?
Zash
localpart of room JID
jonas’
ah
Zash
orrr "https://chat.example.com/join?room={node}"
jonas’
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
jonas’
whatever works :)
Ge0rG
Zash: what if I have multiple MUC domains?
jonas’
(on the client side, I expect a perfectly working URL)
jonas’
Ge0rG, since that’s a per-componetn/domain setting ... ;)
Ge0rG
Right
zachhas left
zachhas joined
remkohas joined
remkohas left
Zash
I made {jid}, {node}, {host}
Ge0rG
awesome
jonas’
now for the most important question. which emoji/icon should I use in the muclumbus web interface?
Would it pick up a vcard for xsf@ if one had set one?
jonas’
yes
jonas’
muc.xmpp.org is in the whitelist
mr.fisterhas joined
Zash
Entire domain?
jonas’
yes
Zash
Wouldyoulookatthat
wurstsalat
jonas’: so gajim.org is probably on the whitelist but it fails to provide its avatar the right way?
jonas’
wurstsalat, refresh
jonas’
wurstsalat, it just took a while to re-scan the MUC
moparisthebest
ooh entire domain you say, can I create mucs here?
jonas’
moparisthebest, no
Zash
You also can't set vcards.
jonas’
off to bed now
mimi89999has left
mimi89999has joined
mimi89999has left
wurstsalat
jonas’: I do like the new layout!
mimi89999has joined
kokonoehas left
LNJhas left
kokonoehas joined
vanitasvitaehas joined
krauqhas left
krauqhas joined
Danielhas left
Danielhas joined
pdurbinhas joined
Daniel
jonas’: I'm currently getting internet server error from the api
Marandahas left
eevvoorhas left
Danielhas left
Danielhas joined
Jens Kortehas left
debaclehas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
davidhas left
pdurbinhas left
zachhas left
zachhas joined
j.rhas left
j.rhas joined
davidhas joined
Andrew Nenakhovhas joined
Chobbeshas left
Andrew Nenakhovhas left
mukt2has joined
pep.
Newbie question: "After SASL negotiation, the parties MUST restart the stream." why is that?
Nekithas left
zachhas left
zachhas joined
Zash
pep., iirc to be sure that any sensitive SASL data can be wiped from memory.
Zash
And so that you can offer new features.
mukt2has left
pep.
new features? ah, after being authenticated
Zash
post-auth only stream features
fippo
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
Zash
and you can't re-send stream features without a stream restart for whatever reason
Zash
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.
pep.
yeah that's what I was wondering (why not "just" send new features)
Zash
becasue.
Zash
resetting the parser and wiping pre-stream restart data has some value one might think
Andrew Nenakhovhas joined
pep.
So using a mobile client actually has some benefits. This way you can see new features your server advertizes quickly (/s)
Andrew Nenakhovhas left
Zash
Now go implement SASL2 and/or BIND2 :)
fippo
"just" sending new features might break backward compat