Foundation Strategy: funding decentralised/local-first applications

Community
1

Hello GNOME Project community,

The GNOME Foundation has not been giving as much news as we wish it has, but doesn’t mean nothing happened!

In the hopes of making GNOME useful for as many people as possible and finding sustainable funding, the Foundation needs to run public programmes. Let’s examine together what makes a suitable programme, what direction the Foundation is taking, and how you can help shaping the programme and the future of the GNOME Project as an active community member.

Note: this is only one axis of the roadmap the Foundation board has been working on. A post on our 3-axis roadmap will be published later by Rob and Neil.

What Makes a Suitable Programme

The GNOME Foundation is not GNOME’s Vendor

Let’s state the obvious: the GNOME Foundation is about GNOME. It is not about “GNOMEing” blindly but about supporting the GNOME Project and making it useful for people.

Given the Foundation doesn’t sell products or services, it can only happen with targeted, planned and transparent programmes, funded by donations. Because of the very open nature of the GNOME Project, the Foundation can’t decide for one direction of the GNOME Project for everyone: to have some weight the Foundation needs to be a significant contributor to GNOME. It needs to work with the people who make GNOME and take the existing culture into account to ensure the project will benefit everyone.

This means of course before drafting a programme, the GNOME Project contributing community needs to be consulted.

The Highest Impact

The GNOME Foundation is a not-for-profit, but also (should be) a not-for-losses. It relies exclusively on donations and grants to fund its activities.

Transparency with what we intend to do and what we actually do with the money is absolutely necessary to attract donations. While we have been making progress with now monthly reports from the executive director in This Week in GNOME , we still need to improve our communication when planning and running programmes.

Individuals have been a good support to the GNOME Foundation, but most of their contributions are in the form of design and code to the GNOME Project. Organisations have more financial power than individuals. It’s easier to get a handful for organisations to agree on funding a specific programme than to convince thousands of individuals to get the same budget.

In short: the more organisations willing to support a given programme, the more ambitious, successful and sustainable the programme can be.

Finding a New Direction

The General Direction

GNOME is a good candidate to focus on empowering developers to make local-first apps: applications where the data lives on your device(s) and is shared locally, without relying on any cloud service.

Not only would this be useful for the privacy-mindful people, it would be a great help for privacy needful people too. Such people include journalists, activists, and LGBTQ+ communities especially in certain hostile regions.

This could also be useful to reduce digital waste: with no server running 24/7 just to sync the data every once in a while, you avoid the production of the server in the first place and the energy it consumes when running.

Finally, it can prove useful for people in rural areas or countries with unreliable internet access, be it a regular or exceptional situation as disasters or wars.

Such a direction takes advantage of the native apps culture of the GNOME Project, and would contribute back to it since reliable and polished applications are a pre-requisite for this to work in practice.

Focused, Scoped Programmes

While many people are excited about the concept of de-clouded, local-first computing (see for example how enthusiastic people were about Christian Hergert’s prototype Bonsai ), the most reasonable thing to do is to ask people we want to help what they need, instead of just projecting our own wishes. Let’s identify the problem instead of coming with solutions missing the point.

The first project needs to be user research: when there is no Internet available, what are the priorities for the following populations, and what would help them addressing their issues:

  • Journalists
  • Activists
  • LGBTQ+ communities members
  • The general public used to having access to the Internet
  • People who live in low connectivity areas

Beyond having a clear understanding on what problem needs to be solved, the Foundation needs the expertise of the GNOME Project contributors to have a view on how to solve these problems, grounded in the reality of the project.

Before we even conduct the user research project, I wanted to open this topic to:

  • Be transparent about what the Foundation intends to do
  • Give the GNOME Project contributors an opportunity to get their voice heard.
    • Is the orientation of the programme clear? Does it make sense to you?
    • Are low hanging fruits we haven’t thought of, that would allow us to quickly make GNOME even more useful?
    • If you were given a magic wand, how would you make GNOME a local-first platform?

Let us know what you think of it and how we can turn this idea into concrete actionable steps.

10 Likes
2

I think GNOME is already quite good at that, because of historic reasons (it was created before the “cloud” exists and before high-speed and always available internet connections that is often required to use cloud apps).

