Building MyZubster in Public: Two Days of Shipping, Evidence, Android Apps, AI, TV, and Real-World Infrastructure
The last two days have been unusually productive for the MyZubster ecosystem.
What started as a series of small documentation, deployment, and evidence-management tasks turned into a broader consolidation of several parts of the project: Android applications, Google TV experimentation, Zorgax AI, public evidence, environmental collaboration material, visual documentation, and a new concept for cloud assistance inside the MyZubster metaverse.
This is a development update about what actually moved forward — and, equally importantly, what is still experimental.
MyZubster Lavori Beta is now available
One of the biggest milestones is the publication of the first Android beta of MyZubster Lavori.
The application is focused on the jobs, bounty, and contribution layer of the MyZubster ecosystem.
The current beta explores a workflow where users can:
discover available jobs and bounties;
filter opportunities;
inspect rewards;
open individual tasks;
test the application flow for applying to work.
The Android APK has been published as a GitHub prerelease:
MyZubster Lavori Beta v1
Download the MyZubster Lavori Beta release
This is deliberately a beta, not a production Play Store release.
The distinction matters.
The presence of a workflow inside the application does not automatically mean that every external payment, verification, or backend service behind that workflow is already production-ready.
MyZubster continues to separate interface development from verified operational claims.
MyZubster is moving onto the television
We also consolidated the first MyZubster TV / Google TV development build.
This is an Android TV experiment designed to explore what the MyZubster ecosystem looks like when it leaves the laptop and smartphone and enters the living room.
The current build is:
Google TV Debug 001
Download the MyZubster TV development release
The APK is intentionally classified as a debug artifact.
Real-device QA still needs to validate things such as:
launcher visibility;
D-pad navigation;
focus behavior;
TV-distance readability;
WebView behavior;
network/API communication;
Back-button behavior;
stability on actual Android TV / Google TV hardware.
We also documented an SHA-256 checksum so testers can verify that the APK they install is the expected artifact.
This may sound like a small detail, but artifact verification is part of a larger MyZubster principle:
software, evidence, and claims should be independently checkable whenever possible.
A single place for MyZubster applications
Both Android projects are now exposed through the MyZubster applications page:
MyZubster Apps
We also added repository documentation explaining where the applications can be found, how they can be installed, and what their current development status means.
The goal is to make the project easier to approach for contributors who discover MyZubster through GitHub rather than through the website.
Zorgax AI: fixing the chat experience
We also investigated an issue with the Zorgax AI chat experience.
The AI backend itself was reachable and configured, but the website experience was being affected by how the chat was embedded.
The problematic architecture relied on an iframe.
Instead of continuing to force the conversation interface through that embedded context, the website flow was changed so that Zorgax can open as a dedicated full-screen experience.
This is a good example of the type of work happening throughout MyZubster right now: not only adding features, but removing unnecessary architectural friction when real usage exposes it.
Real-world evidence enters the repository
Another important update concerns MyZubster's evidence layer.
A new work-activity evidence image associated with the Futura Ambiente documentation flow was reviewed and added to the main repository.
Before merging it, the image was checked for obvious publicly exposed personal information and embedded EXIF/GPS metadata.
This matters because MyZubster's idea of evidence is not:
upload everything and call it proof.
The goal is closer to:
collect → inspect → minimize → verify → publish
Real-world evidence can contain much more information than contributors realize: coordinates, device metadata, signatures, identifiers, addresses, QR codes, or unrelated people.
Evidence therefore needs both authenticity and privacy discipline.
Futura Ambiente: from environmental concepts toward testable pilots
Documentation around Futura Ambiente has also been organized further.
The current material explores potential environmental micro-pilots involving concepts such as:
territorial observations;
environmental evidence;
IoT and sensors;
verification;
structured reporting;
reproducible environmental workflows.
An important boundary remains in place:
a proposed pilot is not the same thing as a completed deployment.
MyZubster should not claim that sensors, plant experiments, environmental monitoring systems, or institutional collaborations are operational until there is sufficient evidence to support that statement.
That distinction is fundamental to how we want the project to evolve.
Visuals are becoming part of the evidence architecture
The visual side of MyZubster is also becoming more structured.
Recent work has included material around:
the visual foundation;
contributor-generated visuals;
working visuals;
social-media presentation;
evidence classification;
distinguishing conceptual imagery from real-world evidence.
This is particularly important in the age of generative AI.
A beautiful generated image can communicate an idea extremely well.
But it is not evidence that the depicted event occurred.
MyZubster therefore increasingly treats visual material according to its role:
concept visual ≠ documentation ≠ real evidence ≠ verified evidence
That taxonomy should become increasingly visible across the ecosystem.
A new Aruba Cloud assistance concept
Another new piece of work explores something different: cloud support inside the MyZubster metaverse.
A new document and visual have been prepared around a concept for an assistance experience related to Aruba Cloud.
The idea explores six conceptual assistance roles, including areas such as:
Cloud VPS guidance;
recovery;
networking;
digital trust services;
digital signatures;
document recognition.
The proposed architecture is roughly:
USER
↓
MYZUBSTER AVATAR
↓
GATEWAY
↓
AUTHORIZED CLOUD / SUPPORT CHANNEL
The important word is authorized.
This concept does not claim that MyZubster has an Aruba partnership, sponsorship, endorsement, or official Aruba product integration.
It is an independent proposal intended to explore whether a controlled pilot could eventually make sense.
The avatar should help users understand and prepare a request.
It should never impersonate a real employee.
And an operator should only be presented as an official verified operator when that identity and relationship have actually been authenticated.
This boundary between simulation and authority is going to become increasingly important as AI agents enter customer-support environments.
Infrastructure and deployment work
The public MyZubster website has also continued moving forward.
Production deployments have been checked through Vercel, the /apps distribution page has been made available, and Web Analytics instrumentation has been detected on the deployed site.
This gives the project a better foundation for understanding actual usage instead of relying purely on assumptions.
The next challenge is not simply generating traffic.
It is understanding:
which parts of MyZubster people actually use;
where users stop;
which experiments deserve continued development;
which interfaces create confusion;
which contributor flows convert into meaningful participation.
Documentation is becoming infrastructure
One lesson from these two days is that documentation cannot remain an afterthought.
We added or consolidated documentation around:
application downloads;
MyZubster Lavori;
MyZubster TV;
Google TV testing;
visual foundations;
environmental evidence;
Futura Ambiente concepts;
the Aruba Cloud assistance concept.
For an open-source ecosystem, documentation is part of the product.
A feature that only its creator understands is not really open infrastructure.
What is experimental?
A lot.
And that is intentional.
MyZubster currently contains production components, prototypes, debug builds, conceptual integrations, documentation, real-world evidence, AI experiments, and contributor infrastructure at different levels of maturity.
Instead of hiding that complexity, the project should label it.
A useful rule is:
prototype what could exist, document what is being built, and only claim as real what can be demonstrated.
That principle applies to AI, environmental sensing, jobs, payments, partnerships, identities, metaverse experiences, and everything else.
What comes next
The immediate roadmap is increasingly clear.
We need to continue hardening Zorgax AI, test the Android applications on real hardware, perform proper Google TV QA, improve the jobs/bounty workflow, expand the visual/evidence verification system, organize environmental pilot material, and keep reducing the gap between experimental interfaces and reproducible real-world functionality.
We also need contributors.
Not only developers.
MyZubster can benefit from testers, designers, environmental researchers, documentation contributors, Android developers, infrastructure engineers, security reviewers, artists, and people willing to test whether these ideas survive contact with the real world.
Because that is ultimately the experiment.
Not whether we can generate another interface.
But whether an open ecosystem can connect software, people, evidence, AI, physical activity, and transparent collaboration without pretending that unfinished things are already complete.
The last two days moved us a little further in that direction.
And we are continuing to build in public.
MyZubster — Open Source. Open Evidence. Real-World Experimentation.
MyZubster on GitHub
MyZubster website
Top comments (0)