Resilience brainstorming

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

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

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

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)

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?)

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

Edited Jan 04, 2023 by Tobias Bernard