= Progress call: 17:00 UTC = == Agenda == * freedombox.org update with new images (James) * https://github.com/freedombox/freedombox.org/pull/47 * Raspberry Pi 2 OpenVPN setup issue - check entropy * Raspberry Pi 3 image (James) * https://github.com/freedombox/freedom-maker/pull/112 * Does freedom-maker work inside vagrant? * Plinth removal from Debian stable? (Plinth issue #893) * python-django-bootstrap-form test issue, patch available * Consider NMU if not resolved soon. * Android App (Rahul and Joseph) * setup done * design help * Diaspora bug fixes (Joseph) * Improving Plinth apps * Descriptions (see notes below) * See also https://github.com/freedombox/Plinth/issues/832 * Translation through Localization Lab (Danny) * our priorities: weblate for plinth to be completed, online content for foundation and freedombox.org * Language priorities: we have been asked to decide as a community * Languages of India could use support (most of them have 0% support) * Most of the translation efforts in India go hand inhand with implentation in India. Telugu, therefor, has the most support because speakers of that language have deployed it. Hindi should get priotity due to its population of speakers. * Chinese could use full language support (currently at 88%) * thoughts on languages of India? How high of a priority should those be? * General communications and outreach updates (Danny): * !FreedomBox.org website content (will be done next week): * Proposed Tabs: 1. What is it?, 2. Why does it matter? 3. Who needs it? 4. How can I get one? 5. About us 6. Contact 7. FAQ's * discuss with mray since he did design * Yale deployment: * the Yale Privacy Lab (an initiative within Yale Law School) is working on a deployment for Yale's campus * already some college deployments in Hyderabad and some other cities in India * Reach out to Jospeh for application and service suggestions for university campus deployments * Potential for OONI Partnership + potential integration into !FreedomBox == Notes == Discussion about usability of apps (7th July, a more recent version is with Sunil) * Template * Issue * What can be done to fix * Time required to fix * Level - Beginner / ready for implementation * Any special knowledge required * Priority * Points * 1 point * Very Small * Time - 0.5 days * 2 points * Small * Time - 1 day * 3 points * Medium * Time 2 - 3 days * 5 points * Large * Time 5 - 10 days * 8 points * Extra large * Time 15 - 30 days * Issues * Framework * Generic framework for crating a user group per application. (3 points) * Write a method for creating a user group in LDAP. * Description of the group should be entered into LDAP. * Assumption: framework for creating LDAP groups exist. * Risk: (small) framework may not allow description in a straight forward way. * Separate out the short description and app name from the current full string. (2 points). * In the new card based user interface and for other purposes such as figuring out the name of the manual page, it is good to have the generic name such as 'Bittorrent Web Client' from the name of the application such as 'Transmission'. Separate out the two strings as short_description and name for each application. * For each application create two variables instead of one. * Update the menu code to compose the menu item name from the two variables. * Test for each application that menu entry is correct. * Link to Wiki from each application (3 points) * Assumption: Short name of the application is available by splitting from current application name. * Rename all wiki pages to reflect their application name. Most wiki pages are already using application names. Only a few may need to be renamed. * Implement a button for linking to the wiki page of each application automatically. * Have a framework for providing information about mobile and desktop clients (3 points) * Framework for providing information on application links for Web, F-Droid store, Google Play Store, iOS App Store. * Handle multiple mobile applications being available for each service. * Icons for each store. * Show buttons on each application for all the above. Buttons should link to market page. * Have a framework for providing information on whether an application is anonymous (scale of 1 to 5) and is dependent on centralized (scale of 1 to 5) and is federated or not. (3 points) * Framework for providing information on application scales for anonymity, centralization and federation. * Icons for showing the above information. * Show icons on each application for all the above. * Note: get UX feedback * Set standard on how to set the scale for anonymity, federation and decentralization of applications. (5 points) * Research into anonymity, federation and decentralization and create scale of 1 to 5 or boolean value. For each level define what the application does to qualify for a particular value. * Provide examples. * Write a manual page with above information. * For all applications, provide information on anonymity, decentralization and federation. * Assumption: Framework for providing the information and showing the icons already exists. * Research each application and find out if they are anonymous, decentralized and federated. * All applications * For all applications, provide mobile application and web page information. (3 points) * Assumption: Framework for providing the information and showing the buttons already exists. * Do this for all applications that have mobile apps for web interfaces. * For each application, see what mobile and web application are available, evaluate them, and pick a recommendation (or multiple). * Syncthing * Study relay nodes and provide checkbox to enable relay node on each !FreedomBox. (3 points) * Spike on how to setup a relay node. * Check if it is a privacy violation. * Implement and test relay node setup. * Restrict use of Syncthing administration to users in group Syncthing. (2 points) * Assumption: that framework for creating a user group for an application exists. * Create a group for Syncthing using the framework. * Change access to Syncthing application for user in the group. * Test that this works with SSO. * Deluge * Enable single sign on (2 points) * Remove authentication on Deluge web interface. * Enable single sign on by reusing configuration already available as web server configuration include file. * Create a user group in LDAP called 'bittorrent'. * Restrict access to user group 'bittorrent'. * Update the manual page about the authentication mechanism * Assumption: Framework for creating LDAP user groups is available. * Improve Deluge description (1 points) * Write more about bittorent and use case for bittorent web client in UI. * Make the downloaded files available to the user easily. (? points)