Bring in

Settings → Bring in brings in what someone kept in another tool, at the time they saved it. It works as a dig, not a transfer: a Pocket export of 2016–2025 arrives as nine years of layers, so the time rail, unseen and resurfacing have something to work with on day one.

What it reads

A dropped or chosen file is recognised by what's inside it, never by its name:

• The Pocket formats come from Pocket's documentation, not from a real export, so one may fail to read. If it does, tell us.
• The Keep format was checked against a real Takeout (2026-10). Checklists (listContent) and voice notes weren't in it, so those follow Takeout's documented shape. Keep has no export button; the page's "Where do I get an export?" says to use Google Takeout with only Keep ticked.
• Only http/https addresses come in as links. Bookmarklets, chrome://, file:, data: and Firefox's place: entries are counted as skipped.
• Limits:
  • 64 MB of text per file, read or unzipped;
  • 4 GB of attachments in a zip (Keep's pictures and recordings), held as Blobs, which the browser can keep on disk. A zip is read in 4 MB pieces, never whole; a zip that can't be streamed (an entry stored with its size after it) is read whole if it's under 64 MB;
  • 200,000 records;
  • 20 folder levels kept;
  • titles one line, up to 500 characters.

What arrives

• One item per address. An address found in two sources (Pocket and bookmarks) is one item with a line of history from each. The same address saved twice in one source counts once: its first save, with every tag from both.
• At the time it was saved there. The capture's time is the original save. The item's creation date moves back to its earliest known save, including when it was already in midden. Times outside 1990 to tomorrow are dropped: the item counts as undated.
• Undated items (Safari keeps no dates) come in as saved when they were brought in. They show in their own "no date" layer, never in a guessed year.
• Tags arrive as tags. They were declared in the other tool, so they mean the same thing here. Folders never become tags: they're kept as provenance on the capture, and the card's history says "bookmarked in Bookmarks bar › Recipes".
• Read status (Pocket) is kept on the capture: "saved in Pocket, read there".
• A Keep note becomes what it is:
  • a note that is one address alone is a link, titled by the note's title, or by Keep's preview when the preview is of that address;
  • any other text is text, the note's title as its first line; a checklist is text with ☐ and ☑ lines; a note with only a title is that title;
  • each picture or recording is its own item, named by the note's title;
  • Keep's link previews (annotations) are used only when the note has no text. Otherwise the links are already in the text, and Keep fetched the previews signed out (a members' page previews as "Login");
  • what one note held is kept together (a kept relation, as from a card), so the text and its picture find each other;
  • trashed notes are left out; pins, colours and archiving say nothing midden keeps;
  • its history says "kept in a note", and a compact row "in a note · 2019".
• Left out:
  • Safari's starting Favorites (undated front pages of Apple, iCloud, Google and the others Safari ships with), because nobody chose them;
  • anything in midden's trash, which stays there untouched;
  • an export already brought in, which adds nothing a second time.

What looks like a secret

Before a dig runs, its warning lists what in it looks like a secret. It works by rules, not a model. In a note's text:

• a sheet of backup codes: 8 or more groups of 4 to 10 characters with digits or symbols, making up most of the note;
• a key in the shape its service gives it: sk-…, AKIA…, ghp_… and the other GitHub tokens, xox…- (Slack), AIza… (Google), a BEGIN … PRIVATE KEY block, a sign-in token (JWT, eyJ….eyJ….…);
• a line that starts password:, pin:, passcode:, passphrase: or secret: (or =);
• only lowercase words, 12, 15, 18, 21 or 24 of them: a wallet's recovery phrase.

In a link's address:

• a password before the site (user:pass@host);
• a parameter, in the query or after #, named for a token, signature, password, secret or session (access_token, token, X-Amz-Signature, sig, pwd, client_secret and so on), with a value that could be one: for a password, 4 characters or more; otherwise 16 or more with a letter in it, and for a plain sig or signature, not only hex (a search engine signing its own query);
• key= with a long value of letters and digits, or code= on a sign-in path (oauth, callback, login and the like);
• a sign-in, reset, verify or invite path with a long random part in it;
• any of the key shapes above.

