Sprints/2019 September Stockholm/Pad

TODO

• Daniel suggests bookmarks2 (0402)
  • Eases deletion of bookmarks (reflected pep event doesn’t overwrite client state when deleting multiple bookmarks)
  • Makes shared bookmarks easier (possibility to pin-point bookmarks users are unable to modify)
• PulkoMandy: in band registration, bookmarks2 may be possible
• LinkMauve suggests work on joinxmpp.org
  • simple entry point to xmpp ecosystem
• LinkMauve: Mastodon/XMPP “bridge”
• (Roel) Mastodon/XMPP auth
• (Roel) Have Yunohost support http upload

Results

• (daniel) bookmarks2 support + some refactoring for bookmarks for conversations
• (daniel/…) discovered numerous issues in the XEP + server bugs
• (linkmauve/daniel) issue with proxy65 on prosody servers that use epoll
• (lovetox) bookmarks2 support in gajim, merged on master (behind flag)
• (linkmauve) bookmarks2 module for prosody for conversion
• (linkmauve/pulkomandy) Bugs in prosody/ejabberd’s IBR code thanks to Renga implementing it
• (linkmauve) xmpp-rs: bookmarks2 and some muc support
• (pulkomandy) bookmarks2 in gloox, and in Renga
• (pulkomandy) IBR support + refactoring in Renga
• (roel, pep.) Text/narrative for joinxmpp + application for prototype fund
• (roel, pep.) work on prosody auth module for mastodon oauth backend
• (larma) work to improve bot bridges(/matterbridge) support for MUC
• (larma) check/test MUC/iq support in server implementations
• (fiaxh) bookmarks2 + fix bookmarks1 for dino
• (pep.) joinxmpp.org (basic implementation without CSS)
• (pep.) prototype fund application
• (pep.) jid proxy/aliasing discussions

Bookmarks 2

• Feedback for 0402:
  • sending the last published item should probably be disabled DONE
  • node needs to be configured to handle multiple items (can max_items be set to 0?) DONE
  • XEP should mention that bookmarks need to be fetched on login (because there is no way to automatically send all items) DONE
  • XEP should mandate conversion (Alternatively we can make 0411 convert between 1 and 2) DONE
  • Name should be an element to allow for multiple translated names (server injected bookmarks) next time
• Server bugs:
  • Ejabberd and Prosody do not understand pubsub#send_last_published_item in publish_options → https://issues.prosody.im/1436 https://issues.prosody.im/1437
• Spec bugs:
  • Why is the @name a SHOULD on <conference/>, at the end of §2? DONE
• Branch fixing things:
  • https://github.com/linkmauve/xeps/tree/xep-0402

JoinXMPP

XMPP description (de): - XMPP ist ein offener Standard für das Übertragen von Nachrichten - XMPP ist offen: XMPP ist von der IETF als RFC akzeptiert. Das Protokoll wird fortlaufend durch die XMPP Standards Foundation weiterentwickelt. - XMPP ist dezentral: ähnlich wie bei Email kann jeder mit einem eigenen Server am Netzwerk teilnehmen. - XMPP ist sicher: Ende-zu-Ende Verschlüsselung ist mit OMEMO und OpenPGP möglich. Alle Verbindungen sind TLS verschlüsselt. - Du benutzt XMPP nicht? Vermutlich doch. Viele weitverbreitete Dienste bauen auf XMPP auf, auch wenn sie nicht an dem dezentralen Netzwerk teilnehmen: Whatsapp, Fortnite, Nintendo Switch, Android und iOS (Push Notifications), WebRTC

The public network for secure, federated messaging

• XMPP is an established and open standard for federated chat ~Individuals and communities can set up or join public chat services Join the network of interoperating chat providers or set one up for your community~ Joining one of the servers allows you to chat w

ith individuals or communities on other servers

• XMPP is secure Use End-to-End encryption for your chats. No advertising or selling of your personal data. The ability to pick a provider using policies you feel comfortable with.
• XMPP runs everywhere Keep your conversations synchronized between all your devices. Support for Android, iOS, Windows, MacOs and Linux

Chat one to one, make private group chats for your friends or public channels for your favorite topic.

• Discover conversations you are interested in. Find public channels of your interest or start your own

(this is copy pasta from mastodon)

Each server is independent

XMPP is based on free, open-source software that anyone can install on a server. Independent operation, independent rules.

The network is interoperable

Using a suite of standard and established protocols, XMPP servers can exchange information with each other, allowing people to chat seamlessly across the network.

