'Digital pantry' - dApp idea suited for Holochain?

hApps New Projects
#1

Hello,

I want to make a dapp (primarily android) and was browsing around for the ‘right ecosystem’ (whatever that may be) for my back-end logic.
I think holochain a very nice initiative but I’m wondering if it would be suited for my goals.

Maybe an overview of my idea, divided in standalone and sharing.

With standalone I mean the core idea of my app, which could run on any smartphone without even internet or authentication.
The goal is a ‘digital pantry’. With this app you would scan food products you buy and set the expiration date.
Before the products expire you get a reminder.
For extra information on a food product I would use Open Food Facts.
For all this functionality I wouldn’t need any storage other than the phone’s and no authentication etc.

Then about sharing.
To make this app more usefull, I would like to add 3 things:

  • That a user can use multiple phones (why, I wouldn’t know - but I’ll try to write as device agnostic as possible by using React native so it might also become as easily as possible a web app)
  • Groups: That multiple user’s can share one pantry (and maybe shopping list) and add/delete products.
  • The ability to add/remove products offline and sync them when coming back online

I don’t want to do that in a centralized way with the need to set up my own server and authentication for users.

The first decentralized dapp ecosystem I encountered was Blockstack and I think I have a pretty good idea about how I would proceed with them, because they arrange:

  • (decentralized) authentication/identity (so I don’t have to worry about that)
  • decentralized storage (every user/identity can choose where he/she runs his/her own pod, like self hosted or on google drive - everything stored to this pod is encrypted)

To add the group functionality, I would do something like granting other users access to the datapod of the ‘pantry owner’ or using the pod of the user itself and just aggregating the data of all group members in one view.

One big disadvantage: Blockstack is anchored to bitcoin (although they can migrate) and I don’t like bitcoin’s energy stats.

Then I discovered Holochain!

But after taking quite some time going through the docs, I’m not sure if my project is suited to run on Holochain.

My question to you guys is if it would make sense to use Holochain as my back-end and how (very broadly).
I stated what I understand from the docs, but everything with a question mark may be confirmed that I’m understanding it correctly.

  • For the authentication I would have to read more on ‘Personas & Profiles’, I guess.
  • For the ‘decentralized’ storage, however, I’m not sure how I would do this with Holochain.
    First of all, everything put on the source chain would be there ‘eternally’, right? Or at least it’s header (?).
    So my food product which was eaten 2 years ago still is there, although it is marked deleted (thus the header will be there, but can the entry’s content be thrown away?)

Then: if I would proceed along this path, according to my understanding, every pantry would need its own DNA and DHT, since every agent who joins a certain network can read all public entry’s.
Thus I would need one network per pantry (?) and this translates into one DHT per pantry (?) and a different DNA per pantry (??? - still to figure out if proceding with Holochain).

Disclaimer: This is just a hobby project.

Greetings and already a big thanks for any feedback,
Th1j5

PS: new users are allowed only two links, but you can ‘google’ Open Food Facts or Blockstack if interested in more details.

2 Likes
Asynchronous messaging, small groups and encryption
Asynchronous messaging, small groups and encryption
#2

I was under the impression that it’s possible to have multiple DHTs associated with one DNA. That said, I’m not all that experienced yet, so I have no idea how this is achieved. I’ll poke around the docs to see I can prove myself right/wrong.

1 Like
#3

Well from my intermittent reading, I’m currently under the impression that you’re right in stating that you’d need one DNA per pantry in order to protect privacy.

I’m now wondering how DNA management is supposed to work at a higher level. I know it’s possible to develop your zomes such that they use properties declared externally in dna.json, such as a member list. Perhaps there’s a way for an hApp to manage multiple DNAs, such that could add new DNAs on the fly when you wanted create new private groups.

It’d be a great if a more experienced hDev could chime in here!

1 Like
#4

I think I’ve found it:

1 Like
#5

Joss, thank you for the clarification around the use of DNA’s!!
Once I’m totally sure holochain is the way to go I’ll dive more in de code myself, but for now I have a few more design questions (besides the old ones) for the community, mainly again about data immutability and storage.

