Sprints/2018 November Dusseldorf/Pad

Collaborative pad

 * 1) XMPP Düsseldorf Sprint


 * 1) Agenda
 * 2) Specification

✓ Easy-muc-joining (JC, Ge0rG, MattJ, pep., Purple Link)

✓ Writing the XEP for Push Notifications (jcbrand, Daniel, Ge0rG, MattJ, Purple Link)

Configure notifications preferences from a MUC

✓ Inbox XEP - sync open conversations across clients (pep., Daniel, JC, Ge0rG, Purple Link, MattJ)

✓ 0283

Referencing of messages (Using XEP-0372 to reference a message) (JC, pep.) (Deferred)

Spec a component (or SIMS?) To expose rich HTTP links to clients (Link Purple, pep.)

Finish to design the DOAP thing for clients (Link Mauve, pep.)

Independence PR for OMEMO XEP-384 (Syndace) (WIP here: https://github.com/Syndace/xeps)


 * 1) Implementation

IBR in poezio, maybe (pep.)

Work on Chatty, based on info on XEPs from Ge0rG (Haeckse)

Feedback on the IBR in Poezio / slixmpp (For Mauve Link, from pep.)

OMEMO in poezio (pep., Syndace)

Jingle in Converse (Mauve Link)

Support for XEP-0156 in Converse (jcbrand)

Easy User Onboarding - ~Ge0rG~, jcbrand, Link Mauve, pep.

add platform detection and link creation ("edit mode") to easy xmpp invitation

joining MUCs with converse

independent (web-enabled) MUC domain also has a corresponding XMPP domain or web chat

a MUC also has other venues (web, IRC…)


 * 1) Documentation

Add / Update documentation on how to set up a webchat support room

update client and server how-to documentation for homebrewserver.club - r

-> ✓ modern & easy config for prosody 0.11

-> config for converse & prosody 0.11

-> Spanish translation - rtq3

Improving python-omemo (doc, tests) (DEFERRED)

✓ thinking about the future of OMEMO

Change parameters in the crypto-protocols

Change the wireformat from protobuf to XML

Don't spread the bundles across multiple nodes but use one single PEP node

Use OX to get experience about full-stanza-encryption and add that to OMEMO later


 * 1) Misc

✓ Find a hotel (For Purple Link, from all the others)

Release Prosody 0.11 (MattJ)

✓ Send email to CCC for XMPP assembly (pep.)

Create official Docker container for Converse / Prosody (and for other servers if anyone is interested)

Split python-omemo packages in AUR into dev / released versions. (pep.)

✓ Send an email to SCAM for CCC stuff

Check CORS headers in compliance tester (iNPUTmice)

Register push app server for MUC (iNPUTmice)


 * 1) Day 1
 * 2) Open chats XEP

Private PEP node containing list of JIDs that represent open chats

One-on-one chats (bare JID) and MUC PMs (full JIDs)

Everything in multiple items (but need to fix PEP so that we can get deletion notifications)

MUC bookmarks with auto-join are merged into this list for the UI, but not stored in it (clients may/should offer a way to ignore the auto-join flag)

on incoming messages, the server adds a new "chat", publishes PEP update before sending out the message

a client opening a chat tab publishes the new JID before sending out the message

node name: urn:xmpp:open-chats:0

    


 * 1) MUC push notifications

Client registers push app server against a MUC service

The MUC services keeps track of nodes/tokens and app servers

Node needs to be associated to bare JID of the user

If the server gets an error from the push app server, it can unregister the JID

Push notifications XEP needs to be updated so that you can send the entire stanza (not just body)

For each message in MUC

the MUC service looks up all registered push app servers for users not online and sends out push notifications to them

The push app server is responsible for deciding whether to send a push message or not

Business rules:

Might be a good idea to let the user register their nick with the MUC https://xmpp.org/extensions/xep-0045.html#register

That way, the user can be mentioned in order to trigger a push notification (e.g. email) for them.

room creates a map of bare-jid -> [app.server,node-id] on every join client re-registers themselves, communicating the app.server,node-id tuple; therefor room knows which app.sever-node-id tuples are currently joined on every incoming message room iterates over list of app.server,node-id tubples and sends a push to every tuple that is not joined an error-bounce will mark a tuple as not-joined



The XEP probably needs a full rewrite but that's fine since nobody was using it anyways..

On old account:

- Create PEP node with publish_options whitelist of current roster JIDs, including JID of the new account

* "whitelist" and not "roster" access model is needed so that read access is still granted once unsubscribed

- Send unsubscribe request with item to each contact

On new account: - Send subscription request with item to each contact

On receiving server - if supported: - Advertise feature support, so that receiving client knows it can _not_ do the action below - Create private PEP node with all items ever received so clients can add a note in the UI

