mirror of
https://github.com/runbear-io/beardrive.git
synced 2026-08-25 08:08:08 +02:00
Merge pull request #24 from runbear-io/feat/gtm-readiness
GTM readiness: reviewer-scored launch prep (6 rounds → 9/8/9/9/8/9 ×2)
This commit is contained in:
Snow W. Lee (Sungwon)
@@ -1,14 +1,24 @@
|
||||
{
|
||||
"name": "beardrive",
|
||||
"owner": { "name": "runbear", "email": "snow@runbear.io" },
|
||||
"description": "BearDrive (beardrive) — a synced file system for AI agents",
|
||||
"owner": {
|
||||
"name": "runbear",
|
||||
"email": "snow@runbear.io"
|
||||
},
|
||||
"description": "BearDrive — the open-source Google Drive for AI agents: one folder your team and their agents share, with per-change attribution and read analytics.",
|
||||
"plugins": [
|
||||
{
|
||||
"name": "beardrive",
|
||||
"source": "./plugin",
|
||||
"description": "BearDrive: folders that stay in sync across your team and agents through a BearDrive server (or S3/GCS directly). Installs the beardrive skill, /beardrive:install, /beardrive:init and /beardrive:status commands, and turn-boundary sync hooks in one step.",
|
||||
"description": "BearDrive: folders that stay in sync across your team and agents through a self-hostable BearDrive hub, with per-file history and public share links. Installs the beardrive skill, /beardrive:install, /beardrive:init and /beardrive:status commands, and turn-boundary sync hooks in one step.",
|
||||
"category": "workflow",
|
||||
"tags": ["sync", "files", "workspace", "s3", "gcs", "agents"]
|
||||
"tags": [
|
||||
"sync",
|
||||
"files",
|
||||
"workspace",
|
||||
"agents",
|
||||
"memory",
|
||||
"claude-code"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
@@ -0,0 +1,47 @@
|
||||
name: Bug report
|
||||
description: Something misbehaved — a sync, the CLI, the hub, or the web UI
|
||||
labels: [bug]
|
||||
body:
|
||||
- type: input
|
||||
id: version
|
||||
attributes:
|
||||
label: bdrive version
|
||||
description: Output of `bdrive version`
|
||||
placeholder: beardrive v0.7.0
|
||||
validations:
|
||||
required: true
|
||||
- type: input
|
||||
id: os
|
||||
attributes:
|
||||
label: OS / platform
|
||||
placeholder: macOS 15.2 (arm64) / Ubuntu 24.04
|
||||
validations:
|
||||
required: true
|
||||
- type: dropdown
|
||||
id: mode
|
||||
attributes:
|
||||
label: Where does it happen?
|
||||
options:
|
||||
- Syncing client (bdrive CLI / daemon)
|
||||
- Self-hosted hub (bdrive web)
|
||||
- Web UI in the browser
|
||||
- Claude Code plugin / agent hooks
|
||||
- Not sure
|
||||
validations:
|
||||
required: true
|
||||
- type: textarea
|
||||
id: repro
|
||||
attributes:
|
||||
label: What happened, and how do we reproduce it?
|
||||
description: |
|
||||
Steps, expected vs actual. For sync issues, `bdrive status` and
|
||||
`bdrive log -n 20` output help a lot. Never paste tokens or the
|
||||
contents of settings.json.
|
||||
validations:
|
||||
required: true
|
||||
- type: textarea
|
||||
id: logs
|
||||
attributes:
|
||||
label: Logs (optional)
|
||||
description: Daemon log lives at `~/.bdrive/volumes/<mount-id>/daemon.log`.
|
||||
render: text
|
||||
@@ -0,0 +1,27 @@
|
||||
name: Feature request
|
||||
description: An idea for BearDrive — check ROADMAP.md first, it might already be planned
|
||||
labels: [enhancement]
|
||||
body:
|
||||
- type: textarea
|
||||
id: problem
|
||||
attributes:
|
||||
label: What are you trying to do?
|
||||
description: The workflow or problem, not just the feature — context makes better designs.
|
||||
validations:
|
||||
required: true
|
||||
- type: textarea
|
||||
id: proposal
|
||||
attributes:
|
||||
label: What would you like BearDrive to do?
|
||||
validations:
|
||||
required: true
|
||||
- type: dropdown
|
||||
id: area
|
||||
attributes:
|
||||
label: Area
|
||||
options:
|
||||
- Sync engine / CLI
|
||||
- Hub / web UI
|
||||
- Agent integration (hooks, plugin, skills)
|
||||
- Sharing / permissions
|
||||
- Other
|
||||
@@ -0,0 +1,10 @@
|
||||
## What & why
|
||||
|
||||
<!-- One paragraph: what changes, and the problem it solves. -->
|
||||
|
||||
## Checklist
|
||||
|
||||
- [ ] `go build ./... && go vet ./... && go test ./...` green
|
||||
- [ ] Sync behavior changes have a multi-device test in `internal/syncer`
|
||||
- [ ] Frontend changes: `npm run build` re-committed `internal/webapp/static` and `npm run e2e` is green
|
||||
- [ ] CLI behavior changes updated both `README.md` and `plugin/skills/beardrive/SKILL.md`
|
||||
@@ -0,0 +1,69 @@
|
||||
# Changelog
|
||||
|
||||
Notable changes per release. Format loosely follows
|
||||
[Keep a Changelog](https://keepachangelog.com/); BearDrive is pre-1.0, so
|
||||
minor versions may ship breaking changes (see [SemVer §4](https://semver.org/#spec-item-4)).
|
||||
|
||||
## v0.7.0 — 2026-07-14
|
||||
|
||||
- **`bdrive url <file>`** — internal, permission-walled links (sign-in +
|
||||
project membership required) that agents share when they create files;
|
||||
the plugin now teaches agents to include the link in their reply.
|
||||
- Mobile layout overhaul: responsive chrome now covers tablet and phone
|
||||
landscape, 44px touch targets throughout, five designer-review rounds.
|
||||
- Read-heat hooks re-registered on upgrade pick up broader matchers.
|
||||
|
||||
## v0.6.0 — 2026-07-13
|
||||
|
||||
- **Web UI rewritten in React + TypeScript** (same URLs, same design):
|
||||
committed build output keeps `go build`/`go install` Node-free.
|
||||
- **Read-heat coverage fix**: agent reads via shell commands (`cat`,
|
||||
`grep`, `tail`) and Grep matches now count, not just native file reads;
|
||||
`bdrive hooks install` upgrades existing hook matchers in place.
|
||||
- Content-hashed assets served immutable; committed e2e harness +
|
||||
42-spec Playwright suite.
|
||||
|
||||
## v0.5.0 — 2026-07-12
|
||||
|
||||
- **Project home page**: connect-an-agent guide (Claude Code & Cowork
|
||||
plugin flow, Hermes/Codex CLI) with real hub URL + project id filled
|
||||
in; Insights embedded for admins/org owners.
|
||||
- Two-file AGENTS.md orientation for shared folders in the plugin flows.
|
||||
- Expandable history notes; RESTful `/insights` and `/history` routes.
|
||||
|
||||
## v0.4.0 — 2026-07-12
|
||||
|
||||
- **Read heat / Insights**: per-file read telemetry (human vs agent vs
|
||||
share), heat dots in listings, and the Insights dashboard — treemap,
|
||||
reads×staleness scatter with the hot-but-stale danger quadrant, hot
|
||||
path, per-agent coverage matrix.
|
||||
- **Agent read reporting**: `bdrive read-log` + hooks spool agent file
|
||||
reads locally and report on next sync.
|
||||
|
||||
## v0.3.1 — 2026-07-10
|
||||
|
||||
- Parallel blob upload + progress bar for large initial imports.
|
||||
|
||||
## v0.3.0 — 2026-07-10
|
||||
|
||||
- **Hub-only architecture**: clients sync exclusively through a
|
||||
`bdrive web` hub over HTTPS (the `remote` command and direct
|
||||
client-to-bucket sync were removed); `bdrive logout` added.
|
||||
- **SQL metadata backends**: hub accounts/projects/orgs/shares can live
|
||||
in SQLite or Postgres (incl. Supabase) instead of JSON files.
|
||||
- Dockerfile + Cloud Run deployment recipe.
|
||||
|
||||
## v0.2.2 — 2026-07-08
|
||||
|
||||
- **BearDrive**: the project (formerly `sfs`) got its name; CLI became
|
||||
`bdrive`.
|
||||
- Multi-project sync hub with accounts and orgs; interactive
|
||||
`bdrive init` / browser `bdrive login` onboarding; public share links;
|
||||
web viewer folded into the CLI as `bdrive web`; per-file history in
|
||||
the web UI; `/beardrive:install` team onboarding for Claude Code.
|
||||
|
||||
## v0.1.0 — 2026-06-12
|
||||
|
||||
- First release: per-device append-only journals, last-writer-wins
|
||||
replay, content-addressed blobs, offline-first sync through S3/GCS/
|
||||
file remotes, conflict copies, daemon with turn-boundary agent hooks.
|
||||
@@ -0,0 +1,65 @@
|
||||
# Contributing to BearDrive
|
||||
|
||||
Thanks for wanting to help. BearDrive is early (pre-1.0) and moving fast —
|
||||
small, focused PRs land quickest, and an issue or discussion before a big
|
||||
change saves everyone time.
|
||||
|
||||
## Build & test
|
||||
|
||||
```sh
|
||||
go build ./... # everything, no CGO, no Node needed
|
||||
go vet ./...
|
||||
go test ./... # full suite
|
||||
go test ./internal/syncer -run TestConflict -v # one test
|
||||
```
|
||||
|
||||
Set `BDRIVE_HOME=/some/tmp/dir` when testing the CLI by hand so you never
|
||||
touch your real `~/.bdrive`.
|
||||
|
||||
## Run a local hub
|
||||
|
||||
```sh
|
||||
go build -o bdrive ./cmd/bdrive
|
||||
mkdir -p /tmp/hub-storage
|
||||
./bdrive web /tmp/hub-storage --addr :8080 --upload # plain-folder viewer
|
||||
```
|
||||
|
||||
For hub mode with accounts, see the self-hosting guide
|
||||
([docs/self-hosting.md](docs/self-hosting.md)). The e2e test harness
|
||||
(`BDRIVE_E2E_SERVE=1 go test -run TestE2EServe ./internal/webapp`) starts a
|
||||
seeded hub on :8993 with test accounts — handy for frontend work.
|
||||
|
||||
## The rules that matter here
|
||||
|
||||
- **Sync changes need multi-device tests.** The real coverage lives in
|
||||
`internal/syncer/syncer_test.go`: simulated devices syncing through a
|
||||
shared remote, driven cycle by cycle. A new sync behavior without a
|
||||
multi-device test is untested where it matters.
|
||||
- **Never break sync.** Errors degrade to offline and retry next cycle;
|
||||
a cycle must not fail because a side feature (telemetry, hooks) did.
|
||||
Read the invariants section in [CLAUDE.md](CLAUDE.md) before touching
|
||||
`internal/syncer`, `internal/journal`, or `internal/store` — replay
|
||||
determinism and journal ownership are the whole concurrency story.
|
||||
- **Frontend changes rebuild the committed assets.** The web UI lives in
|
||||
`internal/webapp/frontend` (React + TS, Vite); its build output is
|
||||
committed at `internal/webapp/static` so `go build` needs no Node.
|
||||
After changing `frontend/src`: `npm run build`, commit the new
|
||||
`static/`, and keep `npm run e2e` green. `frontend/check-dist.sh`
|
||||
verifies freshness.
|
||||
- **Docs travel with behavior.** Changing CLI commands, flags, or output
|
||||
means updating both `README.md` and `plugin/skills/beardrive/SKILL.md`
|
||||
— the skill is what makes agents beardrive-aware and must match the
|
||||
binary.
|
||||
|
||||
## Where to start
|
||||
|
||||
[ROADMAP.md](ROADMAP.md) marks items we'd love help with, and issues
|
||||
labeled `good first issue` / `help wanted` are curated to be approachable.
|
||||
Bug reports with a reproduction (the issue form asks for `bdrive version`,
|
||||
OS, and hub vs plain-folder mode) are gold.
|
||||
|
||||
## Conduct
|
||||
|
||||
Be kind, be direct, assume good intent. Maintainers reserve the right to
|
||||
moderate. Security issues: email snow@runbear.io rather than opening a
|
||||
public issue.
|
||||
@@ -7,25 +7,38 @@ everything keeps working offline. The CLI is `bdrive`; a hub is a
|
||||
`bdrive web` server you (or we) run on an object store — clients sync
|
||||
through it over HTTPS and never touch the storage directly.
|
||||
|
||||
Two things it's for: **sharing files with people** — any synced file
|
||||
becomes a public URL that renders as a page — and **sharing context across
|
||||
AI agents**: give every agent on the team the same folder as memory, and
|
||||
your agent knows what their agent knows. Notes, plans, findings, and
|
||||
artifacts follow the team everywhere, with a full audit trail of which
|
||||
agent or human changed what.
|
||||
What it's for, first and foremost: **sharing context across AI agents** —
|
||||
give every agent on the team the same folder as memory, and your agent
|
||||
knows what their agent knows. (People are covered too: any synced file
|
||||
becomes a public URL that renders as a page.) Notes, plans, findings, and
|
||||
artifacts follow the team everywhere — and unlike a memory API, they stay
|
||||
**real files with provenance**: every change is attributed to the human,
|
||||
agent, and device that made it, and the hub's Insights show what your
|
||||
agents actually read (and which hot-but-stale docs nobody maintains).
|
||||
|
||||
<p align="center">
|
||||
<img src="docs/assets/insights.png" alt="Knowledge Insights — every file plotted by agent/human reads vs staleness; hot-but-stale docs are the danger zone" width="820">
|
||||
</p>
|
||||
|
||||
| Browse with read heat | Public share pages |
|
||||
|---|---|
|
||||
|  |  |
|
||||
|
||||
```console
|
||||
$ bdrive login # once per device (browser sign-in)
|
||||
$ bdrive login https://your-hub # once per device — self-host a hub in ~10 min (docs/self-hosting.md)
|
||||
$ cd ~/workspace && bdrive init
|
||||
initialized /Users/snow/workspace
|
||||
project: workspace (p-7f3a2c91)
|
||||
daemon: running (pid 55434, scan 3s, remote sync 10s)
|
||||
```
|
||||
|
||||
> BearDrive Cloud — zero-setup, bare `bdrive login` — is on the waitlist
|
||||
> at [beardrive.ai](https://beardrive.ai). Self-host to try it today.
|
||||
|
||||
On another machine:
|
||||
|
||||
```console
|
||||
$ bdrive login && cd ~/workspace && bdrive init
|
||||
$ bdrive login https://your-hub && cd ~/workspace && bdrive init
|
||||
# … connect the same project; the files appear and stay in sync
|
||||
```
|
||||
|
||||
@@ -72,9 +85,11 @@ go install github.com/runbear-io/beardrive/cmd/bdrive@latest
|
||||
## Quick start
|
||||
|
||||
```sh
|
||||
# 1. Sign this device in (once). Default server: beardrive.ai;
|
||||
# self-hosters pass their own URL.
|
||||
bdrive login
|
||||
# 1. Sign this device in against your hub (once per device).
|
||||
# Self-host a hub in ~10 minutes (docs/self-hosting.md), then:
|
||||
bdrive login https://your-hub
|
||||
# (BearDrive Cloud — zero-setup, bare `bdrive login` — is coming;
|
||||
# join the waitlist at beardrive.ai. Self-host to try it today.)
|
||||
|
||||
# 2. Start syncing a project — interactive: create or connect a project,
|
||||
# sync the whole folder or just ./shared. Re-run any time to resume.
|
||||
@@ -83,7 +98,7 @@ cd ~/my-project && bdrive init
|
||||
# 3. Work normally — create, edit, delete files with any tool.
|
||||
echo "remember this" > memory.md
|
||||
|
||||
# On every other device: bdrive login once, then bdrive init in a folder
|
||||
# On every other device: `bdrive login https://your-hub` once, then bdrive init in a folder
|
||||
# and connect the same project.
|
||||
|
||||
# See what changed, who changed it, and from which device
|
||||
@@ -103,7 +118,10 @@ exactly where it left off — zero re-scan, zero spurious changes.
|
||||
|
||||
### Credentials
|
||||
|
||||
beardrive uses each provider's standard credential chain — nothing beardrive-specific:
|
||||
beardrive uses each provider's standard credential chain — nothing beardrive-specific.
|
||||
Note: **client devices always use an `https://` hub remote** — the
|
||||
`s3`/`gs`/`file` rows below are how the *hub operator* configures the
|
||||
hub's own storage, never something a syncing client points at directly:
|
||||
|
||||
| Remote | Credentials |
|
||||
|---|---|
|
||||
@@ -116,7 +134,7 @@ beardrive uses each provider's standard credential chain — nothing beardrive-s
|
||||
|
||||
| Command | Description |
|
||||
|---|---|
|
||||
| `bdrive login [server-url]` | Sign this device in (browser flow; `--device` for headless; default server beardrive.ai). Switch hubs with `bdrive login <new-url>` |
|
||||
| `bdrive login [server-url]` | Sign this device in (browser flow; `--device` for headless; default server beardrive.ai — the managed cloud, waitlist-only: pass your hub URL). Switch hubs with `bdrive login <new-url>` |
|
||||
| `bdrive logout` | Sign this device out — clear the saved token/account (`--forget` also drops the remembered server) |
|
||||
| `bdrive init [folder]` | Create/connect a project and start syncing — interactive on a TTY, flags (`--name/--project/--shared/--yes`) for scripts; re-run to resume |
|
||||
| `bdrive stop [folder]` | Stop syncing (files stay; `bdrive init` resumes) |
|
||||
@@ -241,7 +259,8 @@ cd ~/some-project && bdrive init # once per project
|
||||
```
|
||||
|
||||
`bdrive login` signs the device in and remembers the server (`settings.json`
|
||||
under the bdrive home; bare `bdrive login` defaults to beardrive.ai —
|
||||
under the bdrive home; bare `bdrive login` defaults to beardrive.ai — the
|
||||
managed cloud, currently waitlist-only, so pass your hub's URL —
|
||||
`--status` shows the current server and account). To move to a **different
|
||||
hub**, run `bdrive login <new-url>` and then re-run `bdrive init` in each
|
||||
folder to connect it to a project there; `bdrive logout` signs out entirely.
|
||||
@@ -347,77 +366,18 @@ distinct-reader counts, and last-read times — never who read what;
|
||||
`?by=device` adds the agent-only per-device folder breakdown (device
|
||||
identity is already public via history; human emails never appear).
|
||||
|
||||
### Authentication
|
||||
### Authentication & database
|
||||
|
||||
Hubs always require sign-in — every change is attributed to a real account.
|
||||
The whole API — web UI, uploads, project creation, device sync — needs a
|
||||
session; only `/api/config` and the auth pages stay open (the plain-folder
|
||||
viewer, `bdrive web ./folder`, remains auth-free). Accounts are
|
||||
email + password + name, kept in a file-backed registry (`auth.json`:
|
||||
bcrypt password hashes and SHA-256 token digests, atomically rewritten —
|
||||
no plaintext credentials ever touch disk).
|
||||
Hubs always require sign-in — every change is attributed to a real
|
||||
account. **Signup is invite-only by default** (the safe posture for a
|
||||
public URL); self-service signup opens only with a gate (admin approval,
|
||||
or allowed domains + email verification). Hub metadata (accounts,
|
||||
projects, orgs, shares) lives in a file-backed store by default, or
|
||||
SQLite/Postgres (incl. Supabase) via the `database` config block.
|
||||
|
||||
**Signup is invite-only by default** — the safe posture for a hub on a
|
||||
public URL. New people get in only through an expiring invite link an owner
|
||||
mints; the link lets them create an account (bypassing the gates below) and
|
||||
join, in one step. To allow self-service signup instead, set
|
||||
`"allow_signup": true` **with a gate** — the server refuses to start an open
|
||||
hub that has none, so a fake email can never just walk in. Three postures:
|
||||
Full reference — the three signup postures, SMTP, admins, CLI device
|
||||
sign-in, and database selection: **[docs/self-hosting.md](docs/self-hosting.md)**.
|
||||
|
||||
- **Invite-only** (default): `allow_signup` unset/false. Only invite links create accounts.
|
||||
- **Approval-gated**: `allow_signup: true` + `require_approval: true` — anyone can sign up, but a hub admin approves each new account before it works (no SMTP needed).
|
||||
- **Domain-restricted + verified**: `allow_signup: true` + `allowed_domains: ["you.com"]` + `require_verification: true` (needs `smtp`) — only your company's addresses may sign up, each confirming an emailed link. Verification without SMTP is refused (the link would otherwise only reach the server log).
|
||||
|
||||
Admins tune verification/approval live from the web UI (**Admin → Signup &
|
||||
access**); `allowed_domains`, the admin list, and `allow_signup` are
|
||||
server-config-owned so a browser session can never widen who gets in.
|
||||
|
||||
`bdrive login <url>` on a client device opens the server's sign-in page in
|
||||
a browser (sign up right there if needed); when the user signs in, the
|
||||
page bounces a one-time code to the CLI's loopback listener and the
|
||||
terminal finishes on its own, storing a long-lived per-device token
|
||||
(revocable server-side). On headless/SSH machines, `bdrive login --device`
|
||||
prints a short code to approve from any signed-in browser instead. Every
|
||||
sync and every `bdrive init` then authenticates with that token.
|
||||
|
||||
"Forgot password" emails a one-hour reset link via the `auth.smtp` block —
|
||||
plain SMTP, so any provider works. With no SMTP configured, the link is
|
||||
printed to the server log so an admin can hand it over; reset is never
|
||||
fully broken.
|
||||
|
||||
Two notes: put a hub behind TLS (reverse proxy
|
||||
or tailscale) — `bdrive login` warns when signing in over plain http to a
|
||||
non-localhost address. Internally all of this sits behind an
|
||||
`AuthProvider` interface; the open-source server ships the built-in
|
||||
email/password provider, and alternative identity backends can be swapped
|
||||
in without touching the CLI or the API.
|
||||
|
||||
### Choosing a database
|
||||
|
||||
A hub keeps a little **metadata** — accounts, projects, orgs, invites,
|
||||
shares, devices — separate from your files. (File content and the sync
|
||||
journals always live in the object store; the database never holds them.)
|
||||
You choose where that metadata lives with the `database` block:
|
||||
|
||||
```jsonc
|
||||
"database": { "driver": "file" } // default — JSON under BDRIVE_HOME
|
||||
"database": { "driver": "sqlite", "dsn": "/var/lib/bdrive/hub.db" }
|
||||
"database": { "driver": "postgres", "dsn": "postgres://…@…pooler.supabase.com:6543/postgres" }
|
||||
```
|
||||
|
||||
- **file** (default): zero dependencies, human-readable JSON, perfect for a
|
||||
laptop or a small self-hosted hub.
|
||||
- **sqlite**: one embedded database file — a real DB locally with no server
|
||||
to run.
|
||||
- **postgres**: a managed Postgres such as **Supabase** for production —
|
||||
just point `dsn` at its connection string (use the transaction pooler for
|
||||
many connections). Since Supabase *is* Postgres, this stays fully
|
||||
open-source with no managed-only lock-in.
|
||||
|
||||
`file` and `sqlite` are single-writer (run one hub instance); Postgres is
|
||||
transactional and can back more than one instance. Switching backends
|
||||
doesn't migrate existing data — pick one when you set the hub up. Both SQL
|
||||
drivers are pure Go, so the binary stays a CGO-free static build.
|
||||
|
||||
### Uploads
|
||||
|
||||
@@ -507,14 +467,19 @@ deletes for it), and anything excluded by `.bdriveignore` or omitted from an
|
||||
|
||||
## Roadmap
|
||||
|
||||
- `beardrive restore <path>@<time>` — restore any file from history (all content
|
||||
is already retained)
|
||||
- FUSE/NFS mount mode for lazy-loading huge volumes
|
||||
- Journal compaction & blob GC policies
|
||||
- Per-path access scopes for multi-agent setups
|
||||
See [ROADMAP.md](ROADMAP.md) — the public, dated roadmap, including the
|
||||
items we'd love help with. Highlights: `beardrive restore <path>@<time>`
|
||||
(time travel — all content is already retained), FUSE/NFS mount mode,
|
||||
journal compaction & blob GC, per-path access scopes for multi-agent
|
||||
setups.
|
||||
|
||||
## Development
|
||||
|
||||
Contributions welcome — see [CONTRIBUTING.md](CONTRIBUTING.md) for the
|
||||
build/test workflow and the rules that matter, [ROADMAP.md](ROADMAP.md)
|
||||
for where help is wanted, and [CHANGELOG.md](CHANGELOG.md) for what
|
||||
shipped when. Self-hosting a hub: [docs/self-hosting.md](docs/self-hosting.md).
|
||||
|
||||
```sh
|
||||
go build ./...
|
||||
go test ./...
|
||||
@@ -548,6 +513,11 @@ npm run e2e # Playwright suite; starts its own seeded hub on :8993
|
||||
|
||||
GNU AGPL-3.0 — Copyright 2026 Runbear, Inc. See [LICENSE](LICENSE).
|
||||
|
||||
We chose AGPL-3.0 deliberately: it keeps BearDrive fully open and
|
||||
self-hostable forever while preventing a cloud provider from offering a
|
||||
closed BearDrive-as-a-service. The managed service at beardrive.ai funds
|
||||
the project; the code stays open.
|
||||
|
||||
Everything in this repo is open source and self-hostable: a complete BearDrive
|
||||
server for one organization's deployment, teams included. The managed service
|
||||
at beardrive.ai is the same core plus what only makes sense as an operated
|
||||
|
||||
+38
@@ -0,0 +1,38 @@
|
||||
# BearDrive roadmap
|
||||
|
||||
Last updated: 2026-07-15. This is the direction, not a contract — items
|
||||
move as we learn. Comments and PRs welcome; items marked **help wanted**
|
||||
are deliberately scoped for outside contributors.
|
||||
|
||||
## Now (next release or two)
|
||||
|
||||
- **Time travel / restore** — `bdrive restore <path>@<time>`: every blob
|
||||
is already retained forever, so restore is re-putting an old blob as a
|
||||
new op. The history UI and blob API already exist; this is the CLI and
|
||||
revert UX.
|
||||
- **Demo assets & docs** — 60-second demo, richer self-hosting guide.
|
||||
|
||||
## Next
|
||||
|
||||
- **Journal compaction & blob GC policies** — bounded storage for
|
||||
long-lived, high-churn volumes (opt-in; today everything is retained).
|
||||
- **Per-path access scopes** — multi-agent setups where an agent can be
|
||||
limited to a subtree of a project. **help wanted** (design discussion
|
||||
first — this touches the org/permission model).
|
||||
- **More agent platforms in `bdrive hooks install`** — the hook engine is
|
||||
platform-generic; adding a platform is a small adapter + matcher set.
|
||||
**help wanted**.
|
||||
|
||||
## Later / exploring
|
||||
|
||||
- **FUSE / NFS mount mode** — lazy-loading huge volumes instead of full
|
||||
materialization.
|
||||
- **Search across the hub** — full-text + wikilink graph over a project.
|
||||
- **Webhooks / notifications** — "a file changed in `reports/`" pushed to
|
||||
Slack or similar (hub-side).
|
||||
|
||||
## Recently shipped
|
||||
|
||||
See [CHANGELOG.md](CHANGELOG.md): React web UI (v0.6.0), read-heat
|
||||
Insights and agent read attribution (v0.4.0), `bdrive url` internal links
|
||||
(v0.7.0), SQL metadata backends incl. Postgres/Supabase (v0.3.0).
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 335 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 274 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 210 KiB |
@@ -0,0 +1,81 @@
|
||||
# GTM handoff — actions only Snow can take
|
||||
|
||||
Everything the GTM loop cannot do from inside the repo, prioritized.
|
||||
Draft copy is ready to paste; adjust voice as you like.
|
||||
|
||||
## P0 — do before anything else (minutes each)
|
||||
|
||||
1. **Enable GitHub Discussions** on runbear-io/beardrive (Settings →
|
||||
Features). Then add categories: Announcements, Q&A, Ideas, Show &
|
||||
tell. CONTRIBUTING.md already links "where to ask" there.
|
||||
2. **Set GitHub repo topics**: `ai-agents`, `claude-code`, `file-sync`,
|
||||
`sync`, `agent-memory`, `self-hosted`, `golang`, `agpl`. (Repo →
|
||||
About → gear.)
|
||||
3. **Set the repo social-preview image** (Settings → Social preview):
|
||||
use `docs/assets/insights.png` for now — it's the most striking
|
||||
frame; replace with a branded card later.
|
||||
4. **Repo About blurb** → paste:
|
||||
> The open-source Google Drive for AI agents: one folder your team
|
||||
> and their agents share — synced in seconds, every change
|
||||
> attributed, with read analytics. Self-host in one Go binary.
|
||||
Website field: `https://beardrive.ai`.
|
||||
|
||||
5. **Verify the install path from a clean machine** (the #1 CTA must
|
||||
not 404 on launch day): `brew install runbear-io/tap/beardrive &&
|
||||
bdrive version`, and `go install
|
||||
github.com/runbear-io/beardrive/cmd/bdrive@latest`. If the tap is
|
||||
stale, cut a fresh `goreleaser release` first.
|
||||
6. **Verify the full first run, not just the binary**: on a clean
|
||||
machine, `bdrive login <a working hub> && bdrive init && edit a file
|
||||
&& bdrive log` must succeed end to end. Until BearDrive Cloud is
|
||||
live, every try-path (README, website, launch posts) must route
|
||||
people to self-hosting — bare `bdrive login` defaults to
|
||||
beardrive.ai and MUST NOT be advertised until that hub actually
|
||||
accepts logins. Gate any launch on this check.
|
||||
7. **Seed 3–5 `good first issue` / `help wanted` issues** from
|
||||
ROADMAP.md (more agent platforms in `bdrive hooks install`; per-path
|
||||
access scopes design discussion; demo assets; docs gaps) —
|
||||
CONTRIBUTING.md promises curated starter issues; make it true.
|
||||
|
||||
## P1 — demo assets (an hour)
|
||||
|
||||
8. **Record a 45–60s demo GIF/video** for the README hero and any
|
||||
launch post. Script (uses two terminals + a browser):
|
||||
- T1: `bdrive init --name demo --yes` in a folder with a few notes →
|
||||
show `bdrive status` (daemon running).
|
||||
- T1: have Claude Code write `wiki/findings.md` (or just edit it) →
|
||||
within seconds…
|
||||
- T2 (second machine/dir): the file appears; `bdrive log -n 3` shows
|
||||
the change attributed to the agent session.
|
||||
- Browser: the hub's History view for that file, then Insights.
|
||||
- T1: `bdrive share wiki/findings.md` → open the public URL.
|
||||
Tools: `vhs` (charmbracelet) or QuickTime + gifski. Put the result at
|
||||
`docs/assets/demo.gif` and add it above the fold in README.
|
||||
9. **Verify beardrive.ai serves the updated landing page** (the repo's
|
||||
`website/` — including the new `assets/insights.png`) after the next
|
||||
deploy.
|
||||
|
||||
## P2 — when you're ready to be seen (launch window)
|
||||
|
||||
10. **Show HN post** — full drafts in [launch-plan.md](launch-plan.md):
|
||||
title, body, and the first-comment founder note. Post from your
|
||||
account; be present for the first 3 hours to answer everything.
|
||||
11. **Product Hunt** — drafts in launch-plan.md. Schedule after HN, not
|
||||
the same day. Before PH: replace the mailto waitlist on the site
|
||||
with a real form (any hosted waitlist works) — email-composer
|
||||
friction kills launch-day conversion.
|
||||
12. **Claude Code plugin discoverability** — submit/announce the
|
||||
marketplace entry wherever Anthropic surfaces community plugins
|
||||
(Discord, awesome-lists PRs from your account).
|
||||
|
||||
## P3 — measurement plumbing (see metrics.md)
|
||||
|
||||
13. **Turn on GitHub traffic watching**: stars/clones/views are under
|
||||
Insights → Traffic; consider a weekly note of the numbers in
|
||||
Discussions → Announcements.
|
||||
14. **Homebrew install counts**: `brew info --analytics
|
||||
runbear-io/tap/beardrive` (public analytics take ~30 days to
|
||||
appear).
|
||||
15. **Decide on hub-side opt-in telemetry** (proposal in metrics.md —
|
||||
requires your explicit approval before any implementation; nothing
|
||||
is wired today).
|
||||
@@ -0,0 +1,86 @@
|
||||
# Spec: GTM readiness for BearDrive (reviewer-satisfied goal loop)
|
||||
|
||||
Authoritative spec for the GTM improvement loop. The bar is met by
|
||||
independent review: a `beardrive-gtm` subagent (COSS operator persona)
|
||||
audits the repo's go-to-market surfaces and scores them; the implementing
|
||||
agent never scores its own work.
|
||||
|
||||
## Scope — what the loop may change
|
||||
|
||||
Everything GTM-relevant that lives in this repo:
|
||||
|
||||
- `README.md` (positioning, quickstart, time-to-wow, demo assets plan)
|
||||
- `website/` (headline, category claim, CTAs, pricing posture copy)
|
||||
- `docs/` (self-host guide, quickstart, a launch plan, a metrics plan)
|
||||
- Community surface: `CONTRIBUTING.md`, `.github/` issue/PR templates,
|
||||
`CHANGELOG.md` or release-notes convention, a public `ROADMAP.md`
|
||||
- `plugin/` copy where it is a funnel surface (install flow wording)
|
||||
- The open↔paid line as *explanation* (docs/website copy about what OSS
|
||||
ships vs what beardrive.ai adds)
|
||||
|
||||
## Hard guardrails (violating any = the round is void)
|
||||
|
||||
1. **Truth only.** Never fabricate social proof: no invented testimonials,
|
||||
logos, user counts, star counts, or benchmarks. Every product claim
|
||||
must be verifiable against the code/docs. Aspirations are labeled as
|
||||
roadmap, not shipped features.
|
||||
2. **No license change, no pricing decisions.** Pricing/packaging content
|
||||
is written as clearly-labeled *proposal* for Snow to approve, not
|
||||
published as fact.
|
||||
3. **No external actions.** No posting, publishing, account creation,
|
||||
emailing, or launching anywhere. Anything requiring action outside the
|
||||
repo goes to `docs/gtm-handoff.md` — a prioritized checklist for Snow
|
||||
(e.g. "post X to HN with this title", "enable GitHub Discussions",
|
||||
"record 45s demo of Y") with ready-to-use draft copy where applicable.
|
||||
4. Keep README ↔ SKILL.md ↔ CLAUDE.md consistent when CLI behavior is
|
||||
described; never commit `internal/webapp/manual_serve_test.go`;
|
||||
`go build ./... && go test ./...` stays green if anything code-adjacent
|
||||
is touched; frontend changes rebuild committed static.
|
||||
5. Branch `feat/gtm-readiness`, commit per round, PR at the end; never
|
||||
merge or deploy.
|
||||
|
||||
## Review protocol (per round)
|
||||
|
||||
Launch a `beardrive-gtm` subagent. It must score the six dimensions from
|
||||
its charter (positioning, funnel, open-vs-paid line, community readiness,
|
||||
launch readiness, metrics) 0–10 **on repo-controllable readiness**: "has
|
||||
everything within this repo's power been done for this dimension?" —
|
||||
external-world gaps (no stars yet, no community yet) do NOT cap the score
|
||||
if the corresponding handoff items exist and are well-prepared. It returns
|
||||
findings tagged blocker / major / minor, each marked REPO-FIXABLE or
|
||||
HANDOFF, with concrete fixes (replacement copy written out).
|
||||
|
||||
The implementing agent fixes every repo-fixable blocker/major (and minors
|
||||
where cheap), routes handoff items into `docs/gtm-handoff.md`, and records
|
||||
the round in the Scorecard below.
|
||||
|
||||
## Exit bar
|
||||
|
||||
Two CONSECUTIVE review rounds where every dimension scores ≥ 8 and there
|
||||
are zero repo-fixable blocker or major findings. Disagreements: the
|
||||
reviewer's judgment wins unless it violates a guardrail (e.g. demands
|
||||
fabricated proof) — record such rejections under Won't-fix with reasons.
|
||||
|
||||
## Scorecard (append one row per round)
|
||||
|
||||
| Round | positioning | funnel | open-paid | community | launch | metrics | repo-fixable blockers/majors |
|
||||
|---|---|---|---|---|---|---|---|
|
||||
| 1 (baseline) | 6 | 4 | 8 | 3 | 3 | 2 | 3 blockers, 3 majors (all fixed this round; screenshots captured from the live demo hub — real UI, not fabricated) |
|
||||
| 2 | 8 | 7 | 9 | 8 | 8 | 8 | 1 major (residual dead-deployment-mode copy ×3 on the site — fixed) + 4 minors fixed; share.png re-captured with real rendered content |
|
||||
| 3 | 9 | 7 | 9 | 8 | 7 | 9 | 1 major (quickstart defaulted into the not-yet-live beardrive.ai — quickstart/closer rewritten to self-host-first, first-run gate added to handoff) + README trimmed 583→524, starter-issues & waitlist handoffs added |
|
||||
| 4 | 9 | 6 | 9 | 9 | 7 | 9 | 2 majors: bare-login default survived in the README HERO and both plugin commands (+ SKILL walkthrough, website terminal animation) — all four surfaces now self-host-first, fixed this round |
|
||||
| 5 | 9 | 8 | 9 | 9 | 8 | 9 | 0 — PASS #1 (two optional one-line minors applied after the round) |
|
||||
| 6 (confirmation) | 9 | 8 | 9 | 9 | 8 | 9 | 0 — PASS #2, EXIT BAR MET (truth-verified against code; two optional minors — og:image, SKILL parity — applied post-exit) |
|
||||
|
||||
## Won't-fix / disputed
|
||||
|
||||
(none yet)
|
||||
|
||||
## Status
|
||||
|
||||
GOAL COMPLETE (2026-07-15): rounds 5 and 6 both scored every dimension
|
||||
≥8 with zero repo-fixable blocker/major findings. Six reviewer rounds
|
||||
total. The loop's own copy was audited for truth-overreach each round —
|
||||
rounds 3 and 4 caught the loop routing strangers into the not-yet-live
|
||||
cloud, which is exactly what independent review is for. Remaining work
|
||||
is Snow's external checklist: docs/gtm-handoff.md (P0 first).
|
||||
@@ -0,0 +1,72 @@
|
||||
# Launch plan (drafts — nothing here is posted; posting is Snow's call)
|
||||
|
||||
Stage-1 launch: the goal is strangers who care — stars, issues, first
|
||||
outside users — not signups or revenue. Sequence: quiet HN → learnings →
|
||||
Product Hunt → Launch-Week-style feature cadence as Cloud approaches.
|
||||
|
||||
## Show HN (primary)
|
||||
|
||||
**Title (pick one):**
|
||||
1. `Show HN: BearDrive – open-source Google Drive for AI agents`
|
||||
2. `Show HN: A shared folder where your team's AI agents read and write — with attribution`
|
||||
3. `Show HN: BearDrive – give every agent on your team the same folder as memory`
|
||||
|
||||
**Body draft:**
|
||||
|
||||
> BearDrive mounts any folder as a synced volume for a team *and their
|
||||
> AI agents*: files sync through a self-hostable hub in seconds, every
|
||||
> change is attributed to the human/agent/device that made it, and the
|
||||
> hub shows what your agents actually read.
|
||||
>
|
||||
> Why we built it: our agents kept re-deriving context that a teammate's
|
||||
> agent had already figured out. Memory APIs felt wrong — we wanted
|
||||
> real files on disk (agents are great at files), with provenance. So:
|
||||
> append-only per-device journals, last-writer-wins replay,
|
||||
> content-addressed blobs (all history retained), offline-first, one Go
|
||||
> binary for CLI + daemon + hub. AGPL; a managed cloud will fund it.
|
||||
>
|
||||
> The part we like most: read telemetry. Agent hooks report which files
|
||||
> agents consume, so the Insights view shows "hot but stale" knowledge —
|
||||
> docs everyone's agents rely on that no one maintains.
|
||||
>
|
||||
> Happy to answer anything about the sync design (no locks — no object
|
||||
> ever has two writers), the AGPL choice, or the agent hooks.
|
||||
|
||||
**First-comment (founder voice) draft:** technical deep-dive offer —
|
||||
"the whole concurrency story is that no object has two writers: each
|
||||
device appends to its own journal; replay is deterministic," + link to
|
||||
CLAUDE.md's invariants. Answer every comment for the first 3 hours.
|
||||
|
||||
**Prep checklist:** install path verified from a clean machine
|
||||
(`brew install runbear-io/tap/beardrive && bdrive version` — a 404 tap on
|
||||
launch day is fatal), full first-run verified against a working hub (handoff #6), demo GIF live in README (handoff #8), Discussions
|
||||
enabled, `docs/self-hosting.md` linked from README, hub demo instance
|
||||
warm (expect self-host attempts within minutes).
|
||||
|
||||
## Product Hunt (after HN, separate day)
|
||||
|
||||
- **Tagline:** "The open-source Google Drive for AI agents"
|
||||
- **Description:** One folder your whole team and their agents share —
|
||||
synced in seconds, every change attributed, read analytics included.
|
||||
Self-host in one Go binary, or join the cloud waitlist.
|
||||
- **First comment:** the HN body, warmer tone, plus the 60s demo video.
|
||||
|
||||
## Launch-Week cadence (when Cloud nears — one artifact/day)
|
||||
|
||||
1. **Sync core** — the journal/replay design post ("no locks, no two
|
||||
writers").
|
||||
2. **Attribution & history** — every change knows who/what/where; time
|
||||
travel is already free (blobs retained).
|
||||
3. **Share links** — files as public pages; sandboxed HTML.
|
||||
4. **Insights** — the read×staleness quadrant; what agents actually
|
||||
read.
|
||||
5. **The Claude Code plugin** — `/beardrive:install`, two-file AGENTS.md
|
||||
orientation, `bdrive url` links in agent replies.
|
||||
|
||||
Each day: a blog-able writeup + a tweet-length version + a repo artifact
|
||||
(doc or demo). Drafts to be written per-day when scheduled.
|
||||
|
||||
## Not part of launch
|
||||
|
||||
Pricing (Cloud is waitlist-only), enterprise pages, paid promotion, and
|
||||
any claim of traction we don't have.
|
||||
@@ -0,0 +1,41 @@
|
||||
# Metrics plan
|
||||
|
||||
What we measure to know whether BearDrive is working as a project and a
|
||||
product. Stage-aware: today (a16z stage 1, project-community fit) the
|
||||
numbers that matter are attention and activation, not revenue.
|
||||
|
||||
## North star
|
||||
|
||||
> **Active shared brains**: projects with ≥2 members where an agent both
|
||||
> wrote and read a file in the last 7 days.
|
||||
|
||||
This is the promise — "your agent knows what their agent knows" —
|
||||
actually happening: multiple people, agents on both sides of the sync,
|
||||
within a week. Everything else is upstream of it.
|
||||
|
||||
## Funnel metrics (in order)
|
||||
|
||||
| # | Metric | Source | Stage |
|
||||
|---|---|---|---|
|
||||
| 1 | README/landing views → GitHub stars | GitHub Insights → Traffic (handoff #13) | attention |
|
||||
| 2 | Installs: brew + `go install` | brew analytics (handoff #14); go proxy stats are noisy — treat as directional | acquisition |
|
||||
| 3 | Activation: `bdrive init` → first successful sync | today: anecdotal/self-reported; future: opt-in telemetry (below) | activation |
|
||||
| 4 | Team formation: project gains a 2nd member (invite redeemed) | hub data (self-hosted: invisible to us; beardrive.ai once live) | expansion |
|
||||
| 5 | Wedge proof: first agent read-telemetry event in a project | hub read ledger (same visibility caveat) | wedge |
|
||||
|
||||
## What we can already see without any new code
|
||||
|
||||
- GitHub: stars, forks, issues, Discussions activity, traffic.
|
||||
- Homebrew analytics (public, aggregated).
|
||||
- beardrive.ai hub metrics once Cloud is live: metrics 3–5 fall out of
|
||||
data the hub already stores (device registry, org invites, read
|
||||
ledger) — measurement is a query, not instrumentation.
|
||||
|
||||
## Proposal (not implemented — needs Snow's approval)
|
||||
|
||||
Opt-in, anonymous CLI telemetry (a single `bdrive init` success ping with
|
||||
version + OS, no paths, no identifiers beyond a random install id,
|
||||
disabled by default with `BDRIVE_TELEMETRY=1` to enable). This is the
|
||||
only way metric #3 becomes visible for self-hosted users. **Deliberately
|
||||
a proposal**: shipping any telemetry, even opt-in, changes the trust
|
||||
posture of an OSS tool and is Snow's call, not the GTM loop's.
|
||||
@@ -0,0 +1,156 @@
|
||||
# Self-hosting a BearDrive hub in ~10 minutes
|
||||
|
||||
Until BearDrive Cloud launches, self-hosting is *the* way to run a team
|
||||
hub — and it stays a first-class, fully-supported path forever (AGPL, no
|
||||
features held back). One static Go binary, one config file, any object
|
||||
store (or a plain directory).
|
||||
|
||||
## 1. Install the binary
|
||||
|
||||
```sh
|
||||
brew install runbear-io/tap/beardrive # macOS / Linuxbrew
|
||||
# or: go install github.com/runbear-io/beardrive/cmd/bdrive@latest
|
||||
# or: grab a release tarball — https://github.com/runbear-io/beardrive/releases
|
||||
```
|
||||
|
||||
## 2. Pick storage
|
||||
|
||||
Any of: `s3://bucket/prefix`, `gs://bucket/prefix`, an S3-compatible
|
||||
endpoint, or — simplest for a first run — a plain directory
|
||||
(`file:///var/lib/bdrive/storage`). Files and change journals live
|
||||
there; hub metadata (accounts, projects, orgs) lives in the database you
|
||||
pick in step 3. Clients never see this storage — they sync through the
|
||||
hub over HTTPS.
|
||||
|
||||
## 3. Write config.json
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"remote": "file:///var/lib/bdrive/storage",
|
||||
"addr": ":4173",
|
||||
"upload": true,
|
||||
"auth": {
|
||||
// Signup is invite-only by default — the safe posture for a public
|
||||
// URL. Your first account: start once with signup gated (or use an
|
||||
// org invite), then invite teammates from the web UI.
|
||||
"admins": ["you@example.com"],
|
||||
"users_db": "/var/lib/bdrive/auth.json"
|
||||
},
|
||||
"reads": { "enabled": true }, // agent read analytics (Insights)
|
||||
"database": { "driver": "sqlite", "dsn": "/var/lib/bdrive/hub.db" }
|
||||
}
|
||||
```
|
||||
|
||||
Full knob reference for auth and databases: the sections below;
|
||||
share-link rate limits and upload TTLs: the
|
||||
[README's web-server section](../README.md#web-server).
|
||||
|
||||
## 4. Run it
|
||||
|
||||
```sh
|
||||
bdrive web -c config.json
|
||||
```
|
||||
|
||||
Put TLS in front (Caddy/nginx/your platform's LB) — device tokens travel
|
||||
as bearer tokens. For containers, the repo ships a `Dockerfile`
|
||||
(distroless, CGO-free) with a Cloud Run recipe in [deploy/](../deploy/)
|
||||
— any container platform works the same way.
|
||||
|
||||
## 5. First sign-in and first project
|
||||
|
||||
1. Open `https://your-hub/` → create your account (first run: use the
|
||||
signup posture you configured; hub admins are the `admins` emails).
|
||||
2. On any machine: `bdrive login https://your-hub` (browser flow), then
|
||||
in the folder you want synced:
|
||||
`bdrive init --name wiki --yes` — or `--shared docs` inside a repo to
|
||||
sync only that subfolder.
|
||||
3. Invite a teammate: sidebar footer → **Manage** → **New invite** —
|
||||
the join link both creates their account and adds them to your org.
|
||||
4. Connect agents: the project's home page in the web UI shows
|
||||
copy-paste setup for Claude Code/Cowork, Hermes, and Codex; or run
|
||||
`bdrive hooks install` in the folder.
|
||||
|
||||
## Authentication reference
|
||||
|
||||
Hubs always require sign-in — every change is attributed to a real account.
|
||||
The whole API — web UI, uploads, project creation, device sync — needs a
|
||||
session; only `/api/config` and the auth pages stay open (the plain-folder
|
||||
viewer, `bdrive web ./folder`, remains auth-free). Accounts are
|
||||
email + password + name, kept in a file-backed registry (`auth.json`:
|
||||
bcrypt password hashes and SHA-256 token digests, atomically rewritten —
|
||||
no plaintext credentials ever touch disk).
|
||||
|
||||
**Signup is invite-only by default** — the safe posture for a hub on a
|
||||
public URL. New people get in only through an expiring invite link an owner
|
||||
mints; the link lets them create an account (bypassing the gates below) and
|
||||
join, in one step. To allow self-service signup instead, set
|
||||
`"allow_signup": true` **with a gate** — the server refuses to start an open
|
||||
hub that has none, so a fake email can never just walk in. Three postures:
|
||||
|
||||
- **Invite-only** (default): `allow_signup` unset/false. Only invite links create accounts.
|
||||
- **Approval-gated**: `allow_signup: true` + `require_approval: true` — anyone can sign up, but a hub admin approves each new account before it works (no SMTP needed).
|
||||
- **Domain-restricted + verified**: `allow_signup: true` + `allowed_domains: ["you.com"]` + `require_verification: true` (needs `smtp`) — only your company's addresses may sign up, each confirming an emailed link. Verification without SMTP is refused (the link would otherwise only reach the server log).
|
||||
|
||||
Admins tune verification/approval live from the web UI (**Admin → Signup &
|
||||
access**); `allowed_domains`, the admin list, and `allow_signup` are
|
||||
server-config-owned so a browser session can never widen who gets in.
|
||||
|
||||
`bdrive login <url>` on a client device opens the server's sign-in page in
|
||||
a browser (sign up right there if needed); when the user signs in, the
|
||||
page bounces a one-time code to the CLI's loopback listener and the
|
||||
terminal finishes on its own, storing a long-lived per-device token
|
||||
(revocable server-side). On headless/SSH machines, `bdrive login --device`
|
||||
prints a short code to approve from any signed-in browser instead. Every
|
||||
sync and every `bdrive init` then authenticates with that token.
|
||||
|
||||
"Forgot password" emails a one-hour reset link via the `auth.smtp` block —
|
||||
plain SMTP, so any provider works. With no SMTP configured, the link is
|
||||
printed to the server log so an admin can hand it over; reset is never
|
||||
fully broken.
|
||||
|
||||
Two notes: put a hub behind TLS (reverse proxy
|
||||
or tailscale) — `bdrive login` warns when signing in over plain http to a
|
||||
non-localhost address. Internally all of this sits behind an
|
||||
`AuthProvider` interface; the open-source server ships the built-in
|
||||
email/password provider, and alternative identity backends can be swapped
|
||||
in without touching the CLI or the API.
|
||||
|
||||
## Choosing a database
|
||||
|
||||
A hub keeps a little **metadata** — accounts, projects, orgs, invites,
|
||||
shares, devices — separate from your files. (File content and the sync
|
||||
journals always live in the object store; the database never holds them.)
|
||||
You choose where that metadata lives with the `database` block:
|
||||
|
||||
```jsonc
|
||||
"database": { "driver": "file" } // default — JSON under BDRIVE_HOME
|
||||
"database": { "driver": "sqlite", "dsn": "/var/lib/bdrive/hub.db" }
|
||||
"database": { "driver": "postgres", "dsn": "postgres://…@…pooler.supabase.com:6543/postgres" }
|
||||
```
|
||||
|
||||
- **file** (default): zero dependencies, human-readable JSON, perfect for a
|
||||
laptop or a small self-hosted hub.
|
||||
- **sqlite**: one embedded database file — a real DB locally with no server
|
||||
to run.
|
||||
- **postgres**: a managed Postgres such as **Supabase** for production —
|
||||
just point `dsn` at its connection string (use the transaction pooler for
|
||||
many connections). Since Supabase *is* Postgres, this stays fully
|
||||
open-source with no managed-only lock-in.
|
||||
|
||||
`file` and `sqlite` are single-writer (run one hub instance); Postgres is
|
||||
transactional and can back more than one instance. Switching backends
|
||||
doesn't migrate existing data — pick one when you set the hub up. Both SQL
|
||||
drivers are pure Go, so the binary stays a CGO-free static build.
|
||||
|
||||
## Upgrading
|
||||
|
||||
`brew upgrade beardrive` (clients and hub are the same binary — keep
|
||||
them roughly in step; the sync protocol is append-only journals + blobs,
|
||||
which old clients read forward). After upgrading a client, re-run
|
||||
`bdrive hooks install` once per project to pick up any hook improvements.
|
||||
|
||||
## Backup
|
||||
|
||||
Everything irreplaceable is in two places: the storage root (blobs +
|
||||
journals — files and their entire history) and the metadata database
|
||||
(accounts/projects/orgs/shares). Snapshot both; restore is copy-back.
|
||||
@@ -1,11 +1,21 @@
|
||||
{
|
||||
"name": "beardrive",
|
||||
"displayName": "BearDrive",
|
||||
"description": "BearDrive: a synced file system for AI agents. Mount folders that stay in sync across devices through S3/GCS/any object store, with automatic sync at turn boundaries and full change history. CLI: bdrive.",
|
||||
"description": "BearDrive — the open-source Google Drive for AI agents: mount folders that stay in sync across devices and teammates through a self-hostable BearDrive hub (backed by S3/GCS/any object store), with turn-boundary sync, per-change attribution, and full change history. CLI: bdrive.",
|
||||
"version": "0.1.0",
|
||||
"author": { "name": "runbear", "url": "https://github.com/runbear-io" },
|
||||
"author": {
|
||||
"name": "runbear",
|
||||
"url": "https://github.com/runbear-io"
|
||||
},
|
||||
"homepage": "https://github.com/runbear-io/beardrive",
|
||||
"repository": "https://github.com/runbear-io/beardrive",
|
||||
"license": "AGPL-3.0-only",
|
||||
"keywords": ["sync", "files", "workspace", "s3", "gcs", "memory", "agents"]
|
||||
"keywords": [
|
||||
"sync",
|
||||
"files",
|
||||
"workspace",
|
||||
"memory",
|
||||
"agents",
|
||||
"claude-code"
|
||||
]
|
||||
}
|
||||
|
||||
@@ -13,10 +13,12 @@ Follow these steps:
|
||||
or `go install github.com/runbear-io/beardrive/cmd/bdrive@latest`) and
|
||||
wait for the user's choice before installing.
|
||||
|
||||
2. **Sign in if needed**: run `bdrive login --status`. With no server or a
|
||||
stale token, run `bdrive login` (tell the user a browser window is
|
||||
coming; it completes by itself). Default server is beardrive.ai; pass a
|
||||
self-hosted URL if the user mentioned one.
|
||||
2. **Sign in if needed**: run `bdrive login --status`. With no valid
|
||||
session, ask the user for their team's hub URL and run
|
||||
`bdrive login https://their-hub` (tell the user a browser window is
|
||||
coming; it completes by itself). Bare `bdrive login` targets BearDrive
|
||||
Cloud, which is not open yet — only use it if the user says their team
|
||||
is on the cloud beta.
|
||||
|
||||
3. **Detect knowledge tooling** (skip if the folder already contains
|
||||
`.bdrive/` — then just run `bdrive init --yes`; it resumes syncing,
|
||||
|
||||
@@ -15,11 +15,13 @@ If neither works, stop and tell the user how to install manually.
|
||||
|
||||
## 2. Sign in if needed
|
||||
|
||||
Run `bdrive login --status`. If there is no server or the token is invalid,
|
||||
run `bdrive login` — it opens the user's browser to sign in (or sign up) and
|
||||
completes by itself. Default server is beardrive.ai; if the user mentioned a
|
||||
self-hosted server, pass its URL: `bdrive login https://their-server`.
|
||||
Tell the user a browser window is coming before you run it.
|
||||
Run `bdrive login --status`. If there is no valid session, sign in against
|
||||
the team's hub: ask the user for their hub URL and run
|
||||
`bdrive login https://their-hub` — it opens the browser to sign in (or
|
||||
sign up) and completes by itself. (Bare `bdrive login` targets BearDrive
|
||||
Cloud, which is not open yet — don't use it unless the user says their
|
||||
team is on the cloud beta.) Tell the user a browser window is coming
|
||||
before you run it.
|
||||
|
||||
## 3. Initialize the project
|
||||
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
---
|
||||
name: beardrive
|
||||
description: Use BearDrive — a synced file system for AI agents and teams. Start syncing any project folder (bdrive init) and it stays in sync across devices and teammates through a BearDrive hub, with accounts, per-file change history, public share links, and offline support. Use when the user wants to "set up beardrive", "sync this folder", "share this file by URL", "start/stop syncing", "connect to a beardrive server", "switch to a different hub", "check bdrive status", "see what changed", "who changed this file?", or troubleshoot a stuck sync.
|
||||
description: Use BearDrive — the open-source Google Drive for AI agents and their teams. Start syncing any project folder (bdrive init) and it stays in sync across devices and teammates through a BearDrive hub, with accounts, per-file change history, public share links, and offline support. Use when the user wants to "set up beardrive", "sync this folder", "share this file by URL", "start/stop syncing", "connect to a beardrive server", "switch to a different hub", "check bdrive status", "see what changed", "who changed this file?", or troubleshoot a stuck sync.
|
||||
---
|
||||
|
||||
# BearDrive — synced file system for AI agents
|
||||
# BearDrive — Google Drive for AI agents
|
||||
|
||||
**BearDrive** (CLI: `bdrive`) turns any folder into a synced project: a background daemon per project scans for local changes and exchanges them with a **hub** (a `bdrive web` server). Files on disk are always real files — every tool, editor, and agent works on them with no integration.
|
||||
|
||||
@@ -13,7 +13,7 @@ Use this skill whenever the user is working with the `bdrive` CLI: initializing
|
||||
|
||||
| Action | Command |
|
||||
|---|---|
|
||||
| Start syncing a project (create/connect; the front door) | `bdrive init [<folder>]` — interactive on a TTY; flags `--name <x>` / `--project <id>` / `--shared <dir>` / `--yes` for scripts and agents (NEVER prompts without a TTY). Re-run to resume, including after the folder was renamed/moved. Runs `bdrive login` first if the device has no session. |
|
||||
| Start syncing a project (create/connect; the front door) | `bdrive init [<folder>]` — interactive on a TTY; flags `--name <x>` / `--project <id>` / `--shared <dir>` / `--yes` for scripts and agents (NEVER prompts without a TTY). Re-run to resume, including after the folder was renamed/moved. Runs the login flow first (against your hub URL) if the device has no session. |
|
||||
| Run the daemon in the foreground | `bdrive init -f` |
|
||||
| Stop syncing | `bdrive stop [<folder>]` (`--forget` also unregisters) |
|
||||
| One sync cycle now | `bdrive sync [<folder>]` |
|
||||
@@ -22,7 +22,7 @@ Use this skill whenever the user is working with the `bdrive` CLI: initializing
|
||||
| Mounts + daemon + pending state | `bdrive status [<folder>]` |
|
||||
| Change history | `bdrive log [<folder>] [-p path] [-n N]` |
|
||||
| This device's identity | `bdrive whoami` |
|
||||
| Sign this device in (once per device) | `bdrive login [url]` — bare form uses the remembered server or beardrive.ai. Opens the sign-in page in a browser (sign-up available there); the terminal completes on its own and stores a per-device token. `--device` prints a code to approve from any browser (SSH/headless); `--status` shows server + account. Password reset: "Forgot password?" on the sign-in page (emailed via the server's SMTP config, or the link appears in the server log). **Switch hubs** with `bdrive login <new-url>`, then re-run `bdrive init` in each folder. |
|
||||
| Sign this device in (once per device) | `bdrive login [url]` — bare form uses the remembered server or beardrive.ai — currently waitlist-only; pass your hub URL. Opens the sign-in page in a browser (sign-up available there); the terminal completes on its own and stores a per-device token. `--device` prints a code to approve from any browser (SSH/headless); `--status` shows server + account. Password reset: "Forgot password?" on the sign-in page (emailed via the server's SMTP config, or the link appears in the server log). **Switch hubs** with `bdrive login <new-url>`, then re-run `bdrive init` in each folder. |
|
||||
| Sign this device out | `bdrive logout` — clears the saved token + account (folders untouched); `--forget` also drops the remembered server. The device token stays valid server-side until it expires — revoke it from the hub's device list to be sure. |
|
||||
| Link a synced file for teammates | `bdrive url <file>` — prints the file's hub viewer URL (sign-in + project membership required; always the latest content). Computed locally, no network; `--sync` pushes first so a just-created file's link resolves immediately; no arg = the project home page. **After creating a shareable artifact (.md/.html/.csv/report/plan) in the shared folder, include this link in your reply** so teammates can open it. |
|
||||
| Share a synced file publicly by URL | `bdrive share <file>` — prints a link anyone can open (HTML renders as a page, markdown rendered, PDFs inline; sandboxed; always the latest content; no account needed). `--expires 24h` for self-destructing links; `--list` / `--revoke <token-or-url>` to manage. Put generated reports in the shared folder, sync, then share. |
|
||||
@@ -69,7 +69,7 @@ Selective-sync semantics — important when advising users:
|
||||
|
||||
### Init flow
|
||||
|
||||
1. `bdrive login` once per device (browser sign-in; default server beardrive.ai; sign-up available on the page).
|
||||
1. `bdrive login https://your-hub` once per device (browser sign-in; sign-up available on the page). Bare `bdrive login` targets BearDrive Cloud, which is not open yet — use the team's hub URL.
|
||||
2. Run `bdrive init` in the folder. Interactive on a TTY (create new / connect existing project; whole folder / shared subfolder); with flags or without a TTY it creates-or-joins a project named after the folder and syncs everything. It:
|
||||
- writes `<folder>/.bdrive/config.json` (mount id + project + remote) and registers the mount id in `~/.bdrive/mounts.json`,
|
||||
- seeds a starter `.bdriveignore` (node_modules, build dirs, caches, `.env*`) when none exists,
|
||||
@@ -260,7 +260,7 @@ The `s3://`/`gs://`/`file://` URL is the **hub's** storage root; the prefix can
|
||||
### Pointing a hub at storage (server-side)
|
||||
|
||||
```sh
|
||||
# Start a hub on an S3 bucket; clients then `bdrive login` + `bdrive init`
|
||||
# Start a hub on an S3 bucket; clients then `bdrive login https://this-hub` + `bdrive init`
|
||||
bdrive web s3://acme-beardrive/root --upload
|
||||
|
||||
# Or from a config file
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 335 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 274 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 210 KiB |
+40
-24
@@ -4,10 +4,14 @@
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<title>BearDrive — Google Drive for AI agents</title>
|
||||
<meta name="description" content="Google Drive for AI agents: one synced folder for your whole team. Share any file with people as a public URL; share context across agents, so your agent knows what their agent knows. Open source, no server required.">
|
||||
<meta name="description" content="Google Drive for AI agents: one synced folder for your whole team. Share any file with people as a public URL; share context across agents, so your agent knows what their agent knows. Open source and self-hostable.">
|
||||
<meta property="og:title" content="BearDrive — Google Drive for AI agents">
|
||||
<meta property="og:description" content="One synced folder for humans and agents: files become public URLs for people, and shared memory for every teammate's agent. Open source, no server required.">
|
||||
<meta property="og:description" content="One synced folder for humans and agents: files become public URLs for people, and shared memory for every teammate's agent. Open source, self-host in one binary.">
|
||||
<meta property="og:type" content="website">
|
||||
<meta property="og:image" content="https://raw.githubusercontent.com/runbear-io/beardrive/main/website/assets/insights.png">
|
||||
<meta property="og:image:width" content="2720">
|
||||
<meta property="og:image:height" content="1700">
|
||||
<meta name="twitter:card" content="summary_large_image">
|
||||
<meta property="og:url" content="https://beardrive.ai">
|
||||
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>🐻</text></svg>">
|
||||
<style>
|
||||
@@ -276,7 +280,7 @@ footer a:hover { color: var(--text); }
|
||||
<a href="#claude">Claude Code</a>
|
||||
<a href="#get">Open source</a>
|
||||
<a href="https://github.com/runbear-io/beardrive" title="GitHub">GitHub</a>
|
||||
<a class="btn" href="#get">Start syncing</a>
|
||||
<a class="btn" href="https://github.com/runbear-io/beardrive">Star on GitHub</a>
|
||||
</div>
|
||||
</div>
|
||||
</nav>
|
||||
@@ -287,7 +291,7 @@ footer a:hover { color: var(--text); }
|
||||
<h1>Google Drive for AI agents.<span class="green">Your agent knows what their agent knows.</span></h1>
|
||||
<p class="sub">One synced folder for your whole team — humans and agents.
|
||||
<b>Share any file with people</b> as a public URL; <b>give every agent the same
|
||||
memory</b>, synced across machines in seconds. Real files. No server required.</p>
|
||||
memory</b>, synced across machines in seconds. Real files. Self-host the whole thing in one Go binary.</p>
|
||||
<div class="cta-row">
|
||||
<a class="btn" href="#get">Start syncing</a>
|
||||
<button class="install" id="install" title="Copy">
|
||||
@@ -303,10 +307,10 @@ footer a:hover { color: var(--text); }
|
||||
</div>
|
||||
</div>
|
||||
<div class="strip">
|
||||
<p>Works with the storage you already have</p>
|
||||
<p>Your hub stores on the object storage you already have</p>
|
||||
<div class="names">
|
||||
<span>Amazon S3</span><span>Google Cloud Storage</span><span>Cloudflare R2</span>
|
||||
<span>MinIO</span><span>any folder</span><span>— or a BearDrive hub</span>
|
||||
<span>MinIO</span><span>any folder</span>
|
||||
</div>
|
||||
</div>
|
||||
</header>
|
||||
@@ -333,12 +337,16 @@ footer a:hover { color: var(--text); }
|
||||
<p><b>Share by URL.</b> <code>bdrive share wiki/report.md</code> prints a
|
||||
public link that renders the file as a page — always the latest synced
|
||||
version, no account needed, revocable any time.</p>
|
||||
<img src="assets/share.png" alt="A shared markdown runbook rendered as a public page" loading="lazy" style="display:block;width:100%;margin-top:12px;border-radius:8px;border:1px solid rgba(255,255,255,.09)">
|
||||
</div>
|
||||
<div class="card wide">
|
||||
<div class="arch"><b>your folder</b> ←scan/materialize→ <b>local volume</b> ←push/pull→ <span class="a">object storage or a BearDrive hub</span>
|
||||
<span class="dim">real files per-device journals, devices converge through dumb storage:
|
||||
<div class="arch"><b>your folder</b> ←scan/materialize→ <b>local volume</b> ←push/pull→ <span class="a">a BearDrive hub (on S3 / GCS / R2 / a folder)</span>
|
||||
<span class="dim">real files per-device journals, devices converge through the hub's dumb storage:
|
||||
every tool works content-addressed blobs append-only, no locks, offline-safe</span></div>
|
||||
</div>
|
||||
<div class="card wide" style="padding:0;overflow:hidden">
|
||||
<img src="assets/browse.png" alt="The hub web UI browsing a project — per-file agent read counts, heat dots, and the folder's change feed" loading="lazy" style="display:block;width:100%">
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
@@ -348,13 +356,6 @@ every tool works content-addressed blobs append-only, no locks, offl
|
||||
<p class="kicker">WHY BEARDRIVE</p>
|
||||
<h2>Two superpowers, one folder.</h2>
|
||||
<div class="grid" style="grid-template-columns:repeat(auto-fit,minmax(340px,1fr))">
|
||||
<div class="card"><div class="ico">🧑🤝🧑</div>
|
||||
<p style="font-size:15px"><b>Share files with people.</b> Anything in the folder is a
|
||||
<code>bdrive share</code> away from being a public URL that renders as a page —
|
||||
markdown, HTML, PDFs. No accounts for viewers, no "can you re-send that?",
|
||||
always the latest version, revocable any time. Dropbox-link simplicity for
|
||||
everything your team produces.</p>
|
||||
</div>
|
||||
<div class="card"><div class="ico">🧠</div>
|
||||
<p style="font-size:15px"><b>Share context across agents.</b> The folder is shared
|
||||
memory. What your agent learns today — findings, plans, decisions, notes —
|
||||
@@ -362,7 +363,21 @@ every tool works content-addressed blobs append-only, no locks, offl
|
||||
session already knowing it</b>. Context stops being siloed per laptop;
|
||||
every agent on the team reads from, and writes to, the same brain.</p>
|
||||
</div>
|
||||
<div class="card"><div class="ico">🧑🤝🧑</div>
|
||||
<p style="font-size:15px"><b>Share files with people.</b> Anything in the folder is a
|
||||
<code>bdrive share</code> away from being a public URL that renders as a page —
|
||||
markdown, HTML, PDFs. No accounts for viewers, no "can you re-send that?",
|
||||
always the latest version, revocable any time. Dropbox-link simplicity for
|
||||
everything your team produces.</p>
|
||||
</div>
|
||||
<div class="card"><div class="ico">📊</div>
|
||||
<p style="font-size:15px"><b>See what your agents actually read.</b> Every change is
|
||||
attributed to the human, agent, or device that made it — and BearDrive's Insights
|
||||
show which files your agents lean on and which "hot but stale" docs the team relies
|
||||
on that nobody maintains. Agents aren't just users of the folder; they're measured.</p>
|
||||
</div>
|
||||
</div>
|
||||
<p style="margin-top:28px"><img src="assets/insights.png" alt="BearDrive Insights — every file plotted by agent and human reads versus staleness" loading="lazy" style="width:100%;border-radius:12px;border:1px solid rgba(255,255,255,.09)"></p>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
@@ -400,9 +415,10 @@ every tool works content-addressed blobs append-only, no locks, offl
|
||||
concurrent edits keep both versions as conflict copies.</p>
|
||||
</div>
|
||||
<div class="card"><div class="ico">🪣</div>
|
||||
<p><b>Bring your own storage.</b> S3, GCS, R2, MinIO, or a plain shared
|
||||
directory — BearDrive needs nothing but dumb object storage. Or sync
|
||||
through a hub and devices never hold cloud credentials at all.</p>
|
||||
<p><b>Bring your own storage.</b> Your hub is backed by S3, GCS, R2,
|
||||
MinIO, or a plain shared directory — nothing but dumb object storage.
|
||||
Clients sync through the hub over HTTPS and never hold cloud
|
||||
credentials at all.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
@@ -432,7 +448,7 @@ every tool works content-addressed blobs append-only, no locks, offl
|
||||
<div class="msg claude"><div class="who">Your Claude</div>
|
||||
<div class="bubble">Done — I saved the report to <code>wiki/q3-findings.md</code>
|
||||
(synced to the team) and here's a public link for anyone outside it:<br><br>
|
||||
<span class="url">https://beardrive.ai/s/1aad3327224e408d…</span></div>
|
||||
<span class="url">https://acme-hub.example/s/1aad3327224e408d…</span></div>
|
||||
</div>
|
||||
<div class="msg"><div class="who">Your teammate, to their Claude</div>
|
||||
<div class="bubble">What did we learn from the Q3 numbers?</div>
|
||||
@@ -464,7 +480,7 @@ every tool works content-addressed blobs append-only, no locks, offl
|
||||
</ul>
|
||||
<div class="cta-row" style="justify-content:flex-start">
|
||||
<a class="btn" href="https://github.com/runbear-io/beardrive">View on GitHub</a>
|
||||
<a class="btn ghost" href="https://github.com/runbear-io/beardrive#the-sync-hub-and-bdrive-init">Self-hosting guide</a>
|
||||
<a class="btn ghost" href="https://github.com/runbear-io/beardrive/blob/main/docs/self-hosting.md">Self-hosting guide</a>
|
||||
</div>
|
||||
</div>
|
||||
<div class="oss-card cloud">
|
||||
@@ -486,8 +502,8 @@ every tool works content-addressed blobs append-only, no locks, offl
|
||||
|
||||
<section class="closer">
|
||||
<div class="wrap">
|
||||
<h2>Share files. Share context.<br><span class="green">Set up in under a minute.</span></h2>
|
||||
<p>brew install, bdrive init, done. Files travel to people as URLs; context travels to every agent on the team.</p>
|
||||
<h2>Share files. Share context.<br><span class="green">Self-host in one binary.</span></h2>
|
||||
<p>brew install, run one hub, bdrive init. Files travel to people as URLs; context travels to every agent on the team. Cloud — zero-setup — is on the waitlist.</p>
|
||||
<div class="cta-row">
|
||||
<a class="btn" href="https://github.com/runbear-io/beardrive">Start on GitHub</a>
|
||||
<button class="install" id="install2" title="Copy">
|
||||
@@ -537,12 +553,12 @@ for (const [btn, cmd] of [["install", "install-cmd"], ["install2", "install-cmd2
|
||||
const LINES = [
|
||||
{ t: "$ ", cls: "p" }, { t: "bdrive init\n", type: true },
|
||||
{ t: "✓", cls: "ok" }, { t: " project ", cls: "dim" }, { t: "acme-wiki" },
|
||||
{ t: " syncing → beardrive.ai\n\n", cls: "dim" },
|
||||
{ t: " syncing → your team's hub\n\n", cls: "dim" },
|
||||
{ t: " (your agent writes wiki/q3-report.md…)\n\n", cls: "dim", pause: 900 },
|
||||
{ t: "$ ", cls: "p" }, { t: "bdrive status\n", type: true },
|
||||
{ t: " daemon: running\n files: 142 (3.4 MiB)\n pending: 0 — everything synced\n\n", cls: "dim" },
|
||||
{ t: "$ ", cls: "p" }, { t: "bdrive share wiki/q3-report.md\n", type: true },
|
||||
{ t: "https://beardrive.ai/s/1aad3327224e408d\n", cls: "url" },
|
||||
{ t: "https://acme-hub.example/s/1aad3327224e408d\n", cls: "url" },
|
||||
{ t: " anyone can open it — no account needed\n", cls: "dim" },
|
||||
];
|
||||
const body = document.getElementById("term-body");
|
||||
|
||||
@@ -75,7 +75,7 @@ h1 { text-align: center; font-size: 22px; margin: 0 0 6px; }
|
||||
<div class="mini">
|
||||
<div class="pill"><span class="dot">Open source</span> AGPL-3.0 · on Homebrew</div>
|
||||
<h2>A shared drive for your AI agents.<span class="g">Synced in seconds. Tracked forever.</span></h2>
|
||||
<p>Real files. No server required.</p>
|
||||
<p>Real files. Self-hostable in one binary.</p>
|
||||
<div class="row"><button class="btn">Start syncing</button><button class="btn ghost">GitHub</button></div>
|
||||
<div class="term"><span class="p">$</span> bdrive share wiki/q3-report.html
|
||||
<span class="url">https://beardrive.ai/s/1aad3327…</span>
|
||||
@@ -92,7 +92,7 @@ h1 { text-align: center; font-size: 22px; margin: 0 0 6px; }
|
||||
<div class="mini">
|
||||
<div class="pill"><span class="dot">Open source</span> AGPL-3.0 · on Homebrew</div>
|
||||
<h2>A shared drive for your AI agents.<span class="g">Synced in seconds. Tracked forever.</span></h2>
|
||||
<p>Real files. No server required.</p>
|
||||
<p>Real files. Self-hostable in one binary.</p>
|
||||
<div class="row"><button class="btn">Start syncing</button><button class="btn ghost">GitHub</button></div>
|
||||
<div class="term"><span class="p">$</span> bdrive share wiki/q3-report.html
|
||||
<span class="url">https://beardrive.ai/s/1aad3327…</span>
|
||||
@@ -109,7 +109,7 @@ h1 { text-align: center; font-size: 22px; margin: 0 0 6px; }
|
||||
<div class="mini">
|
||||
<div class="pill"><span class="dot">Open source</span> AGPL-3.0 · on Homebrew</div>
|
||||
<h2>A shared drive for your AI agents.<span class="g">Synced in seconds. Tracked forever.</span></h2>
|
||||
<p>Real files. No server required.</p>
|
||||
<p>Real files. Self-hostable in one binary.</p>
|
||||
<div class="row"><button class="btn">Start syncing</button><button class="btn ghost">GitHub</button></div>
|
||||
<div class="term"><span class="p">$</span> bdrive share wiki/q3-report.html
|
||||
<span class="url">https://beardrive.ai/s/1aad3327…</span>
|
||||
@@ -126,7 +126,7 @@ h1 { text-align: center; font-size: 22px; margin: 0 0 6px; }
|
||||
<div class="mini">
|
||||
<div class="pill"><span class="dot">Open source</span> AGPL-3.0 · on Homebrew</div>
|
||||
<h2>A shared drive for your AI agents.<span class="g">Synced in seconds. Tracked forever.</span></h2>
|
||||
<p>Real files. No server required.</p>
|
||||
<p>Real files. Self-hostable in one binary.</p>
|
||||
<div class="row"><button class="btn">Start syncing</button><button class="btn ghost">GitHub</button></div>
|
||||
<div class="term"><span class="p">$</span> bdrive share wiki/q3-report.html
|
||||
<span class="url">https://beardrive.ai/s/1aad3327…</span>
|
||||
@@ -143,7 +143,7 @@ h1 { text-align: center; font-size: 22px; margin: 0 0 6px; }
|
||||
<div class="mini">
|
||||
<div class="pill"><span class="dot">Open source</span> AGPL-3.0 · on Homebrew</div>
|
||||
<h2>A shared drive for your AI agents.<span class="g">Synced in seconds. Tracked forever.</span></h2>
|
||||
<p>Real files. No server required.</p>
|
||||
<p>Real files. Self-hostable in one binary.</p>
|
||||
<div class="row"><button class="btn">Start syncing</button><button class="btn ghost">GitHub</button></div>
|
||||
<div class="term"><span class="p">$</span> bdrive share wiki/q3-report.html
|
||||
<span class="url">https://beardrive.ai/s/1aad3327…</span>
|
||||
|
||||
Reference in New Issue
Block a user