23
edits
Difference between revisions of "Summer of Code 2021"
Jump to navigation
Jump to search
m
no edit summary
m (Tweak deliverables on the Mellium/Jingle idea) |
m |
||
| (4 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
= Participation = | = Participation = | ||
The XSF | The XSF has applied to be a mentoring organisation for Google Summer of Code 2021. We will know whether we are accepted or not on March 9th with the official list is published. | ||
XMPP oriented projects should still add project ideas to the below list. | |||
== Dates == | == Dates == | ||
| Line 66: | Line 68: | ||
* A demo app to start a conversation | * A demo app to start a conversation | ||
=== Group Chat | === Group Chat === | ||
''Brief explanation:'' Add support for group chats using either Multi-User Chat or Mediated Information Exchange (MIX).<br/> | ''Brief explanation:'' Add support for group chats using either Multi-User Chat or Mediated Information Exchange (MIX).<br/> | ||
| Line 77: | Line 79: | ||
=== End-to-End Encryption === | === End-to-End Encryption === | ||
''Brief explanation:'' Add support for end-to-end (E2E) encryption using OMEMO<br/> | ''Brief explanation:'' Add support for end-to-end (E2E) encryption using OMEMO, or MLS<br/> | ||
''Involved Technologies:'' Go, Go Subrepos, OMEMO<br/> | ''Involved Technologies:'' Go, Go Subrepos, OMEMO or MLS<br/> | ||
''Relevant readings:'' [https://xmpp.org/extensions/xep-0384.html XEP-0384: OMEMO Encryption]<br /> | ''Relevant readings:'' [https://xmpp.org/extensions/xep-0384.html XEP-0384: OMEMO Encryption], [https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/ The Messaging Layer Security (MLS) Protocol (draft-ietf-mls-protocol)]<br /> | ||
''Deliverables / Expected Results:''<br/> | ''Deliverables / Expected Results:''<br/> | ||
* A well-designed API and well-tested library for encrypting messages with OMEMO | * If using MLS, an XEP describing behavior and how MLS should be integrated with XMPP | ||
* A well-designed API and well-tested library for encrypting messages with OMEMO or MLS | |||
* Changes to the Go standard library and subrepos to add any missing cryptographic primitives or expose operations that are currently internal only. | * Changes to the Go standard library and subrepos to add any missing cryptographic primitives or expose operations that are currently internal only. | ||
== Psi == | |||
''Website:'' https://psi-im.org/<br/> | |||
''Source Code:'' https://github.com/psi-im/psi<br/> | |||
''Description:'' An XMPP client for advanced users.</br> | |||
''Project Contact:'' [[User:Rion|rion]], Tehnick, VitoZz<br/> | |||
''Relevant readings:'' [https://psi-plus.com/wiki/en:main]<br/> | |||
''Teaser Tasks:'' [https://github.com/psi-im/psi/milestone/4]<br/> | |||
''Chat:'' [xmpp:psi-dev@conference.jabber.ru?join psi-dev@conference.jabber.ru] | |||
=== Mediated Information Exchange (MIX) === | |||
''Brief explanation:'' Add support for Mediated Information Exchange (MIX).<br/> | |||
''Involved Technologies:'' Qt, C++<br/> | |||
''Relevant readings:'' [https://xmpp.org/extensions/xep-0369.html XEP-0369: Mediated Information eXchange (MIX)]<br /> | |||
''Deliverables / Expected Results:''<br/> | |||
* A set of classes in [https://github.com/psi-im/iris iris] library to support MIX extensions. | |||
* A MIX management component in Psi itself similar to one implemented for MUC. | |||
* A Working UI (probably some rework of the current MUC UI to make it compatible with MIX) | |||
* The solution has to be tested with popular XMPP servers | |||
=== QML UI === | |||
''Brief explanation:'' A modern looking UI for both (group-)chat and roster | |||
''Involved Technologies:'' Qt, QML, JavaScript, C++<br/> | |||
''Relevant readings:'' https://en.wikipedia.org/wiki/QML<br/> | |||
''Deliverables / Expected Results:''<br/> | |||
* It's a huge task, so expected an implementation of standalone QML/*cross-platform* UI with clear and well-documented API interfaces. | |||
* The UI may be backed by some mocked C++ code where Psi code should be taken as a guidance. This is perfectly fine to borrow design/API ideas from other clients too. | |||
* It's assumed the UI will be used not just with Psi. So the branded parts preferably should be kept aside and instead set via API. | |||
* The UI should provide next functions: model/view-based chat/group-chat, roster, avatars, statuses, recent (group-)chats, contact list (with groups/tags), contacts management, own status management. | |||
= Join the group chat! = | = Join the group chat! = | ||