Resilience brainstorming

Ideas/inspiration for potential projects, features, and initiatives to move GNOME towards being more resilient. Largely taken from this blog post.

Local-first

• Investigate existing local-first libraries, if/how they could be integrated into our stack, or if we’d need to roll our own
• Prototype local-first sync in some real-world apps
• Investigate how local-first would go together with USB fallback
• Implement USB app installation and updates in GNOME Software
• Investigate integration of offline content providers such as Kolibri
• Investigate much more aggressive caching, e.g. of websites

Relevant art for local-first tech:

• automerge, a library for building local-first software
• Fullscreen, a web-based whiteboard app which allows saving to a custom file format that includes history and editing permissions
• Magic Wormhole, a system to send files directly between computers without any servers
• Earthstar, a local-first sync system with USB support
• p2panda, a protocol for local-first apps with Rust bindings
• Secure Scuttlebutt, a local-first decentralized social network

Resource Efficiency

• Explore ways to make power profiling easy for system and app developers
• Improve power efficiency across the stack
• Explore a system API to tell apps whether now is a good time to use lots of power or not
• Improve the developer story for GTK on Windows and macOS, to allow more people to choose it over Electron

Data Resilience

• Explore new ways to do content apps with the file system as a backend
• Look at where we’re using custom formats in our apps, and consider switching to standard ones
• Consider how this fits in with local-first syncing
• Store user data on the file system, Tracker integration?
• Well-supported workflows for constrained disk space cases (e.g. allow storing apps and SDKs on external drives)

Keep Old Hardware Running

• Actively try to ensure older hardware keeps working with new versions of our software (and ideally getting faster with time rather than slower thanks to ongoing performance work)
• Dogfooding program with older devices for developers
• Explore initiatives to do strategic hardware eneblament for some of the most common mobile devices (including iPhones, potentially?)
• Forge alliances with the infosec/Android modding community and build convenient offline bootloader unlocking tools
• Discuss how far back we can/want to support our software realistically (are computers from 2012 viable? 2008? 2004?)

Build for Repair

• Avoid using obscure languages and technologies for new projects
• Avoid overly complex and brittle dependency trees
• Investigate UX for a local-first software repair flow
• Revive or replace the Devhelp offline documentation app
• Look into ways to make useful online resources (tutorials, technical blog posts, Stackoverflow threads, etc.) usable offline