* roster annotation might have been better but support non-existent?

* allows clients that won't get the subscription presence (but only roster push) to know it was coming from the request

On receiving client - fallback if no server support: - Advertise feature support? - First client receiving the subscription presence accepts it and creates private PEP node/appends item

Security concerns: - Compromised account was mentioned, in which case an attacker could automatically move all contacts to a new account, Do we want to worry about this, (I don't think so. pep.) - Servers could "disable" it for familly setups for example where it is unlikely an account would be moved.


 * 1) Compliance Tester

- Make 156 required once converse supports it. - Add check for CORS support for file upload

- wrote compliance tester test for 'bookmark conversion' and 'vcard avatars on muc', both wont be published for now because they are not wide spread enough - tried to fix a bug in Conversations that only happens randomly on Android 9 - various discussions
 * 1) Who slacked off most - summary
 * 2) Daniel


 * 1) MattJ

- Prosody release tasks (blog, release notes, builds) - CORS in mod_http_upload - Documentation and default config improvements


 * 1) pep.

- Participated in Inbox discussions, - Registered assembly at CCC - Brought back slixmpp omemo plugin to life; Currently instanciating an omemo object properly


 * 1) Link Mauve

- Implementing Jingle in converse * lots of bugs * porting strophe plugin to jquery to not jquery

- Figuring out exceptions in converse with JC

- Playing with jingle.js in FF - Tried deploying jsxc; not there yet

- Helped pep/syndace with slixmpp plugin interface


 * 1) Roel

One of the initiators to homeserverclub

- Editing the article for homeserverclub to make sane defaults for prosody; struggling with stuff on the prosody docuemntation that id not reflect reality; poking MattJ - Now have a working config - Poked people to see what modules they have


 * 1) Syndace

- Browsed through the PRs for OMEMO in xeps; found request from the original author including all relevant changes but it got closed for inactivity -> On Sunday, extend the PR to include usage of single pep items -> Talk to Andy Straub about it

- Helped pep. with omemo impl. in slixmpp/poezio


 * 1) JC

- Easy XMPP onboarding discussion with Ge0rG

- 0156; fixing failing tests


 * 1) Day 2


 * 1) 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

As a user sending an easy-invite landing page, I’m presented with a “share this MUC” button (or a link) that generates an invite page link.

As an invitee opening up an easy-invite landing page, I'm presented with a button (or a link) that takes me to a webchat to join in.

Technical details:

https://xmpp.org/extensions/xep-0045.html#registrar-formtype-roominfo





Implementation notes: A client may want to offer users the ability to share an invite URL. The disco field 'muc#roominfo_inviteurl' can be used to specify a link to a user-friendly invite page. The 'muc#roominfo_alternativeuris' field can be used to provide alternative avenues through which the MUC can be joined, e.g., webchat, or other bridged protocols.


 * 1) Slacking status
 * 2) JC

- Easy-muc-joining discussion - XEP 156 support in converse: - preparatory work - fixing tests - rebasing Link Mauve's PR - needs testing - Rendering https images


 * 1) Andy

- Discussions about OMEMO XEP (ODR, twomemo)


 * 1) Syndace

- Progress on the 384 PR - Discussed about further changes that need to be made to the PR - Slixmpp omemo plugin; found missing features


 * 1) pep.

- Easy-muc-joining discussions; asked feedback to Ge0rg (bad idea); needs some reworking - Slixmpp/omemo still WIP but getting there; decryption working! - Started fr translation for prosody


 * 1) iNPUTmice

- Issues with Android 9 - Bug fixing on Conversations - Compliance tester test for CORS headers; not pushed yet, missing help file - Participated in OMEMO discussions


 * 1) Link Mauve

- Easy-muc-joining discussions - Working on jingle impl for converse

* Realized that he was using an old version of the jingle lib, a new one is available but has never been published

- Helped test CORS header - FR translation for prosody release


 * 1) MattJ

- 90% of prosody release

* Poked packagers

* Blog post being translated in multiple languages (es, nl, fr)

- Added CORS header to the http_upload plugin - Helped review config file for homebrewserver.club

Easy-muc-joining chat discussion
  Ge0rG, are you happy with the easy-muc-joining stuff on the pad   pep.: who is supposed to define the roominfo_inviteurl?   I think the webchat url should be defined by the server Admin, and work for all MUCs on that domain   The server (component) admin would define the inviteurl, (prosody can probably generate that given a url in the config)   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   And I'm not sure it's a good idea to call that "invite url"   What would you call it   Webchat url?   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 Ge0rG I think supporting 401 for MUCs instead of using disco (as we thought) is a good idea. I think I prefer the idea of getting the info in XMPP rather than making an HTTP request 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