Only strong findings are put to you here. A weak one (a checkout's token, a session id, a sign-in code: Might be sensitive) comes in, and waits in the heap's review, so a big dig isn't a page of rows. Titles and pictures aren't checked here: a picture's text is read once it's in the heap, and checked then.

Each flagged item shows its first line (a link: its title, or else its site), when it was saved, why it was caught, and its opening with the rest hidden (a link: the address, with what it carries hidden). show reveals it. Each starts at leave out: fail closed, so nothing that looks secret comes in unless you choose. The choices are:

• leave out: not brought in at all;
• to the hoard: sent to the hoard as a note (with its tags; a link's address is the note's text), never entering midden. A locked hoard keeps it until you unlock. If the hoard doesn't take it, it's left out instead. Only offered in the extension, and only usable with a hoard that takes notes from midden;
• bring in: like the rest.

The warning's count leaves out what's held back. The page always says that "midden looks for a few shapes of secret; it can miss others", and never that the rest is clear. The reading at the end says how many were left out, went to the hoard, are waiting for it, or couldn't go.

Finding what came in

open your heap, at the end of a dig, opens the heap narrowed to that dig: a filter chip ("dug in: Google Keep · Oct 29") and, the first time, a line on what you're looking at. The view includes the items it added and the items already here that it gave a line of history. Every card works as usual (tag, note, keep together, the hoard, the trash), and ✕ on the chip shows the whole heap. Settings → Data & storage → Imports has a show on each import that opens the same view later. A .midden file's import shows the items it added, as "imported: its name".

Two times on an imported capture

An imported capture has its save time, from the source, and its arrival time.

• What counts as a change uses arrival:

  • an item coming back after it was deleted on another device;
  • leaving the trash;
  • the unseen lens;
  • what's "yours" after an import.

  Without this, a 2019 bookmark brought in today would lose to a deletion made yesterday on another device, and quietly disappear at the next sync.

• The time axis uses the save time: the rail, history, "recent" and "circling". A dig of old links doesn't look like a burst of new activity.

• An import counts as a sign of you. Imported items join unseen only once they've gone untouched for the usual time after the dig.

Taking a dig back

Each dig is recorded as an import, on this device only. It can be undone from the end of the dig, or later from Settings → Data & storage → Imports.

• Items it added that haven't been touched since are deleted for good, here and, through sync, on other devices.
• Items captured again or noted since are kept.
• Items that were already in midden keep the history line and earlier date the dig gave them. The tags it added come off, unless they were put on again since.
• Why the history stays: captures merge between devices by union and have no deletion record. Removing one here would come back at the next sync. The line is also true: it was saved there, then.

The reading

At the end, the page says what came up, using only what the sources know:

• the years and the biggest one;
• a subject that went quiet: a title word with at least 5 items and none in the last two years, over a span of four or more years;
• how many were saved more than once;
• for Pocket only, how many were never marked read;
• the tags it brought;
• your own folders (a browser's top-level folders don't count);
• how many were undated, and how many stayed in the trash.

The bookmarks permission

bookmarks is an optional permission. midden asks for it only when bring in this browser's bookmarks is clicked:

1. midden asks for the permission;
2. it reads the bookmark tree once;
3. it gives the permission back.

midden keeps no access to bookmarks between uses, and never writes to them. Declining the prompt reads nothing.

Not yet

• Page previews and titles for dug links: links without a title show their address.
• Keeping up with new bookmarks as they're made.
• Raindrop and other tools' exports.
• A Takeout split into parts, or saved as .tgz: each .zip part can be brought in on its own, but a note whose attachment landed in another part loses it (counted as skipped).

Once links are in, the links arrangement and the from: / in: / site: / is: search words are how to look through them: see Links and where they came from.