Difference between revisions of "Sprints/2020 March Duesseldorf"
Jump to navigation
Jump to search
Vanitasvitae (talk | contribs) |
|||
| Line 10: | Line 10: | ||
* Describe usage of OMEMO in MUCs (MUST be non-anonymous, RECOMMENDED to be members-only, …) | * Describe usage of OMEMO in MUCs (MUST be non-anonymous, RECOMMENDED to be members-only, …) | ||
* PEP access model SHOULD (or RECOMMENDED) to be open (explain security consequences of that.) | * PEP access model SHOULD (or RECOMMENDED) to be open (explain security consequences of that.) | ||
* Link device IDs to the JID in stanzas to avoid the struggles implied by possible ID clashes | |||
* Specify user-defined labels for devices/OMEMO identities to simplify key management | |||
* Maybe a different way to generate device IDs that is guaranteed to create non-clashing IDs | |||
* Describe in more detail how devices get activated inactivated (message from a device, or PEP event, what ever comes last) | * Describe in more detail how devices get activated inactivated (message from a device, or PEP event, what ever comes last) | ||
* Describe how to opt-out of OMEMO again. | * Describe how to opt-out of OMEMO again. | ||
* Ratchet Length Counter to determine stale devices. | * Ratchet Length Counter to determine stale devices. This includes automatic sending of empty messages to forward the ratchet. | ||
* Describe optional ''server please give me one pre-key+idenity key and then remove the pre key'' protocol | * Describe optional ''server please give me one pre-key+idenity key and then remove the pre key'' protocol | ||
* Shorter element names for elements that are often repeated | * Shorter element names for elements that are often repeated | ||
* Complete session by sending key transport message upon receiving a prekey message. | * Complete session by sending key transport message upon receiving a prekey message. | ||
* Stop using protobuf and build XML instead? (problem: need unique serialization method) | |||
* Ping Messages? | * Ping Messages? | ||
* Describe behaviour of recovering from broken session. | * Describe behaviour of recovering from broken session. | ||
* Clear up the one-time pre key thing | |||
* SCE | * SCE | ||
* Talk about possible interactions with MattJ's ideas, including | |||
** a mechanism to transfer data from one device to another during setup (e.g. using a QR-Code) | |||
** a list of all devices a JID has | |||
=== Responsibilities === | === Responsibilities === | ||
Revision as of 09:47, 6 March 2020
Goal
This Sprint is focussed on creating the next iteration of the OMEMO XEP.
Detailed TODO
- 12-byte IVs
- Restructure PEP usage to use one device node with multiple items (One item for each device); Maintain index node? (so we have something to +notify on)
- Describe usage of OMEMO in MUCs (MUST be non-anonymous, RECOMMENDED to be members-only, …)
- PEP access model SHOULD (or RECOMMENDED) to be open (explain security consequences of that.)
- Link device IDs to the JID in stanzas to avoid the struggles implied by possible ID clashes
- Specify user-defined labels for devices/OMEMO identities to simplify key management
- Maybe a different way to generate device IDs that is guaranteed to create non-clashing IDs
- Describe in more detail how devices get activated inactivated (message from a device, or PEP event, what ever comes last)
- Describe how to opt-out of OMEMO again.
- Ratchet Length Counter to determine stale devices. This includes automatic sending of empty messages to forward the ratchet.
- Describe optional server please give me one pre-key+idenity key and then remove the pre key protocol
- Shorter element names for elements that are often repeated
- Complete session by sending key transport message upon receiving a prekey message.
- Stop using protobuf and build XML instead? (problem: need unique serialization method)
- Ping Messages?
- Describe behaviour of recovering from broken session.
- Clear up the one-time pre key thing
- SCE
- Talk about possible interactions with MattJ's ideas, including
- a mechanism to transfer data from one device to another during setup (e.g. using a QR-Code)
- a list of all devices a JID has
Responsibilities
Who does what. TBD
Process
Since multiple people are going to work on multiple parts of the XEP simultaneously we probably need a git and commit early and often. Other and better ideas welcome.
Dates and Times
Saturday, March 7th - Sunday, March 8th 2020
Contact
Join us in the chatroom: xmpp:xmpp-sprint@chat.cluxia.eu?join
Also accessible via https://chat.cluxia.eu/anon/#xmpp-sprint
Venue
Chaosdorf
Hüttenstraße 25
40215 Düsseldorf
http://www.openstreetmap.org/node/1213625556 https://wiki.chaosdorf.de/XMPP_OMEMO_Sprint_2020
Accommodation
Wyndham Garden Düsseldorf City Centre Königsallee
Attendees
| Name (optional) | Nickname | Sprint project(s) | booked | comments |
|---|---|---|---|---|
| Paul Schaub | vanitasvitae | Revolutionize E2EE | yes | |
| Tim Henkes | Syndace | guess what! | yep | |
| Daniel Gultsch | iNPUTmice | TWOMEMO | yes | |
| Marvin W. | larma | urn:xmpp:omemo:1 | no | |
| Klaus | klaus | yes |