When I see “decentralized”, I directly think about git and emails, from a technical point of view. With Evolution or any other email desktop client we can fetch new emails when we have an internet connection, and send previously written emails. An internet connection is not needed in order to consult and write emails. It is “asynchronous” communication. And “power-users” who know how to use git can work without an internet connection, doing pulls and pushes to a remote server when it’s possible.

When I see “local-first apps”, I think about saving files locally and having a robust backup solution that is super simple to use for end-users (also for recovering data, of course). Again, I think GNOME is already good at that.

Of course, there is always room for improvements.

1 Like
3

I like the proposed strategy. I would like to add an additional, economic argument why the proposed localfirst + decentralized no-cloud still-being-able-to-sync strategy totally makes sense for GNOME (in my personal opinion, as someone who enjoys using GNOME, and is currently learning to build GNOME apps).

Individual community members tend to contribute code and design (not money), as stated in the above posting. But centralized services cost a lot of money to operate (server hosting etc). Even more so if a service grows popular.

A distributed nocloud p2p sync mechanism would provide a nice foundation for GNOME apps to provide cloud-like convenience without incurring hosting costs for users or service providers.

1 Like
4

The first project needs to be user research: when there is no Internet available, what are the priorities for the following populations, and what would help them addressing their issues:

Journalists
Activists
LGBTQ+ communities members
The general public used to having access to the Internet
People who live in low connectivity areas

This section seems to be a bit… “first world”? That probably isnt the best way to put it, but there is no outreach to new users, or even users from remote locations where internet may not be universal.

(or another way to look at it would be the blue ocean strategy - existing users are not all the users that could exist.)

I think with the likes of Endless these communities are also targets that should be included. Other than that, developing a story for education even in richer places could be interesting and may even get organisations who want to enter the commercial market be interested.

Another aspect of making good local-first apps is that backup/restore (whether online or other method) needs to be provided, at a lower level - probably available from initial setup, but centralised like in online-accounts. Then apps do not need to worry about saving the cloud etc.

1 Like
5

still-being-able-to-sync

Ah, in my above reply I probably forgot this, which was not well explained in my opinion in the announcement.

So, if I understand correctly:

  • Sharing personal data between our devices, if we have several.
  • Sharing data with friends, family and other people more generally. And securely.
6

Resilience

Thank you for bringing this onto topic. Local-first applications are needed. When looking at trends in Information-Technology it is a task for free software. Sebastien Wilmet’s example for a good application is also mine, “git --everything-is-local”! Or simply mail-clients like Evolution. These applications are fast, resilient and comfortable. They can work quick, reliable on local data and also provide the comfort of syncing with other computers. Focusing on certain groups of users make sense. But applications with the built-in feature of resiliency are needed by all users, everywhere on the globe.

Various Examples
In 2020 Garmin had severe outage. For a week exporting GPX-Tracks or changing settings on some devices wasn’t possible. More critical was the outage of the POS-Systems of COOP in Sweden. POS-Systems shall stop syncing, keep working locally and sync when the servers are available again. Cases of “how often will this happen” not “can this happen”. But outages affected people once a nuisance and once a problem in buying food.

We’ve also bright spots!
Flatpak allows to store applications and dependencies - with some requirements - on a USB-Drive and preserve it as backup or easy sharing with others. Also Teleport allows for local file sharing, similar to AirDrop. I would love a cross-platform version of these between BSD, Linux, MacOS and Windows.

Other topics are installation and recovery after a damage. Regularly updated installation media which allows complete installation of a basic system without external services are more resilient. Fedoras images doesn’t require internet but are usually only provided once after the release. The official images from Arch always need an internet connection. Debian and Ubuntu provided regularly updated images with current packages.

Maybe it also helps not just looking on local applications but servers and services. They often keep crucial data or functionality only on their side but usually their role should be caching and syncing clients - not making the clients dependent on them.

Thank you

7

Flatpak and dependencies on USB-Drives
Teleport (AirDrop like)

I’m not allowed to include more than two links in a post but would highlight hard work of the developers!

8

Thank you Thib. This is a nice initiative and the Board coming forward is much appreciated.

I think there’s 3 legs to this

  1. Configuration
  2. Application data
  3. User files

AFAIU Bonsai is intended as a generic transport for 1, 2, and maybe 3. Otoh there are different solutions that focus each on 1 or 3, with different levels of success and modernity. For 2, each application tends to go its own way, and these tend to be reliant on remote services (examples: Firefox sync, IMAP, Matrix, …).

