Holochain Forum

Dinner Carousel - facilitating community dinners

Here is an idea I did a reasonably detailed write-up of a while back. I haven’t had any time whatsoever to make anything of it but maybe just maybe posting it here will put something in motion. This is pretty old and I am sure there is some questionable design thinking in there and I would love it if somebody rolled a totally different directions with this so I hope it can serve more as inspiration than something to get attached to.

Anyway, here it goes:


The main purpose of this app is to facilitate community dinners. It is meant to make the process of joining, organizing and structuring community dinners where poeple host each other in their own homes, frictionless and super easy to do.

Creating dinners for each other and conversations around dinner tables are a great way of strenghtening social bonds and getting to know people. Cooking larger but less frequent meals also free up lots of time (and is often cheaper!) So let’s eat together!

I first started drawing a design in my journal which looked like this (I called it DinnerBingo at the time):

The basic outline is that a user can set a bunch of preferenses, create groups and add dates when the person is available.

Whenever a person adds dates, those are added as tentative dates to all groups one is a member of and when a group has reached a minimum amount of guests for a date, a request for attendance is sent to all those tentatives.

If enough agree, then a dinner date is set and a host is chosen by the app (based on who has been hosting the fewest times before).

Here is an initial idea about how to structure the zomes, entries and functions needed from a Holochain perspective.

Zome: dinnerGuest

The basic characteristics and functionality of a user of the system.

food_needs [allergies, diet, strong dislikes]
family [kids, partner, linkToOtherUser]
accepted_dinner_start_time [00.00-23.59]
hosting_adress [StreetAdress, GPS]
min/max_group_size [3-20]
recommended_recipies [good food…]
hosting_meter* [timesHosted - timesGuest] //This should be actually calculated, see below…
in_groups [list of dinner groups joined] //just links I guess
available_on_date [list of dates where available]

*HostingMeter is perhaps just implemented as a count of linked dinners where:
(time < today & host==no) - (time < today & host==yes)

set_food_needs() - setting all food needs variables
set_family() - declaring family to toggle at dates
set_accepted_time() -setting what times dinners work, used to match/filter
add/remove_recipie() - add recipie that is available in groups “recipiebooks”
add/remove_dates() - adding a date when guest is available for hosting/joining dinner
join/leave_group() - joining a group, groups are where guests are combined into dinners
accept/decline_dinner_invite - when a match is made, guests are invited to a selected host and they can accept or decline
cancel_dinner - if guest/host needs to cancel dinner. If host cancels, that could propt other dinner guests to be host, else cancel and notify all guests

Zome: dinnerGroup

Basic functionality around groups, through which users are matched into dinners


geo_location_center [Adress, GPS] - setting a group center point to enable users to find dinners close-enough by
max_distance [km/miles] - how far from center are guests/hosts allowed to be
invite_only [yes/no] - if group is public or only available on invite
topic_oriented [suggested topics] - possibility of making groups that are focused on conversations around certain topics like, politics, travel, gender roles, or whatever, sets an intention about starting group conversations at dinner on topic
inexpensive_and_simple_dinners [yes/no] - a possible option for people who want to make sure that hosting remains easy and without prestige
BYOD [yes/no] - bring your own drinks
allow_kids_or_pets [kids, pets] - allowing for kids and pets to come to dinners in the group
pot_luck_dinners [yes/no] - in this group dinners are not prepared soly by host but are a combination of whatever food guests bring

dinner [date/time, host, guest_list, accepted] - a dinner event, first sent out as tentative, then changed to accepted


create/delete_tentative_dinner() - triggered when enough people in group have set the same date, sends out invitations (including host location)
create_accepted_dinner() - triggered when enough people accepted invitation

Additional design considerations

Around the concept of dinnerGroups I am not sure how to handle these entries as they are not agents but a sectioning off of agents in the system. I suppose that a way to handle this is to handle them the same way that groups will be handled in HoloChat. There groups are handled as seperate applications if I understand it correctly where specifics of the group is set in the app dna. Not knowing how to do this I set it up as a seperate Zome with functions.

One thing that could be added is to have a “familiarity slider” which tries to match people with other people they know or do not know based on previous dinners, social connections (bridging with other apps) and preferred setting on the slider.

Another addition could be a “happy to Host” setting that up-regulate how often people that like to host, get to host dinners.

So long as user location and group center location is available as GPS (long, lat) coordinates, math-calculations can determine if user is within accepted range of group.

UX flow

From the users perspective the app would prompt the user on first install to fill in personal preferenses and settings.

The main interaction surfaces would be:

  • a user settings page including “join group” and “create new group” buttons
  • a view for adding dates (a calendar that also includes accepted and tentative dinners)
  • a dialog for accepting invitations for dinners
  • a dinner details view showing: date/time, host location, food needs of guests, number of guests, extra kids/pets, Pot Luck (y/n), BYOD (y/n), Inexpensive (y/n), Dinner theme topics: … and “cancel dinner” button for unforseen events.
  • a group settings page

This looks great and could also hook into the OASIS API in Our World so they can gain karma for hosting a meal and also gain karma for attending but not as much as hosting… :grin::pray::sparkling_heart:

1 Like

@ViktorZaunders, check out Cotfoo. They’re an organisation based in Central India, and are keen on using our Reputation Interchange to facilitate such interactions. Happy to connect you with them.


Thanks @dellams and @sidsthalekar

I don’t think I will have time to build this anytime soon, so I don’t think I should be initiating lots of integration conversations around this just yet. Hoping sometime or someone else would run with it :slight_smile:

Yeah, this idea came out of me and a friend talking about building something like this just on a spread sheet because it would be nice to have a sort of rolling dinner thing going but it just didn’t seem to happen.

The integration that would seem most important for me would be to some kind of general contacts list. Not sure if I’ve seen anybody actually talk about building that. Just a basic implementation of your “social graph” so that you can check that address book of yours against all the applications you are installing, a kind of “who else is here?”.

This feels such a core application but I am not sure if this is included right now in what the hAppy team are building? @maackle? Rolodex kinda thing? On SSB that is the foundation of the network but here since we’re all working within application membranes I guess it has to be a simple seperate application?

Also chat functionality integration to have conversation and notification around change of events happening would be super useful

Yes i am building all that as part of Our World so these components can be shared and gifted forward when they are done… :grin:


@ViktorZaunders I love this idea! I’m definitely familiar with the advantages of cooking bigger meals less often. And I’d love to explore doing that in a community context; I don’t have nearly enough acquaintances in town :sweat_smile:

Re: your question about how to implement groups, it really depends on what you need to optimise for:

  • Privacy: groups should be separate DHTs. The conductor admin function create_from_template can be called by the UI to spin up a new private DNA based on an existing DNA template.
  • Discoverability: Just have the group as a public DHT entry. It feels like these groups should be managed by humans, so the first person to create that group entry could be the author administrator, and they could grant/restrict edit/delete privileges, which would be enforced by validation rules.

I think you called it - the Social graph will be key. I’d be interested in brainstorming the reputation design for such an app. As opposed to absolute reputation scores; relative and contextual scores would work beautifully. Also, being able to import reputations from other applications could further boost interactions.

1 Like

@ViktorZaunders - I love this, and would love to go over it with you in Prague at the hackathon in a couple weeks!


Hey @bear, sure thing! Looking forward to it. Would love to help spin up a lot of those devdinners with this thing too :slight_smile:

1 Like

Bridging with other apps is super interesting. Importing reputations (and therefore contexts) are key for engaging with others in an agent-centric model. (Can share more if its of interest)

1 Like