416
edits
(Dump the pad we had during the sprint.) |
|||
(3 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
== Collaborative pad == | |||
<pre> | <pre> | ||
# XMPP Düsseldorf Sprint | # XMPP Düsseldorf Sprint | ||
Line 250: | Line 252: | ||
### Easy MUC joining | ### Easy MUC joining | ||
(Seealso discussion below on the wiki page, https://wiki.xmpp.org/web/Sprints/2018_November_Dusseldorf/Pad#Easy-muc-joining_chat_discussion) | |||
Requirements | Requirements | ||
Line 334: | Line 338: | ||
- Added CORS header to the http_upload plugin | - Added CORS header to the http_upload plugin | ||
- Helped review config file for homebrewserver.club | - Helped review config file for homebrewserver.club | ||
</pre> | |||
== Easy-muc-joining chat discussion == | |||
<pre> | |||
<pep.> Ge0rG, are you happy with the easy-muc-joining stuff on the pad | |||
<Ge0rG> pep.: who is supposed to define the roominfo_inviteurl? | |||
<Ge0rG> I think the webchat url should be defined by the server Admin, and work for all MUCs on that domain | |||
<pep.> The server (component) admin would define the inviteurl, (prosody can probably generate that given a url in the config) | |||
<pep.> And alternative uris probably by the server admin as well, if a webchat is available for example, but maybe we want to let muc owners append to that | |||
<Ge0rG> And I'm not sure it's a good idea to call that "invite url" | |||
<pep.> What would you call it | |||
<Ge0rG> Webchat url? | |||
<Ge0rG> I think you are solving a different problem to what I intended, so could you explain the supposed flow? | |||
<pep.> webchat url would be in alternativeuris | |||
<pep.> inviteurl would explicitely link to an easy-invite page | |||
<pep.> Or some other project that is similar to it | |||
<Ge0rG> pep.: easy invite should be either centralized (join.jabber.network) or maintained by the client developer. I don't want to require every xmpp admin to host a copy. | |||
<Ge0rG> pep.: so I don't see merit in a per server or per compoment landing page | |||
<MattJ> pep., ^ | |||
<pep.> Ge0rG, why not? | |||
<pep.> What's the benefit of centralizing this | |||
<Ge0rG> pep.: | |||
> I don't want to require every xmpp admin to host a copy. | |||
<pep.> The client might also fallback to their own version of the page | |||
<pep.> In the end it's up to them anyway | |||
<Ge0rG> There's another tangential issue: inviting people into members only MUCs | |||
<pep.> Yeah we also discussed about that quickly, you'd need to be able to generate a token or something? Or maybe add to the participant list beforehand? | |||
<Ge0rG> You obviously could host an anonymous converse and add a "join with native client" button to it | |||
<pep.> Maybe we can improve/extend 401? | |||
<Ge0rG> pep.: 401 for MUCs, akin to mix invites? Sounds good to me | |||
<Ge0rG> I really only wanted to solve the webchat integration | |||
<pep.> Right so that is a non-goal for now. So for you, the alternativeuris field would be enough? | |||
<pep.> You wanted some kind of discovery on the easy-invite thing right? | |||
<Ge0rG> pep.: I'm still struggling with the UX flow. When I create an invitation, I disco info query the MUC, obtain the URL to the invitation page and share that? | |||
<Ge0rG> pep.: I wanted a web based discovery of a web chat URL | |||
<pep.> :/ | |||
<Ge0rG> So thinking of a json hosted on www.mucdomain or something | |||
<pep.> Yeah the flow we came up was, "You'll share the link from a client anyway" | |||
<Ge0rG> That really sounds like 401 for MUCs, and I think it's a good idea | |||
<pep.> Can you maybe write some feedback in the pad for what we currently have? Points we could work on or maybe restricting/redifining goals | |||
<Ge0rG> Because you move all the logic into the server. Obviously, this will require server support. | |||
<Ge0rG> pep.: just implement 0401 on a MUC JID! 😀 | |||
<pep.> :P | |||
<Ge0rG> pep.: seriously! (also I'm on mobile right now and need to focus on other things, so can't edit the pad anyway) | |||
<pep.> Ok, so what do we do with what we have atm. | |||
<pep.> I still want the alertnativeuri thing | |||
<Ge0rG> pep.: just have a landing page linking to the webchat or vice versa. | |||
<pep.> s/just // | |||
<pep.> Yeah but that means http discovery stuff. | |||
<Ge0rG> pep.: having multiple URIs returned is a mess for client developers. Which one to display / share? | |||
<pep.> and we need to come up with something else | |||
<Ge0rG> pep.: | |||
1. Add a "join with native client" linking the xmpp URI into the converse anonymous join dialog | |||
2. Implement 0401 on the MUC, returning the webchat page on created invitations | |||
<Ge0rG> All problems solved | |||
<Ge0rG> If you don't host a webchat, return your landing page instead. If you don't have one, let the client use its own landing page | |||
<Ge0rG> I really wanted to work with MattJ on mod_invite. Bummer. | |||
<MattJ> What did you want to do exactly? | |||
<Ge0rG> MattJ: replace the custom web form with easy xmpp invitation, use a preauth token to associate the invitation on IBR | |||
<Ge0rG> MattJ: essentially replace it with 0379 and 0401 | |||
<MattJ> I think I still don't understand how all those pieces fit together | |||
<MattJ> As far as I remember, you want to use IBR from the client to register, right? | |||
<Ge0rG> MattJ: right, with a preauth token included | |||
<MattJ> So what is it? an xmpp: link with an auth token? | |||
<Ge0rG> MattJ: https://xmpp.org/extensions/xep-0401.html#redeem-invitation | |||
<Ge0rG> https://xmpp.org/extensions/xep-0401.html#preauth-ibr | |||
<MattJ> Why is this better than the web form? | |||
<Ge0rG> MattJ: you don't need to copy paste your account from the web into jabber | |||
<jcbrand> Ge0rG I think supporting 401 for MUCs instead of using disco (as we thought) is a good idea. | |||
<jcbrand> I think I prefer the idea of getting the info in XMPP rather than making an HTTP request | |||
<jcbrand> and requiring the MUC service to provide a web server | |||
<MattJ> Ge0rG, I feel like step 1 is get the user an account. Installing the client breaks the user flow | |||
<Ge0rG> jcbrand: 👍 | |||
<Ge0rG> MattJ: I'm not sure yet whether I agree with that | |||
<MattJ> Ge0rG, the concept of a funnel is often used to model things like user sign-ups, you tend to lose a percentage of users at each step (depending on the complexity of the step) | |||
<pep.> Ge0rG, what do you 👍 on? | |||
<MattJ> So the fewer steps the better, the fewer context switches the better | |||
<Ge0rG> MattJ: yes, and by letting them register you have them kind of hooked up | |||
<MattJ> Exactly | |||
<Ge0rG> MattJ: but you need them to install the client anyway | |||
<MattJ> Sure | |||
<Ge0rG> pep.: on implementing 0401 | |||
<MattJ> But by that point you can even email people who did not log in yet | |||
<Ge0rG> MattJ: except you don't know their email | |||
<MattJ> "Do you need help? Here is our support room" etc. | |||
<MattJ> Ge0rG, but we can collect that in the form | |||
<Ge0rG> MattJ: that's borderline creepy | |||
<Ge0rG> And a GDPR violation | |||
<MattJ> What is? | |||
<Ge0rG> MattJ: technically, you can already replace the generation of invitation flow with 0401, and leave the redesign of the form / landing page for later | |||
<MattJ> "Your email will be used for password recovery and communicating with you regarding your account." | |||
<Ge0rG> MattJ: sending people an email without prior consent for that use case | |||
<Ge0rG> MattJ: I'd agree on using the web form if we had per client passwords or another way to export the result of the registration into my client | |||
<Ge0rG> (e.g. xmpp:newuser@domain?register;preauth=initialpasswordtoken) | |||
<Ge0rG> MattJ: and have the registration end in a page with a button "import account into jabber client", with that link | |||
<MattJ> Yes | |||
<Ge0rG> But we don't. | |||
<Ge0rG> And I'm kind of reluctant to include the password in a URI | |||
</pre> | </pre> |
edits