It probably got lost between the lines for most, but Tracker is doing its own advances for point no. 2. RDF is a data format that lends itself very well to merging and coalescing from multiple sources, and SPARQL has capabilities for mass manipulation and transport of RDF. Putting these together, we have a mechanism for synchronizing application data, also across HTTP, or Bonsai.

Tracker is at the last step in moving big portions of RDF fast and convenient. After that (maybe, 43?) we can start work on a service that makes synchronization over local network as as easy and out-of-the-box as possible, for applications to use.

Much!

I hopefully am creating some, or doing something that is considered a net gain in this regard for the platform.

Application developers would shake off stale misconceptions about Tracker and look it with a fresh eye. They would see a library that is a very shallow wrapper to SQLite, with features that amke it more convenient and easy to use, and considerably faster than their regular “I know SQL” urge, both in performance and maintenance load. Also, a library that can make features like this to work out-of-the-box.

Application data of GNOME-y applications would migrate, application data synchronization would be handled in a single place. Users would set up their trusted network/devices once in Settings, and get transparent background synchronization whenever the right circumstances happen, without reliance on third parties or connectivity to a broader network.

Examples that would benefit of this:

  • Conversation logs (Polari, but why not Fractal)
  • Bookmarks, opened browser tabs (Web)
  • Email (e-d-s?)
  • Other sensitive information (Health)

And users would live happily, with a bigger trust in their data being neither leaked on the internet, nor left behind in another device.

Setting my feet in reality again, I am thrilled that Health does already use Tracker for its data, and hope that Polari will finish following up someday soon. But I would love to see more, that would make this scheme start to pan out :).

Cheers,
Carlos

2 Likes
9

Hi Sébastien,

You’re absolutely right, GNOME already has the right culture and foundation for it. It’s important to run programmes that fit well with our culture and strengths.

The distinction you make between decentralised and asynchronous is quite important. When writing the post above I didn’t have asynchronous communications in mind but they can make sense too.

To answer your second message, yes sharing data between one person’s devices (not necessarily all running GNOME?) or between two distinct person’s devices are both in the scope of the project. Security should definitely be a first class citizen, especially if we consider oppressed populations as one of the targets of this programme.

Thanks for contributing to the brainstorming

10

Absolutely, and there are two distinct economic aspects here:

  • Getting funding for the programme (e.g. by organisations willing to support LGBTQ+ people or journalists)
  • Not adding recurring costs for the Foundation infrastructure

This also has benefits of reducing the environmental costs.
Thanks for your contribution :slight_smile:

11

Yes, that’s an excellent argument I didn’t have in mind, thank you!

Teleport does look like a low-hanging fruit. Being compatible with mobile platforms would be lovely, though require more efforts. I guess it all depends on the funding we can get.

Yes indeed, I would love if my contacts and calendar could be shared seamlessly with my devices locally, without having to go to Big Tech’s servers. Valid points here again, thanks for your contributions to the brainstorming effort!

1 Like
12

Hey Carlos, you certainly are. Thanks for the insightful answer on Tracker and how it can help setting this up from a technical perspective. This is definitely something we will have to keep in mind when crafting a more technical strategy

13

Application developers would shake off stale misconceptions about Tracker and look it with a fresh eye. They would see a library that is a very shallow wrapper to SQLite, with features that amke it more convenient and easy to use, and considerably faster than their regular “I know SQL” urge, both in performance and maintenance load. Also, a library that can make features like this to work out-of-the-box.

Yes, and I think we should probably start making some nice example apps to show this off. I realize that tracker has had a bad rep over the years - but it is still a very viable engine and an important tool in the desktop.

Application data of GNOME-y applications would migrate, application data synchronization would be handled in a single place. Users would set up their trusted network/devices once in Settings, and get transparent background synchronization whenever the right circumstances happen, without reliance on third parties or connectivity to a broader network.

Being able to synchronize with a phone or tablet while on the local network would be something that I would love to see.

Be aware, that we need to do outreach for this kind of thing to succeed - eg we should be talking about this at Linux App Summit, GUADEC, and community conferences like SeaGL and other places. It’s imperative that if you want to do a brain trust that we put the work in of doing the outreach.

1 Like
14

Aha, you hit my weak spot :slight_smile:. I take your point, in the couple previous years there were various talks, but there’s just been silent progress lately. The ship already sailed for GUADEC/LAS this year, hopefully we’ll garner some nice showcases for next time.

