RetroShare Development Team is happy to announce to take place in the Google Summer of Code 2016!
Google Summer of Code is a global program focused on introducing students to open source software development. Students work on a 3 month programming project with an open source organization during their break from university. Google provides a stipend of 5500 USD per accepted student developer.
Retroshare is receiving support from the Freifunk Mentoring Organization, which acts as an umbrella organisation for other wireless communities like Ninux, qaul.net, Guifi.net or HUBS and communites developing software they extensively use like OpenWRT, OLSR, or B.A.T.M.A.N..
You are a student and don’t know where to get started? Try and see what you can do together with RetroShare, a great piece of software for secure communication.
Retroshare contrasts pleasantly with other anonymous software, which is mostly designed to do just one thing. RS on the other hand includes replacements for instant messaging, mail, forums and filesharing along friends.
As part of the summer of code you can help extend the software and functionality.
RetroShare can offer 6 different topics for your GSoC project and you can choose which one does fit your interrest the most. Below are the project descriptions as they appear on the Freifunk wiki: Freifunk Ideas Page. These descriptions are just high level guidelines. A detailed roadmap will be defined between the students and their mentor during discussions of the student application period. Most of these projects require a good level of programmation skills, as the existing codebase has a significant learning curve.
1) Differential file list sharing system
Retroshare allows you to share files between friends and lists of shared files are exchanged between neighbor nodes. The current file exchange system is quite old and very unefficient. Besides, it relies on an old component of the backend (the v0.5 cache system) which should disappear. The goal of the project is to design an efficient and versatile system for sharing file lists, while keeping the existing GUI. The project needs a good understanding of the software back-end, so it is not as easy as it might look.
Things to be implemented:
- new file list storage. It should be extensible, and should at least contain information about hash (and other crypto primitives depending on how the file transfer is encrypted), access dates, amount of upload/download per file, and friend-based permissions.
- interface layer between GUI (Qt-based, where file lists are already shown as trees) and the core file lists system which holds your own shared file list and your friends’ shared file lists.
- differential file list exchange service. This should be a regular Retroshare service, with its own network transport items. It should only send/request data when shared directories change using a two-tracks request queue (one fast queue fed when the user is browsing his friends’ shared files and one slow queue used to update outdated entries). Data exchange will depend on specific user permissions.
2) Chess/Go plugin – play between GXS identities
Retroshare v0.6 offers an authenticated/encrypted/robust tunnel system to exchange data in real time between pseudo-anonymous identities over the network. This system is already used for chatting, but it has a lot of potential. At the same time Retroshare offers a plugin system that users can leverage to create new decentralised services. The Retroshare Chess/Go project has a double tap impact: creating a simple example of a portable service plugin using the new tunnel system of v0.6, and creating a cool game interface to allow users to play Chess/Go. This project includes some GUI (which will be done in Qt) for the games, and a bit of backend to handle the interface with the tunnel system. It also needs to fit in the current plugin architecture which will be adapted if needed.
Things to be implemented:
- game data exchange service and encrypted tunnel handling
- GUI for the games
- GUI for game handling
3) Video over IP in RetroShare
Retroshare currently offers the possibility to talk using Voice/Video over IP, but only as a toy system. It needs a skilled developer to implement/port a proper cross-platform video codec that would be capable of frame-rate auto-adjustment and robust to network delays. This is a challenging project that needs a good understanding of how VOIP works and interacts with the network layer.
Things to be implemented:
- find (or implement?) a good cross-plaform video codec
- handle auto-adjustment of bandwidth for video/sound with proper priority handling to avoid gaps
- proper GUI device selection and notifications
4) wall/blog plugin based on GXS latest stuff
Retroshare contains a generic distributed database system (called GXS) which allows to share data between nodes, in a way that is cryptographically secured (database access may be limited to circles of people, etc). This database system is currently used for distributing forums and channels over the network. The GXS system also offers the possibility to respond, submit comments, and vote over posts. We would like to use it to create a service that allows users to create a blog-like service, to which friend nodes subscribe so as to propagate the info over the network. Depending on the student’s skills and motivation, such a plugin could offer one of the following similar services: twitter (distributed micro-blogging), blog (distributed blogging), Wall (Facebook style information sharing).
Things to be implemented:
- plugin interface
- GUI for the Wall/Twitter/Blog service (to be defined)
- backend service, based on GXS interaction handles
5) Retroshare better Chat backend
The current Retroshare chat system is very simple: if the peer is online, it sends the messages and assume they get received on the other end. Messages are sent directly to single peer locations, so the user has to decide where a friend with multiple online locations actually is, in order to hold a proper conversation.
An improved chat protocol would send messages to all locations. It would also send a confirmation if the message arrived. It would send another confirmation if the user has read the message. This should work across all locations as well: if a users has read a chat message on one location, it would be marked as read on all other locations.
6) Retroshare single search across all services
Retroshare has many services: forums, identities, channels, file lists… Each of this service has its own search box. For the forums, every forums has its own search box. It is currently impossible to search across all subscribed forums at once, not to say across the entire set of services.
As a solution, we propose that every service has an interface where it exposes internal data in a searchable format. A search service would collect data from all services and build a search index. A single search box in the UI would query the index. All results would be displayed in a unified list.
7) Plugin to share entire directories among GXS identities
Retroshare could easily share entire directories between connected nodes. This project is different: it aims at creating a distribution service for entire directory trees based on the GXS distribution back-end. The service would create/manage entities similar to current “channels” and contain information to download and update a full directory content. This way, the same data could be shared from friend to friend among many people, according to reading rights defined by the owner. The publication/updates rights will be automatically managed by GXS (like with channels) hence ensuring security/authentication of the directory content. This means that distribution can be restricted to a certain circle of Identities and publishing rights can be shared if needed with friend nodes. Usage applications for this are easy to figure out: shared wiki, photo-albums, or any kind of website.
Please take a look on Freifunk’s ideas page and select the idea you like. If you miss any information like documentation or repositories, please ask the mentors connected to the ideas. You can contact them by e-mail firstname.lastname@example.org. We invite you to subscribe to forums or mailinglists to introduce yourself and clarify your questions.
Github/Bitbucket/Assembla etc. profile:
IRC Nick and Network:
Who are you? What’s the focus of your studies? What makes you a good candidate to work on this project? Tell us about your experiences in Free Open Source Software; What free and/or open source projects have you participated in? Describe your contributions, provide us links to your features and commits.
Availability – How many hours per week can you spend working on this? What other obligations do you have this summer?
After GSoC – Do you have plans to continue with your project within the freifunk community after GSoC?
The precise content of your project (milestones, hierarchy of tasks, etc) will be defined when discussing the details with your mentor!
Timeline and Deadlines (information coming from GSoC/Freifunk websites)
29 February 19:00 UTC – List of accepted mentoring organizations published on the Google Summer of Code 2016 site. Interested students should begin discussing project ideas with accepted mentor organizations.
29 February – 13 March – Would-be student participants discuss application ideas with mentoring organizations. Students can register and submit their applications to mentor organizations.
14 March 19:00 UTC – Student application period opens. Students can register and submit their applications to mentor organizations.
25 March 19:00 UTC – Student application deadline.
22 April 16:00 UTC – Accepted student proposals announced on the Google Summer of Code 2016 site.
Community Bonding Period – Students get to know mentors, read documentation, get up to speed to begin working on their projects.
- Accepted students in good standing receive 500 USD shortly after coding begins
- Students receive 2250 USD shortly after passing the mid-term evaluation
- Students receive 2750 USD shortly after the passing the final evaluation
And more on the official timeline.