Use software of your choice

XMPP clients come in different shapes and sizes, from mobile to desktop to web. Find one that fits your needs, whether you just want to get stuff done or whether you want to have full control over all options.

---

• XMPP is decentralized: ähnlich wie bei Email kann jeder mit einem eigenen Server am Netzwerk teilnehmen.
• XMPP is secure: End-to-End encryption with OMEMO and OpenPGP. All connections are additionally TLS encrypted.
• XMPP is open: It is an IETF approved RFC and continued to be developed by the XMPP Standards Foundation.
• Many popular services are based on XMPP, even if not decentralized: Whatsapp, Fortnite, Nintendo Switch, Android und iOS (Push Notifications), WebRTC

About

joinxmpp.org is an initiative by users and developers to promote a public federated chat network based on XMPP. We recommend a limited set of high-quality service providers that [conform to our standards]. In addition, we curated a selection of apps which are secure, well designed and meet expectations for contemporaty messaging applications.

Aliasing component

Goals: - provide aliasing capabilities, 1:1 or 1:N mapping - provide an anonymity layer

Possible XEPs to use: - Stanza forwarding (0297)

Another idea: Have a server component do c2s to other servers? And then use stanza forwarding. Similar to having multi-account clients, but with the added benefit that there is only one connection to the server (mobile use-case). Sounds fucked-up though. Imagine all the po ssibilities! (onion routing?)

Are we just trying to reimplement c2s?

Use-case 1: Customer support (1:1)

Request random identity

 SENT:
 <iq type='set' to='alias.service.tld'>
   <alias xmlns='urn:example:aliasing:0' />
 </iq>

 RECV:
 <iq type='result' to='pep@foo.bar'>
   <alias xmlns='urn:example:aliasing:0'>
     <jid>abcd@alias.service.tld</jid>
   </alias>
 </iq>

Request specific identity

 SENT:
 <iq type='set' to='alias.service.tld'>
   <alias xmlns='urn:example:aliasing:0'>
     <jid>support@alias.service.tld</jid>
   </alias>
 </iq>

 RECV:
 <iq type='result' to='pep@foo.bar'>
   <alias xmlns='urn:example:aliasing:0'/>
 </iq>

Use-case 2: Customer support (1:N)

Request specific identity for daniel and pep

Daniel sends first bind IQ. Component replies with success result and gives a token.

 SENT:
 <iq type='set' from='daniel@example.org' to='alias.service.tld'>
   <alias xmlns='urn:example:aliasing:0'>
     <jid>support@alias.service.tld</jid>
   </alias>
 </iq>

 RECV:
 <iq type='result' to='daniel@example.org'>
   <alias xmlns='urn:example:aliasing:0'>
     <token>TOKEN</token>
   </alias>
 </iq>

Pep sends bind IQ including TOKEN. Component replies with success result.

 SENT:
 <iq type='set' from='pep@foo.bar' to='alias.service.tld'>
   <alias xmlns='urn:example:aliasing:0'>
     <jid>support@alias.service.tld</jid>
     <token>TOKEN</token>
   </alias>
 </iq>

 RECV:
 <iq type='result' to='pep@foo.bar'>
   <alias xmlns='urn:example:aliasing:0'/>
 </iq>

Aliasing multiple JIDs (bare or full) to an identity prevents IQs from being forwarded.

Customer -> support@anon.service.tld

 <message to="support@anon.service.tld">
   <body>Can you help me?</body>
 </message>

Anon->Daniel

 <message from="anon.service.tld" to="daniel@example.com">
   <forward xmlns="forwarding">
     <aliasing xmlns='urn:example:aliasing:0'>
       <message from="customer@domain.tld" to="support@anon.service.tld" xmlns="jabber:client">
         <body>Can you help me?</body>
       </message>
     </aliasing>
   </forward>
 </message>

Daniel response

 <message form="daniel@example.com" to="anon.service.tld">
   <forward xmlns="forwarding">
     <aliasing xmlns='urn:example:aliasing:0'>
       <message from="support@anon.service.tld" to="customer@domain.tld">
         <body>Yes</body>
       </message>
     </aliasing>
   </forward>
 </message>

Anon service checks if daniel@example.com has permissions to send as support@anon.service.tld

Use-case 3: MUC JID proxy

• Pep requests identity specifying iq shouldn’t be forwarded.
• Pep sends join presence to MUC

 <presence something something />

OMEMO Iconography

https://gist.github.com/mar-v-in/b683220a55bc65dcdafc809be9c5d0e4