Helping families achieve privacy

Published: April 13, 2019

Ohana

An open source software project to create a closed social network for families.

The td;lr origin story

I've been asked a few times why I build Ohana the way I did, it was because I was inspired. I grew up with IRC using different clients to connect to IRC servers, it was nice because I could use what I wanted to chat with friends on the internet. We're also living in a time that Privacy is becoming more important to users, we're not wanting our data to be hacked; Now, it seems more and more often people wish they could control their data. I also have some family that are anti-social media because of privacy reasons, of which some don't even have a smartphone, and some family which will share every part of their existence publically. I wanted a place that we could all communicate and share openly and help mitigate the 50+ person email chains around the holidays.

That said, there are plenty of pain points in building a Single Page Application compared to a traditional Server Side Rendered app. I think the trickiest part, will be getting everything to run smoothly for a user to spin up a server and handling configuration. Currently, you need some programming knowledge to work on the configuration and my goal for the next iteration is to make it simple enough for a non-technical user to use a graphical interface to make edits.

Ok, so what's the architecture look like?

It's a distributed application split between kaiaulu, the front-end client, and hale, the backend server which can be hosted anywhere. This allows any number users to connect to a server (though you'll have to eventually scale up hardware) that is for a specific family, meaning there is less surface for malicious actors. You have kaiaulu which is a React/Redux build and hale is a Rails API app. I think the biggest advantage is that the server is hosted somewhere not under the control of a company to directly manage the application. It could be hosted at a Big Cloud service, a co-location service, in your garage, or anywhere else you can imagine.

Tell me more about the authentication and authorization

The first user initializes the family by creating one with the first account after the initial server is spun up. Currently, a user can take a docker instance and spin up hale where ever they want. They'll get that endpoint and use it within their initial signup/sign in process which is stored in Redux and Local Storage.

It's pretty simple for user signups, you can select a family from a list that is on an unprotected route, then you send your registration request which is then authorized. If you're creating a new family, that happens during your registration. Currently, on the roadmap, there will be the ability for users to invite people to the platform via tokens in emails.

So, is this just for a single family per server?

No, it was built from the start that there could be n families on a server; However, there is the concept of a "Family Member" which allows a single user to be apart of n number of families allowing them to see everything. There is a concept of horizontal sharing for some types of data, like recipes for example. This works off the assumption that the individual that runs the server is related to each family instance, so there is some kind of family bond.

Some Items on the Roadmap

Recipes and Events

One solution I'm solving for is coordinating family events but also storing artifacts like recipes; Eventually, storing other types of media like photos, genealogy documentation, digitized family history heirlooms. Currently, hale has

Communicating solutions

Documentation for developers and users is a big project because both are needed and have to be expressed in a way that can be understood, with enough specificity, to lead to a solution. Also, in an ideal deployment, most users shouldn't be developers meaning that technical concepts have to be explained clearly.

Some Conclusions

What were the fun parts to build for each product?

hale

The registration process or polymorphic models were probably more satisfying and challenging.

kaiaulu

I would definitely say that the Emoji bar was one of the more fun and lighthearted components. I designed hale to only keep one emoji attached to a model (i.e. Post, Comment, and etc.) which made it easier to maintain state. I would also say that the components which were used all over were fun to build because of the extra edge cases.

What was my biggest takeaway while building this project, so far?

I would say part of the reason, I built the application in the way I did was based on the opinions of others without validating and researching their forceful suggestions. I would say the next time around, I'll be more skeptical of suggestions and take them with a grain of salt.

Why name it Ohana?

Stich of Lilo and Stich said it best, "Ohana means family and family means nobody gets left behind or forgotten." So, yes, the software suite is named after a Disney movie quote. So, if you or know someone who works for Disney Intelectual Property, send them this article. It'd be cool to use Stich as our mascot. As for the product names, 'hale' means 'house', since everything is being processed within the server; 'kaiaulu' means 'community' since the front-end application is where everything visually occurs.

hale github: https://github.com/OhanaOSS/hale kaiaulu github: https://github.com/OhanaOSS/kaiaulu