This document is divided into a few sections:
- Really Big Things. These are items that can be thought of in terms of the broad development direction and business strategy.
- Big Things. Non-trivial features, possibly poorly defined and poorly understood.
- Little Things. This is a laundry list of items that may or may not ever be completed, that are nice-to-have but not strategically important.
- Distributed Nodes. Go global for improved latency and fault tolerance.
- Database v3. When development began, the single API server had SQLite built right into the binary; very speedy. Coming out of beta, we made the switch to a multi-server architecture with a distributed database (BedrockDB). It has two downsides: writing to the database does not block pending the completion of the transaction, so doing a read for data recently written can yield old or no data. The Streamie and Penguin code is littered with wait-for-two-seconds code to cope with this. Second, while Bedrock did once support macOS, that hasn’t been the case in a while, so using Bedrock requires Linux servers. Being able to consolidate the whole system onto Macs would hugely simplify the overall architecture, hardware requirements and power consumption. I’ve been eyeing FoundationDB, which looks amazing, but it has scary warnings to not run it on Macs in production. There are two other options I am considering. The more realistic of the two is to use Cloudflare Workers to access WorkersDB. My main concern is whether I could avoid being rate limited. I’d need to find some documentation that described such limits plainly before I invested the considerable time. The second (and less realistic) option is to take a step back to built-in SQLite but add a conflict resolution and synchronization mechanism. The API servers already have a channel for communicating with each other. The opportunities for making a huge mess of really important data would be numerous.
- Mac App. A real, true, native macOS app. Just imagine being able to distribute an app via the website! In addition to recording directly to locally attached storage, a Mac app could make use of a “record only” mode that performs no decoding or displaying, and would be capable of handling hundreds of cameras simultaneously. For organizations with an abundance of cameras, a Mac Mini would be a powerful and affordable management tool.
- Android App. We will need this eventually. I’m not doing it myself though.
- Navigation overhaul & unification. The iOS navigation overhaul is complete. The tvOS navigation overhaul is still pending. Once both are complete a lot more of the code will be shared across the platforms, which is vital to the next Big Thing (“Permissions”)…. Update: this is partially complete as of v3.13.0, but additional work is needed on some parts of the UI for both platforms.
- Permissions. An administrative user should be able to lock down the functionality of any device, preventing both malicious and accidental security issues. By way of example, a user may be able to stream a camera, but not view or edit the camera’s configuration. Permissions will be defined in Permission Groups. Update: this feature is finally available as of v3.13.0, extending to core data objects, the Home tab and the Settings tab.
- Audit Logging. Actions within the app and, more specifically, actions that modify data, should be logged in an immutable fashion for the purpose of being able to perform an audit. Audit logs would expire over time; they would not be manually purgeable.
- Cloud Recording. Cameras streamed by a particular device would also be securely relayed to cloud storage. Streamie supports record-to-NAS on your local network. If you have the necessary upstream bandwidth and transfer limits, this feature would remove local storage requirements.
- Bulk User Management. A mechanism for simplifying the management of 100s or 1000s of members on an account. The use case here is for a neighborhood or office building with a centralized video surveillance system where every resident or tenant can stream the cameras. As neighbors come and go and upgrade devices, the process of managing these changes needs to be minimally burdensome. There is probably an opportunity here to integrate with some sort of 3rd party user management / badge access system so that after an initial configuration process, no user management work has to take place within Streamie.
- Web Viewer. Share or monitor your cameras from the convenience of a web browser.
- HLS. I’m not entirely sure what the use case is here, but I’d like to see HLS support.
- Two-Way Audio. It’s the Wild West out there when it comes to the many ways cameras support two-way audio, but it’s worth adding solid support to at least one popular device, which would possibly be a network audio device and not actually a camera.
- Remote Streaming Session Tracking. Know which devices are (or were) remotely streaming your cameras. Manage existing connections. Define blocking rules.
- Live Stream to YouTube. Figure out how to support MPEG-DASH so that any Streamie device can live stream to YouTube (or possibly other platforms). Update: this feature is finally available (in beta) as of v3.13.2. Check it out!
- Crash Reporting & Resolutions. When an app crash occurs, make the crash details and the associated issue visible to the user. Thus a user could beware of the nature of the issue and its progress towards being resolved.
I’m adding to this list as I have time to organize all of my chicken-scratch notes.
- Remote Actions. Remotely manage the streaming state of another device, including stopping the current streaming session, or starting a new streaming session with a camera, module or group. DONE in v3.13.1.
- Attached Audio. Streamie already supports remotely accessing a device’s attached camera, and that support should be augmented with streaming an attached audio input device.
- Camera Overlays. Arrange text and images to appear overlayed on a streaming camera.
- Object Grouping. When you’ve got a bunch of cameras, modules, file servers, account members, etc., it’d be nice to be able to arrange them into groups for maintaining you organizational system. Drag and drop between the groups.
- Unlock Code. Lock the app with a passcode to improve your security, or use a Permissions Group to enforce an unlock code on restricted devices.
- Local Network Event Notifications. When a device produces an event, in addition to posting it to the server, also look at the local network for other Streamie instances and directly notify them of the event. In addition to reducing one’s reliance on an internet connection, this would reduce the latency in getting the event sent.
- SMS Alerts. Allow the user to provide a phone number for SMS alerts instead of just APNS.
- Custom API Calls for Events. When a smart home or motion event occurs, instead of logging an event or whatever, also let the user define a custom API call including the method, parameters and so forth. This might take the form of a new integration type that can be referenced when defining actions.
Streamie provides a best-in-class user experience on your iPhone, iPad, Apple TV and Apple Silicon Mac, with an intuitive user interface that makes it simple to discover, stream, record, monitor and share your HomeKit, Google Nest, Ubiquiti UniFi Protect and ONVIF-compatible IP and RTSP cameras. Streamie keeps you informed with motion event notifications and it works with most cameras using its advanced audio and video codec support. You can watch your cameras from anywhere, record 24/7 to your private NAS, remotely manage multiple locations, device permissions and seamlessly synchronize settings across your devices; configure Hubitat smart home automations, live stream to YouTube and rely on the in-app technical support system when you need help (but you can also reach us by phone). Download Streamie today. Lastly, Streamie is solar powered!