Difference between revisions of "Sprints/2018 November Dusseldorf/Pad"

Jump to navigation Jump to search

Sprints/2018 November Dusseldorf/Pad (view source)

Revision as of 14:45, 29 November 2018

10,188 bytes added ,  14:45, 29 November 2018
Add discussion that happened in chat about easy-muc-joining
(Fix section name.)
(Add discussion that happened in chat about easy-muc-joining)
Line 336: Line 336:
- 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>
Pep.
416

edits

Retrieved from "https://wiki.xmpp.org/web/Special:MobileDiff/10537"

Navigation menu