121
edits
Difference between revisions of "GSoC/2020/Project Ideas"
Jump to navigation
Jump to search
→High Level Messaging API
(→List of Project Ideas: Added Openfire) |
Vanitasvitae (talk | contribs) |
||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 63: | Line 63: | ||
''Involved Technologies:'' Android compatible Java 8, WebSockets<br/> | ''Involved Technologies:'' Android compatible Java 8, WebSockets<br/> | ||
''Mentor(s):'' Paul Schaub (vanitasvitae) [mailto:vanitasvitae@fsfe.org <vanitasvitae@fsfe.org>]<br/> | ''Mentor(s):'' Paul Schaub (vanitasvitae) [mailto:vanitasvitae@fsfe.org email: <vanitasvitae@fsfe.org>]<br/> | ||
''Deliverables / Expected Results:''<br/> | ''Deliverables / Expected Results:''<br/> | ||
| Line 76: | Line 76: | ||
Currently Smack can establish connections via TCP/IP and HTTP via BOSH. WebSockets are yet another way to connect to a server. | Currently Smack can establish connections via TCP/IP and HTTP via BOSH. WebSockets are yet another way to connect to a server. | ||
=== Smack Bot Framework === | |||
''Brief explanation:'' Create a bot framework with Smack that enables the easy definition and creation of bots.<br/> | |||
Smack is currently mainly targeted towards client developers. It would be nice to make it more appealing to bot developers. | |||
''Involved Technologies:'' Android compatible Java 8<br/> | |||
''Mentor(s):'' Paul Schaub (vanitasvitae) [mailto:vanitasvitae@fsfe.org email: <vanitasvitae@fsfe.org>]<br/> | |||
''Deliverables / Expected Results:''<br/> | |||
* Being able to create a chat bot that does a simple task with only a few lines of code. | |||
* Implement a spam fighting bot for use in multi user chats. That bot should be invitable to a chat by admins and then monitor messages. It must ban spammers and remove their messages with the help of XEP-0425: Message Moderation. Configuration is per multi user chat and should be done via Data Forms or - if supported by the admins client - via XEP-0439: Quick Responses. | |||
=== High Level Messaging API === | |||
''Brief explanation:'' Smack provides APIs for sending and receiving messages (duh).<br/> | |||
What this project is about is to create a high level API that unifies the process of sending plaintext and e2ee encrypted messages. | |||
''Involved Technologies:'' Android compatible Java 8<br/> | |||
''Mentor(s):'' Paul Schaub (vanitasvitae) [mailto:vanitasvitae@fsfe.org email: <vanitasvitae@fsfe.org>]<br/> | |||
''Deliverables / Expected Results:''<br/> | |||
* An intuitive, easy to use API for sending and receiving plain and encrypted messages using OMEMO and OX. | |||
* A framework that makes it easy to listen for incoming messages, message corrections, retractions and other updates and that is easy to plug into as a client. | |||
== Dino == | == Dino == | ||
| Line 86: | Line 112: | ||
''Project Contact Person:'' [[User:Larma| Marvin W. (larma)]]<br/> | ''Project Contact Person:'' [[User:Larma| Marvin W. (larma)]]<br/> | ||
''List of Teaser Tasks:'' [https://github.com/dino/dino/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22 Dino good first issues]<br/> | |||
''Contact chat:'' [xmpp:chat@dino.im?join chat@dino.im] | ''Contact chat:'' [xmpp:chat@dino.im?join chat@dino.im] | ||
| Line 120: | Line 148: | ||
Real-time text is text transmitted instantly while it is being typed or created. The recipient can immediately read the sender's text as it is written, without waiting. It allows text to be used as conversationally as a telephone conversation, including in situations where speech is not practical (e.g., environments that must be quiet, environments too noisy to hear, restrictions on phone use, situations where speaking is a privacy or security concern, and/or when participant(s) are deaf or hard of hearing). | Real-time text is text transmitted instantly while it is being typed or created. The recipient can immediately read the sender's text as it is written, without waiting. It allows text to be used as conversationally as a telephone conversation, including in situations where speech is not practical (e.g., environments that must be quiet, environments too noisy to hear, restrictions on phone use, situations where speaking is a privacy or security concern, and/or when participant(s) are deaf or hard of hearing). | ||
== Prosody IM == | |||
''Website:'' https://prosody.im/<br/> | |||
''Source Code:'' https://hg.prosody.im/<br/> | |||
''Description:'': Prosody is a lightweight XMPP server that aims to be easy to set up and configure, and efficient with system resources.<br/> | |||
''Project Contact Person:'' Matthew Wild [mailto:mwild1@gmail.com <mwild1@gmail.com>]<br/> | |||
''List of Teaser Tasks:'' https://issues.prosody.im/?q=state%3Dopen+difficulty%3Deasy | |||
''Contact chat:'' [xmpp:prosody@conference.prosody.im prosody@conference.prosody.im] [https://chat.prosody.im/ web client] | |||
=== Standalone mod_firewall === | |||
''Brief explanation:'' This project would produce a version of mod_firewall that runs standalone and can be connected | |||
with any XEP-0114 compliant server.<br/> | |||
''Involved Technologies:'' Lua, XMPP<br/> | |||
''Mentor(s):'' Matthew Wild (MattJ) [mailto:mwild1@gmail.com <mwild1@gmail.com>], Kim Alvefur (Zash)<br/> | |||
''Deliverables / Expected Results:''<br/> | |||
* Standalone server-independent mod_firewall | |||
* Server-side implementation that uses external mod_firewall for determining whether/how to to route a stanza. | |||
''Milestones:''<br/> | |||
# Design and document server-independent protocol for communicating with external mod_firewall. | |||
# Develop standalone mod_firewall process that connects to a XEP-0114 compliant server and implements above protocol. | |||
# Develop server-side code to communicate with external mod_firewall and allow it to filter stanzas. | |||
Prosody's mod_firewall is a rule-based XMPP-layer firewall that is useful for security and | |||
anti-spam purposes. However it currently only works with Prosody, and needs to be loaded | |||
into the main process. | |||
This project would produce a version of mod_firewall that runs standalone and can be connected | |||
with any XEP-0114 compliant server. | |||
The project would include: | |||
* Protocol design: develop and document (in XEP form) a protocol whereby a server may submit a stanza to the standalone mod_firewall and receive a decision. | |||
* Coding (Lua): adapt mod_firewall's core code to run standalone, and connect to servers as a component implementing this protocol. | |||
* Coding: Additionally add support for the new protocol to an XMPP server of your choice. | |||
=== Implement MIX === | |||
''Brief explanation:'' This project would add support for the MIX suite of XEPs to Prosody<br/> | |||
''Involved Technologies:'' Lua, XMPP<br/> | |||
''Mentor(s):'' Matthew Wild (MattJ) [mailto:mwild1@gmail.com <mwild1@gmail.com>], Kim Alvefur (Zash)<br/> | |||
''Deliverables / Expected Results:''<br/> | |||
* A server with support for creating and joining MIX channels. | |||
* A suite of [https://matthewwild.co.uk/projects/scansion Scansion] tests for testing correct MIX behaviour | |||
''Milestones:''<br/> | |||
# Implement support for creating, joining and exchanging messages with MIX rooms. | |||
# Implement channel administration (XEP-406) | |||
MIX is a new protocol for group chats in XMPP that provides a modern alternative to the existing MUC protocol. It is not currently | |||
widely implemented, but this project would provide a server-side implementation against which clients can be built and tested. | |||
Basic support may be found in experimental branches of Conversations, but it is expected that this implementation may be tested through | |||
use of Scansion and/or other client-side testing tools and libraries. | |||
= How to add your project idea = | = How to add your project idea = | ||