toybox-stories.md: the weekly roundup (#23), album-to-album sync (endojs/playground#16), and drag-to-archive.org (#118), with the needs they share. The checklist gains the toybox tree: a changed signal (T1), Blockly composition by petname (T2), and confined code in Dynamic Workers (T3). Generated-by: Claude Opus 5.5
75 lines
3.2 KiB
Markdown
75 lines
3.2 KiB
Markdown
# toybox user stories
|
|
|
|
What the pieces are for. A goal in [the capsite checklist](capsite-checklist.md)
|
|
earns its place by serving one of these; architecture with no story
|
|
waits.
|
|
|
|
## S1. Weekly roundup
|
|
|
|
> Monday morning, I open madmode and find last week's bookmarks waiting
|
|
> as a draft roundup. I drop a few, add a line of commentary to a
|
|
> couple, and publish: 10 minutes, not an hour of copy-paste.
|
|
|
|
[Weekly PESOS a la Tim Bray, madmode-blog#23](https://github.com/dckc/madmode-blog/issues/23).
|
|
Later sources join the same weekly shape: Zotero additions
|
|
([bib sync, madmode-blog#195](https://github.com/dckc/madmode-blog/issues/195);
|
|
[the zotero goal tree](zotero-checklist.md)) and social.coop posts
|
|
([the social.coop goal tree](social-coop-checklist.md)).
|
|
|
|
- source: the diigo cache, read-only (public items)
|
|
- sink: a madmode draft post
|
|
- trigger: weekly, a human in the loop
|
|
- glue: editorial — the human picks and comments
|
|
|
|
## S2. Album to album, unattended
|
|
|
|
> Every time I add a photo to Google Photos album A, it shows up in
|
|
> Amazon Photos folder A' (so it's on the TV).
|
|
|
|
[Copy on insert, IFTTT-style, endojs/playground#16](https://github.com/endojs/playground/issues/16);
|
|
context in [photo album on TV, madmode-blog#118](https://github.com/dckc/madmode-blog/issues/118).
|
|
|
|
- source: Google Photos, read-only, **one album**, with a stream of
|
|
photos added to it
|
|
- sink: Amazon Photos, write to **one folder**, plus a read-only
|
|
view of it to avoid duplicates
|
|
- trigger: each insert, nobody watching
|
|
- glue: a one-line rule
|
|
|
|
## S3. Drag photos to archive.org
|
|
|
|
> I browse my Google Photos and drag the ones worth keeping onto an
|
|
> archive.org target, which publishes them.
|
|
|
|
[The drag-and-drop comment on madmode-blog#118](https://github.com/dckc/madmode-blog/issues/118);
|
|
background in [archive.org and IPFS for the commons, madmode-blog#108](https://github.com/dckc/madmode-blog/issues/108).
|
|
The plugins should be "boring enough for an LLM to do most of the
|
|
work", given [ocap-discipline clues for LLMs, awesome-ocap#55](https://github.com/dckc/awesome-ocap/issues/55).
|
|
|
|
- source: Google Photos, read-only
|
|
- sink: archive.org, post
|
|
- trigger: a human gesture (drag-and-drop)
|
|
- glue: a UI that holds both capabilities
|
|
|
|
## What the stories share
|
|
|
|
| need | S1 | S2 | S3 | goal |
|
|
|---|---|---|---|---|
|
|
| session-cookie read where the official API is closed | diigo | Google Photos | Google Photos | webapp (done for diigo) |
|
|
| a cache of what's been read | ✓ | ✓ | ✓ | 1c (done for diigo) |
|
|
| fresh data | ✓ | ✓ | | 1f |
|
|
| **narrowed capabilities** (one album, one folder, public only) | public only | ✓ | ✓ | *no goal yet* |
|
|
| a changed signal / stream of additions | | ✓ | | T1 |
|
|
| generated code, confined | | rule | plugins | T3 |
|
|
| visual composition | | | | T2 (no story yet: parked) |
|
|
|
|
Notes:
|
|
|
|
- Google's Photos Library API stopped serving a user's own library in
|
|
2025 (only media the app itself uploaded), as far as we know; that's
|
|
the diigo situation again, and why #118 links a
|
|
[browser-console approach](https://github.com/Ninefrm/console-automation-google-photos/).
|
|
Check before building on it.
|
|
- S1 is the first to ship; S2 is the first unattended one, so it's
|
|
where T1 and narrowed capabilities stop being optional.
|