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  in publish_options → https://issues.prosody.im/1436 https://issues.prosody.im/1437
 * Spec bugs:
 * Why is the @name a SHOULD on, 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 ith individuals or communities on other servers Chat one to one, make private group chats for your friends or public channels for your favorite topic. (this is copy pasta from mastodon)
 * XMPP is an established and open standard for federated chat ~Individuals and communities can set up or join public chat servicesundefinedJoin the network of interoperating chat providers or set one up for your community~ Joining one of the servers allows you to chat w
 * 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
 * Discover conversations you are interested in. Find public channels of your interest or start your own

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?

Request random identity
SENT:   

RECV:   abcd@alias.service.tld 

Request specific identity
SENT:   support@alias.service.tld 

RECV:   

Request specific identity for daniel and pep
Daniel sends first bind IQ. Component replies with success result and gives a token.

SENT:   support@alias.service.tld 

RECV:  <alias xmlns='urn:example:aliasing:0'> TOKEN </iq>

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

SENT:  <alias xmlns='urn:example:aliasing:0'> support@alias.service.tld TOKEN </iq>

RECV:  <alias xmlns='urn:example:aliasing:0'/> </iq>

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

Customer -&gt; support@anon.service.tld
<message to="support@anon.service.tld"> Can you help me?

Anon-&gt;Daniel
<message from="anon.service.tld" to="daniel@example.com"> <aliasing xmlns='urn:example:aliasing:0'> <message from="customer@domain.tld" to="support@anon.service.tld" xmlns="jabber:client"> Can you help me?

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

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