Support for owning the data (complete privacy)

Feature Request
1

I like this tool a lot. Hence, asking for the support for completly owning the data.

Cause, I like this tool, I want to use it for the things which I would like to keep private.

Which makes me ask for if there is a way to complete owning the privacy then trusting Pirijan (not that I have any reasons to make any claims of failed privacy so far).

I would be happy if there is any path which can be taken which would result in complete privacy.

  • End to end encryption. Or
  • Users bring their own database. Or
  • Self hosting solutions. Or
  • A desktop app which stores the files locally.

I understand each solutions has its complexities and downsides-- but given that this product in itself is a statement that out of the boxes things can be made, it’s time it takes next orbit jump.

Thanks,
A user who is in love with this product.

2 Likes
2

Hey chhabra,

Thanks for your thoughts. There are a couple complexities to consider, the main one being collaboration and share-ability. These features don’t really work with private data or e2e.

The other consideration is that the significant complexity to build a whole alternate storage system won’t benefit the comparably few ppl who have the technical ability to use the system.

I know from my time at trello/stack, that offering self-hosting comes with it a lot of work and technical support, so much so that self-hosting usually = big money enterprise version.

If you use kinopio without signing up, your data only lives in your browsers local storage. But that space is limited and you’ll still have the card limit.

Def open to suggestions or pointing me to other app examples with multiple data sources

1 Like
3

Thanks @pirijan, for the response and sharing the complexities with each solutions.

I guess there is not going to be any trivial solution for these requirements.

So, my mind reaches to “makedo” solutions. Just stating a few of them.

  1. There are two kinds of spaces. E2E and not-e2e. Users can only share the ones which are later. And if someone wants to share E2E, they would have to lose the E2E first and only then can share.

  2. Like the above solution-- desktop app lets either store your files locally and/or in Kinopio server. The later is needed for collaborating with others. And for the first choice, users can use file sync solutions like dropbox, google drive to sync their changes from multiple clients. Many note sharing app allows this.

I feel like whatever solution you end up choosing, it won’t be for everyone. So, (maybe) the best way could be keep the things as for the users who don’t want e2e (or local file handling), and for the users who want it, you give them an option. It’s ok, if that option needs them to do some work.

3 Likes
4

that makes sense, in the (farther) future being able to switch a space to e2e/not-sharable would be cool.

The downside of e2e is it still requires trust in the kinopio service, which might not count as ‘owning the data’ to some people.

another approach is local filesystem (using this api if it’s any good irl https://developer.mozilla.org/en-US/docs/Web/API/File_System_Access_API) or moving from localstorage to indexdb (assuming it’s more stable and that ppl count that as owning the data). The local filesystem approach wouldn’t let you access your data on your other devices though.

re syncing to dropbox/google-drive, this sounds like the opposite of ‘owning the data’ to me though. Unless you mean that the user sets up dropbox etc. themselves outside of the app on their local files. But you still wouldn’t be able to access your data on mobile this way.

2 Likes