Sinookas is a private content-delivery platform you host yourself that unlocks the GPS-potential of your mobile devices without having to trust or depend on third-party services. It's a two-part system, an open-source web interface and a commercial mobile application, that allows you to replicate and customize common tasks, both single- and multi-user, found in many of today's popular apps, including but not-by-any-means limited to:
- Messengers
- Geocaching
- Shopping lists
- Daily Planners
- Tour guides
- Map services
- Trackers
Sinookas takes advantage of the fact that many content-driven applications are very similar from a functional perspective. The major differences are things like how content is viewed, who can create content, how are pieces of content related, and in many cases simply what content is called. In other words, they are rehashed and repackaged ideas.
Sinookas abstracts these differences away giving you the control to create your own services and customize the behavior, look, and feel of your mobile device via a browser interface. It is flexible and highly configurable, but it's only as complicated as you want it to be. There are increasing levels of involvement from running a turn-key application that you never think about or touch all the way on down to manually extending the platform programmatically. See below for more details.
Because the backend is open-source, you can host an instance yourself anywhere you'd like. Connections to your server or any other Sinookas provider are direct, so nothing is ever routed through a central server, meaning you control and own your own data. Under certain configurations, an internet connection isn't even required.
This is a service that I've wanted to exist for a few years, so I've finally decided to do it myself.
Anyway, I hope you're as excited as I am and thanks for reading this far!
Back to the top
I've already been working on the project for 3 months, so a lot of progress has been made. Other than slight tweaks here-and-there, the web interface/backend is complete. I've built a quick prototype for Android™ to test the content creation and retrieval mechanisms so I know I can deliver Sinookas in a realistic time frame.
I've paid for hosting, domains, and TLS/SSL certificates, so the $5,041 goal will cover the cost of the bare minimum viable product, primarily going towards development time and covering the following:
- Shipping the Sinookas platform, both the web and Android applications
- Increasing test coverage to 90-95% (currently at 67% for the web application and ~40% for the mobile application)
- Writing setup and usage instructions
- Creating video tutorials
- Finishing the developer documentation
- Seeking legal counsel
Because so much more can be done to improve Sinookas, the perks are arranged in a modular way giving you influence over the direction the platform will take once the first stage is complete. Think of them as a voting system.
These are what I am putting the highest priority on, in no particular order:
- Creating a Windows Phone app
- Creating an iOS app
- Building an "installer"
Lower-priority features I would like to implement eventually:
- Subscription/payment hooks so you have the option to earn money with a service you create
- Sign in to multiple services from multiple hosts simultaneously
- Integrate content with a publicly facing web view
Each of these features and goals have a corresponding $1 perk that behaves simply as a vote and a more expensive perk that unconditionally determines the next phases Sinookas will take. The upper-tier perks will be honored in a first-come basis and will trump the voting system. However I believe strongly in listening to users' requests and will otherwise prioritize further development according to the voting results. (One exception is the iOS app which will only be honored if the cost of an OSx computer is covered).
Other things I'm considering doing if enough interest is expressed:
- Creating a Wordpress plugin
- Porting the backend to Ruby on Rails
Should the project not reach its goal, I will still finish the project because this is something I want to use, but I can't guarantee when it will be launched. And of course I will keep any backers updated on progress being made.
Back to the top
Sinookas is important for those who are concerned about privacy and wish to minimize their digital footprint without sacrificing the advantages technology brings. At such an early stage in the globalized, interconnected era, it's difficult, if not impossible, to predict what effect such open and easy access to our personal data will have. There's often a trade-off between protecting ourselves and our data and taking advantage of the tools and services that pop up so quickly in this age.
On one hand, keeping up with the terms and service (TOS) of one application as it changes is difficult enough. Keeping up with the terms and services of all your applications (Web, mobile, desktop, wearable, vehicular, etc) with all their affiliated legal documents approaches on the impossible.
On the other hand and regardless of TOS, sites get hacked. People get doxxed. Information is leaked. These things aren't necessarily malicious, but accidents happen.
Sinookas makes it so you don't have to choose between privacy/security and technology. The only person you have to trust to keep your information and your family's information safe is yourself--well, and maybe your web host depending on how you set things up.
Back to the top
While it's great for all the security-minded reasons above, it's not all doom-and-gloom! In fact Sinookas originated as the engine of a kid's book I'm writing.
Aside from plenty of single-user tasks, it's also intended for multiple users: think private services for you and your friends or colleagues what you might not want the rest of the world to see ;-)
Be creative. There's lots of ways you can make Sinookas stupid and/or fun :)
Back to the top
Because of the nature of Sinookas, there is nothing really groundbreaking about its functionality, so the technological hurdles are minimal. It's not a matter of whether these things are possible, it's a matter of when they will be finished. And as I mentioned above, I've already finished the backend and started on the mobile app. So conservatively, I'm confident I can release Sinookas by May. In a worse case scenario with unforeseen difficulties, I would release a beta version to the backers at that time.
I've never developed for Windows Phone or iOS. To be honest I've never even programmed in C# or Objective-C--the languages required by those platforms, respectively. So there will be a bit of overhead as I port Sinookas to those operating systems. For those of you with no programming experience, that's not nearly as problematic as it sounds. It's common to have to switch to new languages for different projects. (As a comparison, the first time I ever tried developing for Android, I was able to turn my phone into audio controls for my PC in about 6 hours including download, installation, and reading documentation).
For the developers interested in extending the platform, I got the idea at a late stage to use HTTP Options to transmit meta-information about how fields should be rendered on the frontend. It's very basic at the moment, mostly just data type and whether a field is required or not when creating or updating. A more useful implementation will require a fairly significant refactoring which I don't plan to do for the first release.
Back to the top
It's contrived, but spread the word! It really does help. Don't be afraid to share the campaign page.
Invite me to do an AMA, casual or official. That'd be fun. I like answering questions and elaborating about what isn't clear.
If you're going to sign-up for an account on Webfaction, which I highly recommend, use my affiliate id: mcclure
Here's a link: https://www.webfaction.com/signup?aid=mcclure
Back to the top
(Videos demonstrations will be uploaded soon.)
In the most simple case, a user follows a three-step setup wizard, optionally skipping the second step, and selects from a list of 10 preset configurations to setup a working app with minimal effort in a matter of minutes.
More involved users can use the default services as templates, tweak the behavior, mix and match parts as they desire, or even skip the wizard all together and try building a service by hand from the ground up.
Developers will have the opportunity to extend the platform even further by taking advantage of hooks to create their own data models and queries then registering them with the API. The administration panel will detect them automatically and include further configuration, display, and settings options.
The truly adventurous won't even need to use the backend at all. The documentation will specify everything you need in case you want to start from scratch and communicate directly with the mobile app.
Sinookas is a content-driven application, so most of its power and flexibility comes from fine-tuning the behavior of content. There are currently three categories:
- Content: this is the core piece of, well, content. Often it is the center-point of a service
Examples: messages, ingredients, historical sites
- Content Groups: these are exactly what they sound like: groups of content.
Examples: conversations, recipes, tour guides
- Meta-Content: content about/connected to other content or content groups.
Examples: Away messages, tips, warnings
These categories are essentially text, geospatial information, and a file attachment with some additional information for each. You also find other attributes commonly found with digital data like the author, time-date information (publish, expiration, and deletion dates), who can view the content, who has viewed it, view counts, visibility rules, and some others.
You tailor the behavior by creating specific instances of each category, called Content Types, where you define default values and control what users can see and edit. It's a ridiculously simple idea, but a lot of "different" services and tasks can be squeezed out by changing minor things.
For example, take a shopping list, just a group of food items. It's a very basic Content Group. By allowing other people to contribute, the shopping list becomes dynamic so your family or roommates can add to it from wherever they are. But any list that accepts input from multiple users is functionally no different than a private messenger service. Because we're consenting adults, all it takes is to just rename "shopping list" and "food item" to "conversation" and "message" to create the illusion of a different service. There are more subtle changes you can make to improve the user experience, but this is just a demonstration.
Then by enabling GPS-data for each of these, your shopping list alerts you to pick something up as you walk by a store and a location-dependent messenger where you continue conversations based on where you are.
Alternatively, requiring users to provide publish and expiration dates shifts the behavior from geospatial notifications to temporal ones, or in other words, a reminder system, the basis for daily planners, todo lists, project management, calendars. etc. etc.
Little tweaks open up lots of possibilities. Be creative. Ask yourself questions. What effect does adding users to a service have? What could a a maximum view count be used for? Does changing the order of content matter? What happens when all messages have the same value for X? What do you get when you limit titles to 140 characters? What happens when all content has a required duration after which it is no longer available? Why would I want all active users to be visible on the map?
Once the content types are set up, you build your service. These are more general rules that tie everything together. You can require all activity to take place in certain geographic reasons, and if so, whether the map should be viewable. You set how often users can search and how fast users can travel--intended to protect against cheating and bots but maybe there are other uses?
Under certain circumstances users are considered to be a special type of content, so here you can define what should be visible and editable.
It's also where you include and exclude the content types you've created. You determine whether users can create content or just read it. For geospatial content, you define how far away a user must be to detect content.
You also have the opportunity to change the color scheme and some labels here.
Each Sinookas server can run multiple services simultaneously. Global settings are rules that apply to all of your services (e.g., the name of your server, a description, terms of service[if applicable], permissible file types to be uploaded, virus scanning policy), dictate what happens before a user logs in or registers (Design settings, registration methods) and where they are directed once they login.
Back to the top
These are just some multi-user services I would like people to create:
- Local history guides/tours for cities, towns, and regions
- Neighborhood watches
- GPS guide to fiction that takes place in real locations (e.g., On the Road, and Confederacy of Dunces), with chapters mapped to where they may have taken place
- Location-based news
- Boycotts
- Archaeology excavation aides
- GEO-blogging
- Human Trackers/Visual aids for sports that take place over large areas: paintball, cross country, mountain biking.
Back to the top
Backend/Web Interface
- Python 2.7 and 3.4+ compatible
- Built with Django 1.8+
- Features a browsable REST-API that uses the JSON format
- Optionally uses the Nominatim service from Open Street Maps to retrieve boundary definitions when trying to create regions from text descriptions
Mobile Application
- Compatible with Android 2.3+
- Requires Google Play Services to be installed (for now) for efficient location handling
- Required Dangerous Permissions:
- Group (Permission(s)): explanation
- Camera (CAMERA): for users to upload images and videos
- Location (ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION): it's a GPS app :)
- Microphone (RECORD_AUDIO): so users can upload audio files
- Storage (READ_EXTERNAL_STORAGE): so users can upload files
Database
- PostgreSQL is required for certain database fields
- PostGIS extension
Security and privacy
- TLS/SSL is required
- Password encryption: sha256, pbkdf2 algorithm, 12,000 iterations, 12 character salt
- Authorization tokens: sha128, 15 day expiration, 128 character digest, 16 character salt
- Multiple tokens are issued per user per request and can be revoked simultaneously
- Developers may change password and token implementation details as they see fit
- Files are scanned for malicious content using ClamAV
- File types are verified by the magic number file signature
Back to the top
Legal stuff
Android is a trademark of Google Inc.
The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.
Back to the top