This sentence:

  • For large objects that have a short life, consider storing data outside of the DHT in separate, short-lived DHTs, IPFS, Dat, a data store on the user’s machine, or even a centralized service.)

from CRUD operations suggests to me that to claim back some space in a pantry (let’s say after 2 years of adding & deleting products), I would just start a new DHT and remove/obsolete/… the old one.

Would that be the preferred way to go or would this make the use of Holochain useless?

Second concern:

Most of the time I imagine a pantry (and DHT) is shared between members of the same household, so let’s say 4 agents.
I think we may assume that they will frequently not be connected to each other (not connected to the internet at the same time).
If 1 person updates the pantry (add’s a few products & deletes a few), these changes would have to spread to the others.
In this situation where not many agents are online at the same time, it would provide benificial to have some always-on agent (basically a server :confused: )

If we compare this again with the Gaia storage system (from Blockstack), we see they use encrypted storage, accessed by a Gaia Hub.
This is decentralised in the sense that this Hub provider can be choosen by the user or self hosted.

If I translate this back to Holochain,

  • the self hosted solution would be a headless agent participating in the DHT and
  • the solution where you choose a provider would be paying someone to host a headless agent participating in your DHT.

My questions are:

  • would a headless agent be very different in development? I think I understand the DNA will have to be the same, but the environment in/on which this runs would be different… (for example a Raspberry Pi and not a phone).
  • is it even possible in Holochain to store your data safely (not readable) with non-trusted agents?

All feedback is greatly appreciated!!
(and sorry for the long posts :slight_smile:)

EDIT: I might have overlooked some posts like Throwaway DHT and linked posts when writing this, I’ll read them now, but I think the second concern still stands.

#6

Tbh, I’m not experienced enough to answer those questions. I get the impression this thread is being overlooked by the more experienced members, so I wonder if you might get better engagement if you were to start a new thread that’s narrowly framed on a technical question, rather than broadly in the context of an hApp idea.

Anyway, possibly useful to note:

  • I’m under the impression that RedGrid are using holochain in a headless manner.

  • The HoloPort network is a related project that exists, in think part for dealing with the issue of downtime, but I think mainly for providing regular web browser access to those who aren’t setup with a conductor. You might be interested in watching Virtual Hackalong Session 13, which took the form of a Q&A with one of the project’s devs.

#7

Hey there @th1j5 and @joss . I’m sad I missed this thread, because it’s the very thing I love talking about. The both of you are correct in pretty much all of your assumptions that I’ve read so far. Let’s see if I can summarise the conversation to see if I’ve got things straight.

  • P2P/DWeb is attractive because of privacy, offline-friendliness, and no need for you the developer to maintain a server
  • Blockstack is attractive because it’s got a turnkey stack, but it’s tied to a PoW blockchain
  • Each pantry can have multiple participants, but they should be authenticated to access that pantry (either because they belong to the creator’s 1 or more device(s) or because they’ve been invited by the creator or another participant)
  • You’re concerned about slowly expanding storage because Holochain uses append-only storage
  • One network/DNA/DHT per pantry, but not sure how that is done (maybe something to do with app.json and having the app manage creation/destruction of those)
  • Authentication has to be in the hands of the creator of the pantry
  • Concern about whether it’s an anti-pattern to garbage-collect by throwing out the old DHT and creating a new one
  • There’s also a concern about resilience and availability, because people would pop in and out of the DHT at random.
    • Headless node – would it work differently from ‘human’ nodes?
    • Third-party-hosted headless node – what are the security concerns?