2 Likes
15

Hello! Thanks for your as always cool ideas and initiatives! This makes me proud for GNOME. And this initiative really motivates me to help. I haven’t had a chance to get involved in GNOME development yet, but I’d really like to start here. Where could I help? I’m somewhat familiar with Rust and C development, and I could help with testing. I’d like help getting involved in GNOME development because I’m new here. My main contacts are email - dev@shdwchn.io and Matrix - @shdwchn10:matrix.org

Now for my thoughts on this initiative:

In a nutshell, it would be nice if we could end up with some sort of Syncthing-like technology with automatic synchronization conflicts resolution and tight integration with DE GNOME, GNOME Circle, and other community applications. With close integration of p2p-syncing technology into apps and DE, we could achieve a user-friendly and private ecosystem, even better than Apple’s. It could also contribute to the popularity of Phosh & GNOME on smartphones.

But I think as the #1 platform, GNOME could do even more:

We could make technology that would eliminate the boundaries between devices and make it almost no difference what device the user is currently using. And make that technology very modular. Then Bonsai would really shine. We could take as a basis something similar to the OSI network model:

  1. At layer one, we should have zeroconf P2P communication technology that has NAT Traversal. That way the devices can be on the Virtual Private Network and we can provide the basement for all the cool stuff that we’ll have layers above. This could either be something written from scratch, or to save time, already working libp2p/Yggdrasil, and could be inspired by the work of Syncthing and tailscale. The only thing left to do is to make the GNOME Settings & Initial setup easy to add QR codes or code phrases of other devices so that sync could start working. Also, devices in the same local network could use auto-discovery so it would require minimal action from the user. I’d love to try to make a mockup of what this could look like in the near future, if the GNOME community is interested.

  2. On the second layer:
    a) We could already have those services that the network from the first layer suffices: ssh, RDP (which is now available as a simple GUI option in GNOME 42), file sharing and remote access, synchronization of selected folders, PipeWire audio and video streaming, etc. You can also stream games via a p2p network such as Steam Remote Play. And you could also think about streaming individual windows and applications, for example via Waypipe+PipeWire. Seamless app launching from other devices could be useful.
    b) It would be cool to bring some traditionally corporate technology into the consumer world, even if partially and on a smaller scale. We could use logind, RDP, PipeWire, Wayland, sssd, LDAP and systemd-homed to have not only a collaborative remote desktop (which we already have), but also: Single Sign-On; a simple and convenient separate remote graphical login session; and a local session with settings, data and an account obtained from another device, as is possible in corporate environments with Windows or RHEL. We already have some of this in GNOME, at least as an “Enterprise Login” option, but we could go further. Imagine a family of three living in a private house. Suppose they each have a desktop/laptop and a phone. It would be handy if the son on the first floor could use his mother’s laptop to quickly open some of his documents through his account, instead of having to go upstairs to his computer. Also, it would be cool to be able to selectively sync data with other users, so the family, for example, could have a shared music library for everyone. To do this, we could create a system similar to XDG Portals: if in classic portals, we have a user-to-application permission system, then in portals for Bonsai we could have a user-to-user permission system.
    c) Network traffic optimization. For example, p2p distribution of OS updates if there is enough bandwidth. This is especially useful for local networks. For already signed or encrypted data, you could not limit yourself to only your own nodes, but use all devices in whole global network. Here it is important to have built-in upload speed limiters and traffic limiting, because the user’s network can be charged. As well as P2P transmission can have a negative impact on the battery of mobile devices.
    d) Tools to integrate with GNOME technologies, just as described in the Christian’s blog post “Introducing Bonsai”. This would give the features I’m talking about in the third paragraph.
    e) The same thing that we could do in paragraph 2d could be done by other DEs and organizations. A similar approach is already used in Flatpak: GNOME Runtime, KDE Runtime, Freedesktop Runtime, RHEL Runtime, etc. libadwaita and granite implement a similar idea.
    f) Same as the previous two paragraphs, but something basic and compatible with everything (maybe even IoT, Windows and Android!). Something like Freedesktop Flatpak Runtime, but a toolset for the Bonsai ecosystem. Perfect for something that doesn’t require DE-specific integration. You could also add a cross-platform API to communicate various simple facts to applications. Imagine that I ordered food or medicines in a delivery app on my phone and the app reports an approximate delivery time that changes periodically (traffic, cooking speed, courier speed, presence of other orders, and customer response rate). Looking at the phone to monitor delivery times can sometimes be inconvenient for the user if they are currently working on a computer. Instead, the app could tell the mobile OS about the delivery time, and the mobile OS could send that information to the computer through Bonsai. Also, through the same API, devices from smartphones to smart watches could tell each other their battery level. I think such an API would be very useful for all sorts of things.

  3. Layer 3 introduces us to the capabilities available via paragraphs 2d, 2e, and 2f:
    a) Synchronization of settings, notifications, messages (SMS, IRC, Matrix), calendars, world clocks, alarms, contacts, ToDo lists, MPRIS, ssh/gpg keys, all GNOME Keyring and more. If we can do PipeWire network streaming and integrate it, we can even route normal voice calls from the phone to the laptop! You can think of this paragraph as features already offered by {KDE,GS}Connect, EteSync, Apple, and other services/vendors. But we will have integration with GNOME, simplicity and convenience, and the p2p benefits of privacy and independence from Big Tech servers. Some of these features would be better developed with “GNOME Bonsai Runtime” - GNOME settings sync have no need to integrate with others, and some would work well with the more generic “Freedesktop Bonsai Runtime” - like notifications, calendar, contacts and other stuff.
    b) Collaboration. For example, Collabora Office, OnlyOffice, or any other applications could offer users collaboration capabilities without being tied to servers.
    c) GNOME applications could also benefit from Bonsai. Imagine Komikku, which learned to synchronize library, read chapters, and server settings between desktops and phone. We could have synchronous movie or music playback services and it would work well among different users if we had the ability to selectively sync between users that was mentioned earlier.
    d) The imaginary ecosystem we are all talking about here could give huge opportunities to third party developers and everything would be limited only by their imagination: easy for users to distribute computations on CPU, GPU and other accelerators between different machines; network RAID or Ceph-like file distribution system between user devices to keep data safe - this would have a certain overhead compared to existing solutions, but would be very simple and user friendly; and also overflowing device storage could automatically offload less used data to other users devices.
    e) Access to so much data could make tracker3 even smarter, and also give the hypothetical possibility of creating a voice assistant that would know really everything about the user, but still respect the user’s privacy. And the heavy AI computations could be distributed across devices.
    f) My phone recently broke and despite the backups, I would still have to take the time to set up a new phone (I didn’t have Google Services). If I had a smartphone with Phosh and good integration with Bonsai, I could have all my data from my phone backed up to my computer, where I have a lot of space and my phone data would definitely fit. If syncing everything at all, from the app list, to the data in them, and the settings of the phone itself, then I could spend minimal effort setting up a new phone.

