C-Hour
Adapted from the 23 September 2026 plan. The proposed system is open to development with participants.
A product to shape together
The next step is a working product that people can try, improve and help build. The C-hour needs a connected software foundation: a personal agent, understandable consent, community adventures, a reciprocity ledger and links into the local area digital twins that eventually connect together and form the proposed Web3 Sensorium. Together these turn a promising idea into an experience a household, visitor or host organisation can use.
The proposed development approach is open source and AI-assisted from the beginning. We can use conversational coding, often called vibe coding, to assemble working prototypes, then improve them through real use, review and repeatable checks. Better AI tools and a growing contributor community could compress development dramatically. The roadmap therefore describes plausible capabilities, with indicative time windows that can shorten when the work is ready. It does not require waiting for the complete Aura platform or every advanced facility.
This is a starting product sketch for builders and participants to revise together. The linked corpus contains ideas, content and possible starting code. A technical inventory would help distinguish what already runs, what is reusable and what still needs to be built. Its findings may change the proposed architecture and sequence substantially.
The first useful journey
One proposed first release follows a complete journey: an invitation, a conversation, a chosen activity or existing contribution, a discussion of information use, participation, reflection and a next step. Hosts and participants would help discover which parts are useful, what is missing and what could disappear. The journey is a way to start learning from a working product.
Trying both a hosted adventure and recurring informal care would expose different needs. A connected example involving food, learning, a creative story and a place-based observation offers another way to explore the wider ecosystem. Participants may suggest a much better demonstration and that can inform other communities as they start their own C-hour pilots.
Candidate pieces to connect
Personal agent and access
A phone-friendly application is a candidate for text and voice conversations, personally chosen memory and private shared-device sessions. Participants would help shape access, recovery and ending a session. The design question is how to make assistance useful and intelligible while leaving decisions with the person.
Level Zero or L0 consent and private storage
One approach pairs a personal information store with a service that remembers purpose, information, recipient, duration and changes of consent. Separate software checks could help keep model actions within the person’s choices. Builders and participants would test this approach together, including how to inspect and revise an agreement.
Adventure and community service
A shared service might connect agent conversations with current invitations, contacts, capacity and locally developed norms. Household contribution, visitor participation and remote follow-up provide different cases to explore. Notice boards and project invitations could draw on the same information. Real hosts and participants would help decide what belongs in that shared service.
Reciprocity ledger and verification
A candidate ledger would hold contribution accounts, the context people find useful, their sharing choices and subsequent confirmations/corrections. Proposed, confirmed and disputed are possible states to test. Duplicate submissions and overlapping activities are practical questions for the first build. Community-chosen recognition, awards and rewards belongs in this exploration.
Sensorium and digital twin connections
Small connectors might translate personally authorised phone, wearable, sensor or project observations into a useful format. Source, time and purpose are ideal starting details to discuss. A place-based digital twin showing project locations and chosen outcomes would let participants try the connection. Richer simulations and immersive Aura experiences could grow from what proves useful.
Knowledge and media service
An agent connected to relevant guidance, sources and current activities might help people navigate the ecosystem. Civic AI, De-Slop learning, courses, podcasts and documentary resources offer material to explore. Participants would help assess the explanations and the distinction between imagined and operating services. Publication of a person’s story remains a separate conversation from recognising their contribution.
Operations and community support
Releases, backups, corrections and participant support are part of making a pilot useful beyond its first afternoon. Builders and hosts would work out these responsibilities together. Learning how to diagnose failures without collecting private conversations is one of the practical design requirements.
A practical foundation to test
One shared codebase with clear component boundaries is a candidate for the first assembly. It offers a relatively simple place to build and change things together. Independently operated services are another possibility as communities explore different arrangements. The people doing the work would shape that choice.
A progressive web application is a candidate for the first phone and shared-device client, offering access from a link, installation and selected offline functions. Trials on participants’ actual devices would reveal what works. A dedicated mobile companion is another option where a wearable or background sensor connection needs it. [S1]
A replaceable agent gateway would help compare models and adopt improvements without rebuilding the ledger. It offers a place to implement the person’s choices about which information reaches which service. There are an increasing number of highly capable open source AI models that could be tested as candidates for local model experiments on suitable computers. A useful pilot comparison would show what runs locally, what relies on a remote service and how each option feels to participants. [S3]
Shared software interfaces and record formats offer a way for Garden Mate, Kitchen Mate, civic tools, media projects and twins to connect. An initial connector would help test whether the proposed formats are useful. Builders of neighbouring projects would bring important input, and the formats would evolve with them.
The Web3 idea here begins with open source distributed control, portable records and verifiable provenance. Whether a blockchain adds something useful to a particular connection remains an open design question. A first pilot offers a way to investigate that value while keeping personal sovereignty and the non-monetary nature of C-hours front and centre.
A roadmap open to acceleration
Expansion would follow interest, useful results and the people joining the build. BYO device connections, local operation, food and civic tools, learning pathways and immersive twins might develop alongside one another. A contributor arriving with a working idea could change the sequence immediately. The roadmap is deliberately open to that kind of surprise.
These windows are discussion starters for a focused, resourced build. Repository findings, real participants and contributors would reshape them. Better model-assisted development and reusable components could compress the work dramatically. Sharing what people are actually doing with each release would make that acceleration visible.
First working assembly, an initial days 1 to 7 sketch
Interested builders might begin by surveying the repositories, choosing reusable parts and assembling a conversation-to-contribution journey with fictional data. A phone demonstration, a correction and a data request outside the person’s choices would give participants something concrete to discuss. What runs and what is simulated would be made clear. The findings would shape the next build.
Connected alpha, an initial weeks 2 to 4 sketch
Account access, consent controls, persistent records, human verification where appropriate and one Sensorium connector are possible next pieces. A willing household, host and visitor group would help test the experience. Changed consent, a corrected record and an interrupted connection offer useful cases to explore together before relying on the software for sensitive information.
Supported pilot, an initial weeks 4 to 8 sketch
Live adventures and notice boards would bring the product into everyday use. Voice, shared devices, community thanks and a contribution linked into a twin are possible areas of learning. Hosts and builders would track effort, costs and failures, and practise handing operation and recovery to another person.
Repeatable community release, an initial weeks 8 to 12 sketch
A second willing community would help discover what travels well and what needs local reinvention. Voluntary sharing of a contribution history offers one test, including a person choosing not to share. Installation notes, known limitations and accounts of the pilot would help the next group decide how to begin.
Help build a useful piece
A clearly named open-source home, an explicit licence, a working demonstration and simple, straightforward setup instructions would give interested people a practical entry. Contributors would review the licences of reused code and models as part of that work. Sharing software does not imply sharing the private lives of its users.
Small, useful tasks offer a way into the build: a voice interaction, a garden connector, a consent test, a translation, a source check or a simpler invitation. A purpose, sample information and an observable result would help someone begin. Testing, lived experience, accessibility and learning material belong alongside programming as contributions to product design.
AI-assisted code, tests and documentation offer a fast starting point. Review by other builders and automated checks are proposed ways to learn where a change fails before others depend on it. GitHub Actions is one available tool. Unintended data access, duplicate hours, lost consent changes and incompatible formats are useful first cases for the team to investigate. [S4]
Product coordination, software integration, personal data controls, community testing and operations are responsibilities to discuss among the people joining the build. Roles may overlap and change. Ready S.E.T. Co-op offers a possible home for related learning and mentoring. Voluntary development and testing belong within the C-hour exploration, with paid engineering retaining its own arrangements.
A working demonstration invites interest; an easy first contribution helps turn that interest into a stronger product. As AI improves, new models offer further experiments in cost, speed and capability. Participants and builders would help assess whether those improvements also respect the personal choices, applicable laws and meanings developed in the pilot while the adventure grows through that continuing exchange.
An invitation supporters can explore
A politician, nonprofit or prospective host could try the emerging journey and see which parts are running. A prospective volunteer might discover an enjoyable contribution or suggest a missing one. A developer might run the code and propose a better way to assemble it. Their questions and experiences become part of the product’s direction.
An initial budget discussion would separate build time, model and voice usage, hosting, devices, support and review. Measured pilot costs would give that discussion substance. Open source invites shared development, while the people involved work out how continuing operation is resourced and managed.
The immediate invitation is therefore concrete: help assemble and test the first connected release on Minjerribah. Bring code, lived experience, a useful activity, a device connection or a willingness to try it. The ambition is a joyful product that gets better as more people help create it, with progress fast enough to surprise us and clear enough for everyone to follow.