Okay, here’s some of my thoughts…

  • Bang-on with all the stuff talked about so far. I think Holochain would be an ideal use case for both privacy and resilience; the only concern I have right now is that it’s not proven on cell phones. Besides the fact that we haven’t yet started officially supporting compilation on Android, there’s the question of how to make a device a persistent participant in the DHT – both the Android and iOS app stores frown on background services that eat battery and network. And for now, you would likely need some sort of background service in order to stay ‘live’ on the DHT and hold it in existence.

  • Re: stale data and garbage collection, pretty much all decentralised tech (except IPFS) works the same way: append-only journals; if you want to delete something, you mark it as deleted and content yourself with the fact that the data is still visible and taking up space. Sub-thoughts:

    • The kind of data you’re talking about is so light that you could probably store a whole family’s pantry data at 100% redundancy for a decade and still not take up the space of a single JPEG photo.
    • If you wanted to start storing heavy data, like a photo of the barcode and expiry date, you might want to keep that on a separate DHT and periodically garbage collect in the way you described.
    • We’re planning for two new DHT operations in an upcoming version of Holochain: withdraw (for when you want people to delete stuff, either because it was a mistake or because it’s no longer necessary), and purge (same as withdraw, but with more seriousness – like when you discover illegal content). At that point you’d be able to use withdraw to clean up junk data.

  • Resilience of a DHT’s data is something I’ve thought about a lot too. With small DHTs, like a family, there’s a fair chance that, even when you’re online, you’re as good as offline because all your family members are offline. Family DHTs make for great data sovereignty, but bad user experience. You have two options, both of which have been identified already:

    • Set up a small node on a RaspberryPi
    • Hire some space on a HoloPort via the Holo hosting network

    (or you could buy your own HoloPort Nano, which essentially is a RaspberryPi-like machine with pre-installed software, and host the app yourself and don’t charge yourself any hosting fees). The headless instance will have a copy of the DNA, but because there’s no UI to boss it around, the only thing it does is respond to requests to validate and store data for the family. No special programming needed.

  • The third-party-hosted option of course brings up privacy concerns. FWIU data is encrypted at rest on the Holo hosts, so that it can only be accessed when it’s in-memory, but the host needs to decrypt the data in order to validate it and serve it to other nodes, which means the owner of the host has the private key. You have some options:

    • Trust the host’s owner – they’re bound by contract to respect your data. May or may not be palatable to you, depending on your comfort level. Perhaps you’re embarrassed by the amount Cheez-Whiz you buy in a given month :smiley:
    • Encrypt public data – this could be fine for simple data like shopping list items, but the authentication data will need to be read by all nodes in order to keep unauthorised people out.

  • Spawning a new DNA/DHT based on existing rules is easy. When you install a DNA into the conductor (the runtime that runs Holochain DNAs) you have the option of passing extra data in, which changes the DNA’s hash and creates a new private network/DHT. This data could be some random bytes, or it could be a name (“Thijs’ family pantry”, although you’ve got to watch out for collisions there with other people creating the same name), or it could be the initial authentication data that sets up the Progenitor of the new space (that is, the public key of the agent who initially has full and exclusive rights to create entries that authenticate other agents’ public keys to join). This can be done by the admin services API, which is just a JSON-RPC-over-HTTP API that lets the UI control the conductor to install/remove/start/stop DNAs, UIs, agents, etc. You can see it at work in a couple hApps, including Acorn.

5 Likes
#8

@pauldaoust and @joss, thank you both for the feedback!

@pauldaoust, I think you’re summary is also bang-on :wink:.

I think I’ll just dive into the Holochain tutorials and learn by doing.
I’ll also have a look at _Prtcl, found by following @joss’ link.
The reason I thought Holochain is also ready for Android is because of the ‘building for android’ instructions on the Holochain developer site, but it looks like I might be wrong?

I’ll see how things turn out, thinks some more about all feedback and post here when I could use some comments.

Thanks!!

#9

I hve to apologise and say that it’s been a looooooong time since we’ve touched that documentation and tried the Android build. If anything, it should’ve gotten easier because we’ve dropped some of the more troublesome dependencies (like Qt5), but the fact is that nobody’s tested it recently. My personal concern about long-running processes and app store approval still stands, but there may be ways around that. Not sure yet.

Hard to go wrong looking at _prtcl or any of @guillemcordoba’s stuff. Also check out https://github.com/holochain-open-dev/ ; there’s a lot of high quality stuff going on there, from Guillem and others.

2 Likes
#10

@pauldaoust typical reply i always expect from you - detailed as always! Hope you saw my latest qns on the security thread and could advice on it soon. :slight_smile:

1 Like