And we also can’t forget the GNOME Foundation’s funding and opportunities that other large organizations and companies might be interested in:

  1. GNOME would mainly benefit from having an ecosystem where GNOME would be at its heart. There would be lots of services and features that you wouldn’t have to spend money on from the fund, because none of that would require any servers, except maybe rendezvous points for p2p (they have many names - supernodes, discovery nodes, bootstrap nodes, etc.).

  2. Red Hat, Fedora Project, Flathub, LVFS and others could greatly reduce their own costs for network traffic and the servers that deliver it. After all, as stated in paragraph 2c, updates for Flathub applications, LVFS firmware updates, Fedora updates, as well as updates to RHEL and any other Red Hat products could be streamed via P2P. I’m also sure that the technologies described could find other uses within Red Hat’s walls. For example, some networking stuff in enterprise products could be migrated to our zeroconf p2p.

  3. Purism has made great progress in convergence and has done a lot for GNOME. They have desktop, laptop, and smartphone in their current product line. What’s missing here to be completely happy? An ecosystem. A really user-friendly ecosystem for which user privacy is not an empty word.

  4. Valve could save a lot of traffic on families with multiple gaming computers or Steam Decks, but if we were crazy enough to do network traffic optimization at scale, Valve would have a CDN made with user devices, without having to spend money on a real CDN. Imagine Steam game updates spreading within an entire city, like BitTorrent. On top of that, they could move Steam Remote Play and Remote Play Together to Bonsai. Also, speed up Steam Dynamic Cloud Sync and better integrate Steam Deck with existing Linux gamers desktops. And as I understand it, Valve won’t stop with just Steam Deck and they want to at least make a portable VR headset and maybe try to make a console again. What devices Valve wouldn’t want to make in the future, they should also be interested in a shared ecosystem with synchronization.

  5. Various IoT vendors might be interested in paragraph 2f if we provide opportunities to integrate IoT devices. A private zeroconf p2p network to integrate smart home and desktops/smartphones is something many would like to see in their home, instead of the often incompatible and privacy disrupting devices that are on the market today.

  6. Blender and other programs that actively use CPUs/GPUs/etc and scale well horizontally could use p2p load sharing between machines, as suggested in paragraph 3d. Of course, this would work unless the network becomes a bottleneck, i.e. not suitable for every type of computations.

  7. There could be paid cloud sync services that would save data even if you only have one device online. With data encryption (like Syncthing Encrypted Folders) and minimized metadata footprint, we could achieve a good level of privacy and convenience for users. By the way, the GNOME Foundation could provide such a service as well - an additional source of funding is always a good thing.

  8. I don’t know how the GNOME community feels about cryptocurrencies, but we could consider this option as a very good source of funding. Both for the GNOME Foundation and others in the ecosystem.

