Share through an ordinary link
Prepare a private or unlisted share in a desktop application and let the recipient open it in a supported browser.
MyTriba
A proposed media-sharing system that prepares files locally, issues private or unlisted links, and delivers from creator-controlled sources instead of central media storage by default.
- Category
- Platforms & Utilities
- Platform
- Desktop creator + web viewer · planned
- Status
- Concept
What if sharing a video link did not require uploading the media to a central host?
A desktop creator app, browser viewer, small control plane, verifiable manifests, direct transfer, explicit availability, and lower-bandwidth alternatives separate coordination from media delivery.
User value
Share a link. Keep the media under creator control.
The proposed first experience keeps private audio and video on creator-managed hardware by default while giving recipients a familiar browser link.
Retain the source and renditions
Process media locally and use the creator's device as the first delivery source instead of uploading every file to central storage.
See what keeps it available
Explain whether the creator is online, whether a direct connection is possible, and when a lower-bandwidth mode or another approved source may help.
Features
The proposed first sharing system.
These capabilities define the first MVP. None is implemented in the current repository.
- 01
Desktop creator library
Import audio or video, inspect compatibility, manage local processed assets, and reuse renditions across shares.
- 02
Local media preparation
Create a standard rendition, a lower-bandwidth alternative where practical, and audio-only playback when appropriate.
- 03
Private or unlisted sharing
Register descriptive metadata, access state, and a versioned manifest, then return a link without giving the control plane default custody of the media.
- 04
Browser playback
Resolve the share, complete any access check, choose an available mode, and begin playback before the complete file has arrived.
- 05
Verified direct transfer
Request independently transferable media units from the creator and verify each one against a signed, versioned manifest.
- 06
Visible availability and revocation
Show creator-offline, denied, unsupported-browser, and direct-connection failure states, and let the creator stop future authorized sessions.
How it works
Prepare locally, share simply, explain availability.
The intended journey hides protocol complexity without hiding the limits of creator-controlled delivery.
- 01
Choose the media
Open the desktop creator application and select a video or audio file from creator-controlled storage.
- 02
Prepare reusable renditions
Inspect compatibility, process the file locally, segment it into transferable units, and calculate the manifest and integrity data.
- 03
Create the share
Choose private or unlisted access and register the share metadata, access policy, manifest, and current availability with the control plane.
- 04
Open the browser link
Let the recipient resolve the share, pass any access check, and select an available playback mode without installing a viewer application.
- 05
Connect and verify
Coordinate a direct session, request media units from the creator, verify them against the manifest, buffer, and begin playback.
- 06
Handle limits honestly
Explain offline or incompatible states, offer available bandwidth alternatives, and allow the creator to stop new sessions without promising erasure of existing copies.
Product concept
Coordination and media delivery can be separate.
A small service can manage identity, access, manifests, connection setup, revocation, and operational health without becoming the default warehouse and streaming path for every file.
Keep the interaction familiar
Creators still send links and viewers still press play, even when the media comes from creator-controlled or community-supported sources.
Availability requires resources
The design refuses to imply permanent availability when no creator, supporter, node, or bounded reliability service is contributing storage, bandwidth, and uptime.
Contribution must be explicit
Viewer assistance, persistent supporter seeding, storage, bandwidth, and background participation must be visible, controllable, bounded, and removable.
Architecture
A small control plane coordinates a separate media path.
The proposed architecture keeps share metadata and connection setup central while creator-controlled and later community-supported sources carry the media itself.
- 01Creator-controlled source file
- 02Local renditions and media-unit hashes
- 03Versioned manifest and share record
- 04Access resolution and signaling
- 05Creator-to-viewer media units
- 06Verified playback and availability state
The control plane coordinates
Identity, share lookup, access, manifests, short-lived presence, signaling, revocation, and coarse operations remain separate from default media storage and streaming.
Every source is untrusted
Receiving clients would verify independently transferable media units against a signed manifest instead of trusting the peer that supplied them.
Reliability is layered
Creator origin comes first, while viewer assistance, supporter seeding, persistent nodes, community mirrors, and bounded relay or edge capacity remain later concepts.
Privacy claims remain bounded
Peer delivery can reveal network information, revocation cannot erase copied media, and anonymity or end-to-end encryption must not be claimed before the model is designed and reviewed.
Technology
Technical choices remain open.
Planned clients
- macOS, Windows, or Linux creator app
- Desktop and mobile-capable browser viewer
- First supported OS undecided
Media pipeline
- Local processing
- Reusable renditions
- Signed versioned manifests
- Hash-verifiable units
Coordination
- Identity and share records
- Access and revocation
- Short-lived signaling
- Coarse operational health
Transport
- WebRTC data channels or equivalent expected
- Exact library deferred
- Relay policy unresolved
Current evidence
- No source code
- No selected stack
- No tests
- No deployment
- No AI component specified
Development
The product is defined, not implemented.
The repository contains seven substantial Phase 0 definition documents but no application source, build configuration, dependency manifest, test suite, prototype, deployment, commit history, or product media. Every capability on this page is therefore described as proposed.
- Stage
- Concept
- Application code
- None
- Validation results
- None
- Product media
- None
Documented so far
- Working name, positioning, product charter, non-negotiable principles, and public-language guidance
- Prioritized creator, viewer, supporter, curator, and technical-user personas
- Core flows for private sharing, viewing, availability, publishing, support, discovery, curation, self-hosting, unpublishing, and reporting
- Tightly scoped first MVP centered on one creator, one viewer, and creator-to-viewer delivery
- Explicit MVP exclusions, philosophical non-goals, acceptance criteria, and proposed test scope
- Logical control-plane and media-plane architecture plus an explicit list of deferred technical decisions
Next evidence
Place the definitions under version control, approve the first-slice scope, record the minimum stack decisions, and build narrow proofs for local processing, browser playback, direct transfer, integrity verification, clear failure states, and control-plane cost. Then test the end-to-end flow with non-technical creators and viewers before expanding into public publishing or community delivery.
MyTriba lab notes
The project, over time.
Notes about the thinking, architecture, development, and decisions behind this work.
Development notes for this project will begin here.