An Accessible Automation Interface - The HubSys/DarkPi
jak
Public
Seen by 15
Technology promises to give us tools for life and save us time, but cannot objectively be said to deliver on these promises.
This clear lack of delivery on available potential represents the focus of the HubSys/DarkPi project and product(s): namely, the creation of a cohesive, mental-health-and-accessibility-first computing system.
project status
In active development, currently pre-alpha.
(project site: darkpi.com)
Our development prototype "works for us", is portable, usable on solar power, and currently facilitates development of said prototype system in an off-grid, internet-free location.
Most recently, we built a web app (a custom baby birth announcement, shower, and guestbook site) to prove the functional utility of the underlying prototype, even as-is.
project scope
"Everything needs repository hosting, a build system, and a message board."
(having briefly looked through the other products proposed here, it seems as though every one might benefit from this project's more-public existence)
Our one-year if-properly-funded scope includes off-grid decentralized project repository hosting, local/remote builds with continuous integration workflows, and secure asynchronous text communication/collaboration. Our primary stretch goal adds audio and multi-media streaming to this.
(while the prototype functions for us, the first year of development is essentially about re-implementing the prototype in a more reproduceable way, so we can share it outside of our physical space)
If adequately funded, year one will see the alpha release of our 'bridge' node software to contributors and backers via our community portal, year two will see the release of our beta to corporate partners, and year three will be our public "version one" launch with dedicated and custom hardware options based on negotiated partnerships in year two.
The five-year scope includes applications in robotics, home automation, and forestry/agricultural sensing.
project goals
To return time and peace of mind to the end user through consistent, accessible computing interfaces for personal, community, and professional use.
To reduce downtime from hardware failure on the manufacturing workfloor, home office, and public space.
To fill the clear need for long-term-oriented computing, as we are intending each system to match or exceed the 20-40 year lifespan of early business computing implementations (as seen in early banking and point of sale systems, among others), placing control back in the hands of everyday users after far too long an absence.
project documents
Three of the main ones are attached.
The rest...are currently in a git repository that needs some cleaning up before it can be published to the general internet, please provide an ed25519 pubkey if you'd like to preview the main repository.
Current Plan
Establish a formal cooperative software group that models ethical relationships with open source communities and end user individuals who find current technology inaccessible.
Develop and reproduce our portable automation interface from the existing working-prototype stage, using industry best practices around security, accessibility, and engineering.
Refine said system into an efficient platform for personal and professional nontechnical use, such that it provides high availability services consistent with or above the functionality of the best current offerings for electronic communication, entertainment, and professional use.
Release said system and platform, to spread computing excellent and finance similarly audacious projects.
Demonstrate, expand, and standardize the use of user-first design, and overtly evaluate the case for long-term oriented computing services as a business revenue model.
Funding
We are preparing to launch via CrowdSupply or similar.
jak Sat 1 May 2021 6:34AM
A casual example of how to use the system in the home:
A bridge node remains connected to the internet, providing single sign on authentication and access to locally stored files for members of the household
The administrative user has opted to allow 1/3 of their system resources to be used by the community, so development builds occasionally compile portions on the user's system in the background, and the community system image CDN peers the complete image from their local network based on shortest path to a given checksum.
The user stores personal files from existing mobile devices, organizing their media into auth-or-password-protected albums for their family to share. Pushing those files to enabled cloud storage endpoints is a simple checkbox.
The user stores contacts, calendar, and notes that can be shared with other trusted users, or via existing sharing paradigms like SMS, cloud storage, and email.
The user manages their kitchen inventory and recipes, publishing specific processes for food preparation with their household, with public web visibility enabled for the recipes they all decide taste the best (with voting).
The user plays audio and video from their streaming services via the main node, with HDMI and 2.5mm audio outputs.
jak Sat 1 May 2021 6:43AM
A casual example of development use and workflows:
A bridge node exists on a network, with access to the wider internet and a compatible router.
A user writes their application code and pushes to the bridge node, which queues the project for build via all reachable and trusted nodes, concurrently building the project's atomic dependencies to integrate security patches and other time-critical code into the build workflow.
The user resolves compile-time errors, and publishes their application to the web/internet/appstore.
The user has visibility of their applications runtime errors and warnings, with structured/contextual feedback on common problems. If trusted network sharing tools are enabled, uncommon problems prompt the user for feedback intended to help others who experience similar errors.
jak Sat 1 May 2021 6:12PM
(I will be offline for about a week, and will mostly be working on polishing this into a less-abstract chunk of info, focusing towards getting to a place where I can put it up on CrowdSource or similar.)
(Please ask me questions, express concerns, and declare points of confusion...I've been working on this in near-isolation for 20+ years, and my brain is full of assumptions and datapoints which are nontrivial to identify and communicate unless something sends up a "WTF" flag.)
jak · Sat 1 May 2021 6:21AM
A casual example of how to use the system in the field:
A bridge node remains connected to the internet, providing an always-online presence for an application, endpoint, or other remote interface.
A user, with their own portable bridge node, synchronizes their work periodically with the online bridge, allowing asynchronous work to be completed by individuals who may never actually be online at the same time, exactly. Individual nodes or node networks can be identified as "trusted", allowing the trusted nodes to share encrypted data chunks for resiliency and concurrency. Immuteable system design with syncing user data across trusted peers means the loss of any specific piece of hardware is a momentary distraction from in-progress tasks.
The user collects datapoints in the field, via sensor network aggregated to the bridge. Search/filter of collected data, trajectory plotting, and data portability interfaces are available at all times, with sync/backup options when networked with other nodes. Work proceeds seamlessly on any/all networked nodes. Intentional elimination of online dependencies means the user's sensor network never needs to expose itself to the wider internet, even to get updates or rebuild everything from source.
Simply adding hardware to the pool, and cloning the desired configuration, allows more nodes to be brought online seamlessly.
The network grows.