The first generation consumer operating systems were difficult to manage, often or even always required the use of a terminal, and were unreliable. Second-generation operating systems became concerned about user experience and improved overall quality, security, and reliability. GNOME today could open and lead the era of integrated operating systems into a single ecosystem - when user devices will actually take advantage of what networking technologies can provide and finally become really smart and start communicating with each other. We’re on the doorstep of that right now. I think we should focus on usability and privacy first, but we also shouldn’t forget about functionality and capabilities. With the right groundwork, we can create a limitless ecosystem.

P.S. Sorry if this is too much of a fantasy :stuck_out_tongue:

2 Likes
16

This section seems to be a bit… “first world”? That probably isnt the best way to put it, but there is no outreach to new users, or even users from remote locations where internet may not be universal.

Could you please elaborate more on what you are sayin by “first world”? I didn’t get what you mean.

17

While I think it might be a good source of donation from the crypto nerds, I think that’s definitely going to be so controversial. Still remember the Mozilla controversy around that? I don’t want GNOME to be like that, since we already have haters unfortunately.

1 Like
18

No: cryptocurrencies are just unregulated securities, which is mostly enabling pyramid/Ponzi schemes that benefit early investors (VCs that provide seed funding and people with enough backing capital to buy and keep escalating mining rigs), using FOMO and other manipulations to get more greater fools to enter the market and provide liquidity for those early backers to cash out. On top of this, cryptocurrencies using proof of work are actively destroying the world’s ecosystem, by burning cheap electricity for the mining rigs, and creating tons of e-waste.

The idea of GNOME endorsing or even using cryptocurrencies goes against the very nature of the project, and it ought to be resisted by anybody in the community.

14 Likes
19

I have a gut feeling that disability, chronic illness, and health, in general, might fit into the list. I will just post some random thoughts instead of trying to come up with a coherent concept.

  • Tracking symptoms, medication, and other treatments can be very helpful with many conditions. I probably don’t have to explain why this is data you may not want to store in the cloud.
  • Health topics like menstruation can be taboo or at least shame-ridden. Having very easy access to information about such topics could be helpful.
  • Reaching out for help for certain conditions can be hard or even dangerous for some people. I’m mostly thinking about mental health conditions. I have very concrete ideas for something like an emotional emergency intervention app.
  • Having first-aid instructions available quickly and with as few barriers as possible might be something interesting?
  • Not related to local first, but something that bothers me a lot, so I’m adding it here: Many apps and services have a tendency to cater to healthy people to help with self-optimization. Often that does not cover the reality and needs of disabled people. Also, the perspective of those apps can be dangerously one-sided. For example, health apps that focus on weight loss without asking if the person using the app might actually have an eating disorder and wants to stay away from calory tracking of any kind. I feel like every community that can help with increasing the diversity in those areas should try to keep those things in mind.

Maybe those loose thoughts can spark some ideas :slight_smile:

4 Likes
20

Tracking symptoms, medication, and other treatments can be very helpful with many conditions. I probably don’t have to explain why this is data you may not want to store in the cloud.

Absolutely agree! These sort of data is going to be so bad if it gets into the hands of advertisers and hackers.