Project Thoughts: Thinking of You

Thinking of You is a project that was inspired by a recent treatise on the value of handmade software. Creating and using software or any technology to help a community, even on the scale of one’s own family is very worth while and radically against corporate motives and agendas which we grow more and more accustomed to complying with in our technology mediated environment. In short, I’m all for it. The general sysreturn friend group was excited to have something similar to what the original author created. A low-friction, ephemeral, video sharing application that allowed users to send each other little snippets of their day, to show that they were thinking of them. Very sweet, and something that I thought my family could use to keep in touch when we are out and about and wanted to share a small moment with our loved ones. It’s of particular note for my family, because many of the children have disconnected from social media to some extent and casual sharing is harder to do than in years past. We have been looking for a more private, controlled, non-commercial, and unobtrusive means of keeping up with each other, but so far to no avail. Something like boopsnoop would possibly be a good fit. We all have phones, we like showing stuff to each other, we can sort out the rest later.

The Plan

The plan for development was to quickly create a client-server application relationship. Clients collect video, package them up into messages, send them to a server that then notifies other clients that they have a video available to view. The main extensions to the original project, boopsnoop, was to make the server distributable and allow for multiple backends for multiple friend/family circles to communicate in their own private networks using the same software package. So that meant including some changes to how devices authorize their communications and how available inboxes are set per user. I also wanted to extend client application support to more OS/Hardware options. The original only supported iOS, because his family only used iPhones I guess.

With that loose plan in mind we started the project a few months ago(2020-02-17), so where are we now?

Web Browser Client Issues

I started on the project with an experimental approach where the app was delivered through a web-browser and stored as a progressive web app accessible from the home screen of the smart phone. The progressive web app portion, it turns out, is pretty difficult when targeting a range of web-browsers. Safari in particular does not allow most PWA functionality, probably because Apple doesn’t want anything to interfere with their App Store monopoly. Even when the app would work, however, there were problems getting a comfortable amount of control over the functioning of the camera hardware of the phone. You could get video input into the browser but no control over any aspect of the video, like orientation, zoom, focus, etc. You just get whatever the phone will spit out by default. That limitation didn’t sit very well with me, because if there were any problems with the functioning on any device or web-browser there would be very little we could do about it other than shrug. Given these limitations, I decided to drop that approach. It seemed clear that we would need to go with a native app delivered through a beta app distribution method similar to the inspiring author’s approach.

My knowledge of mobile device development is pretty limited. I did some a few years ago, but I have not really developed anything to the point where more than the developing team could use it. In response to that friction, I decided to instead work on the communication and message sending aspect of the application.

Server-Side

Getting the communication API right was not easy at first. I went with a HTTP api as that is accessible to develop for, debug, and very flexible with client implementation. I wanted it to be as simple and intuitive to develop for as possible and have as little cruft and no over-designed elements to cause friction or confusion when working with the communication system. So I wanted as few levers and knobs exposed to the client as necessary. I think I managed to succeed with a lean 5 actions covering all the actions I wanted the server to handle, (openapi spec). Other aspects of the final phone interface would be left to the client.

• GET /manifest
  • returns target_inboxes and details to the client based on the authenticated user.
• GET /messages
  • returns the authenticated users currently available messages
• DELETE /messages
  • receives a list of messages to delete
• GET /messages/{message_id}
  • returns the message content or a redirect to the content of the target message
• POST /send/{target_inbox}
  • receives a message including attached media files

Authentication is handled via Basic Authentication over HTTPS. That’s it, a teeny tiny messaging api. Messages are persisted in a SQLite database. The expected volume and size of messages reduces the chance of running into the downsides of using sqlite. Message contents are stored in and served from digital ocean spaces. To debug and make sure that the server-side worked, I created a simple web app that implemented the basic actions of a client. No video capture, but you can upload a file for a message and download that file from a message. Users on that system are for demonstration purposes only (you can start with username&password = alice|bob|carol|dave|erin).

Client-Side

Here is where I have little to show. I need the application to run on both Android and iOS just to hit all the important people in my life, so that basically means developing two client apps. React Native and Cordova are not really options here, because they don’t really cover the problem of camera controls. They are essentially parred down browsers running on the device and so are subject to many of the same API limitations that browsers do when attempting to access media capture hardware. They also bring a lot of boilerplate and layers of abstractions, enough so that they end up being a third operating system on top of one of the two target hardware operating systems. Basically, it’s not suitable to our use case just due to the complexity involved with the tools and the aim of the project to be simple and handmade.

So I’ve got no choice but to develop two native apps to get this project off the ground. They are simple apps, with very little content within themselves to synchronize between codebases, but they are still two apps in technologies with which I have little experience. A friend with more expertise with android apps did build a proof-of-concept app before I had the server available. I haven’t checked in with them about integrating with the now working test server. For the iOS application, I purchased a (used) Mac Mini back in March with the hope that I could use it to build and sign iOS apps. I have yet to do much with it however.

Next Steps

When I have the motivation, which sometimes comes from surprising places, I plan to dig into iOS development and hack together an that communicates with the server. After that, maybe I’ll get help with the android app, or I’ll get on to that myself.

There are some up-coming challenges that I will need to address after client apps are working.

• Client Builds and Distribution
  • Actually getting the app and updates to users will still require a “beta testing” distribution system. I expect that to be a bit of a project by itself.
• End-to-End message encryption using a hybrid cryptosystem
  • This way message contents are always encrypted when not on the sender’s or receiver’s device.
  • hybrid encryption is needed so that users can decrypt a message addressed to them even if the message was sent to a group address.
  • Feasible because of the control over the key distribution in this limited user environment.
• Multi-tenancy and/or simple installation process
  • A way for other friends/families to install and distribute their own version of the application.