Shared lists.

A shared list is a file of keywords and links: a Google Sheet, a CSV or JSON file on GitHub, or a CSV or JSON file at any https address. Each person subscribes once: from an invite link, by pasting its address into Wyrd's Shared lists page, or, in an organisation that manages Chrome, through a policy that presets it. From then on their Wyrd re-reads the file on its own, and its keywords work in their address bar next to their own. Everyone types the same word for the same place, and when an address changes, it changes once, in the list.

Setting up a team? Start with Wyrd for teams or the step-by-step guide give your team the same links. This page is the full reference, for team leads and IT admins.

What a shared list is, and is not

• Wyrd has no server and no accounts. It never decides who may read a list: the place that keeps the file decides, exactly as when someone opens the file in a browser tab. A team's list lives in the team's own Google or GitHub account, or on its own web server, under that account's access rules and audit trail.
• A keyword is not a public web address. team/roadmap is not a link anyone can click; it works in a browser that has Wyrd and is subscribed to the list. A short link that anyone can click needs a server that answers for it, and Wyrd deliberately has none.

Views: Family & Friends and Teams

Under Settings → View ("How do you use Wyrd?") each person chooses how much Wyrd's pages show. A view only changes what is offered; switching never deletes anything, and a list someone is subscribed to keeps working in every view.

Where a list can live

A Google Sheet

1. Create a sheet. In row 1 type the headers Keyword, URL, Description and, to group the keywords on the Keywords page, Category. Add one keyword per row. An address with %s is a search.
2. Share it with the people who should use it. Viewer is enough for reading.
3. Open the tab that holds the list and copy the address from the browser's address bar. Subscribe yourself, then send the team the list's invite link (Copy invite link on its row), or the address.
4. Each person opens the invite link, or opens Wyrd's Shared lists page and pastes the address; they look at the preview and subscribe. Chrome asks once whether Wyrd may read docs.google.com and googleusercontent.com, where Google delivers the file from.

Wyrd never opens the sheet as a page; it asks Google for that one tab as CSV. Start a list of your own, under the subscribe form, has a template to copy straight into a new sheet.

If the preview says "No access" for someone who can open the sheet in a tab, publish the tab instead: in the sheet, File → Share → Publish to web, choose the tab and Comma-separated values (.csv), and hand out that link. Anyone with that link can then read the list, signed in or not, so treat the link like a password; stop publishing to withdraw it for everyone.

A file on GitHub

1. Put a JSON or CSV file in a repository; a private one is recommended.
2. Copy the file's normal address, for example https://github.com/acme/links/blob/main/team.json. Use a branch address (…/blob/main/…), not a permalink with a long commit number, or the list never updates. A branch name without a slash is safest.
3. Paste it into the subscribe form and choose how Wyrd signs in: the GitHub sign-in the browser already has, or a token.

For a token, each reader makes a fine-grained personal access token on GitHub (Settings → Developer settings → Personal access tokens → Fine-grained tokens), limited to the one repository, with Contents: Read-only and an expiry date. A public repository needs neither.

A file at any https address

Any https:// address that returns a JSON or CSV file works: an intranet page, a static file host, a raw gist link. http:// is refused without exception, because a token must never travel in clear text. If the site needs a sign-in, choose browser sign-in; if it accepts a bearer token, enter one, and Wyrd sends it to that address only. The address may not contain a user name or password.

The file formats

CSV

With a header row, the header decides which column is which, in any order:

Keyword,URL,Description,Category
roadmap,https://example.com/roadmap,This year's roadmap,Planning
wiki,https://example.com/wiki/search?q=%s,"Search the wiki, all spaces",Docs
!namespace,team,,
!category,Planning,Where we are going,
!contribute,https://example.com/suggest-a-keyword,,

Without a header row, the columns are keyword, link, description (optional) and category (optional), in that order. Quoted cells, commas and line breaks inside quotes, either kind of line ending and a byte-order mark are all understood; blank rows are ignored.

Rows whose keyword starts with ! are settings, never keywords: !namespace recommends the list's short name, !contribute says where additions go, !category gives a category a blurb and an order, !title and !intro give the Keywords page a title and a line under it, and !pattern and !rule set how Wyrd proposes names for new keywords. A column headed timestamp, time, date or submitted marks the sheet as a log of form answers: later rows win, and a row with an empty link takes the keyword back.

JSON

The simple form is one object of keywords and links:

{
  "roadmap": "https://example.com/roadmap",
  "wiki": "https://example.com/wiki/search?q=%s"
}

The wrapped form adds a name, a recommended namespace, descriptions, categories and a contribute link:

{
  "name": "Platform team",
  "namespace": "team",
  "title": "Platform links",
  "intro": "Every link the platform team uses.",
  "contribute": "https://example.com/suggest-a-keyword",
  "shortcuts": {
    "roadmap": "https://example.com/roadmap",
    "wiki": "https://example.com/wiki/search?q=%s",
    "docs": "@wiki",
    "handbook": { "url": "https://example.com/handbook", "description": "The handbook", "category": "Docs/People" }
  },
  "descriptions": { "roadmap": "This year's roadmap" },
  "categories": { "roadmap": "Planning", "wiki": "Docs" },
  "categoryInfo": { "Planning": "Where we are going", "Docs": "Everything written down" }
}

In both formats a link may open several pages (https://a.example | https://b.example) or be an alias (@wiki), which looks in its own list first. A link without https:// gets it.

Namespaces: team/wiki

Every list someone subscribes to gets a short name, its namespace: team, family, platform. After > and Space, team/wiki and team wiki look only in that list, and words after them still fill a search: > team/wiki budget.

• A namespace is 1 to 16 lower-case letters, digits or dashes, starting with a letter or digit, and unique among that person's lists. It is personal: one person's team can be another's platform.
• A list can recommend its namespace (!namespace in a sheet or CSV, "namespace" in wrapped JSON), so the whole team ends up typing the same thing. Wyrd pre-fills it when someone subscribes, and offers it to people already subscribed under another name.

Whose keyword wins

1. Your own keywords: anything you added or edited yourself.
2. Your shared lists, from top to bottom, in the order you set on the Shared lists page.
3. Wyrd's starter keywords that you never changed.

The first place that defines a keyword decides, even for input it cannot handle: if your own bank is a plain page and a list's bank is a search, > bank login is an ordinary web search, exactly as before you subscribed. A list can never take over a keyword of yours; reach the list's version with its namespace, > team/bank login. The Clashes panel on the Shared lists page shows every keyword that exists in more than one place, and which one wins.

Refresh, and when access is withdrawn

Wyrd re-reads every list every 6 hours while Chrome runs, when Chrome starts, when someone presses Preview, Subscribe or Refresh, when a subscription arrives through Chrome sync, and right after a commit made from Wyrd. Each request is https, waits at most 10 seconds and is sent without a Referer.

Moving or renaming the file counts as "access refused": tell subscribers the new address first.

Letting people add keywords

• A Google Form. Link a form with the questions Keyword, URL, Description and Category to your sheet, and put its pre-filled link in a !contribute row. Subscribers then get Add to this list in Wyrd: it opens the form with their answers filled in, and they press Submit themselves. The responses tab keeps every answer, so everyone can see a keyword's history.
• A commit to GitHub. With a token that has Contents: Read and write, Wyrd commits the one added, changed or removed entry to the file's branch, with a message that names the keyword only (Wyrd: add "roadmap"). The rest of the file is left exactly as it was. If the branch only accepts pull requests, Wyrd opens the file's edit page on GitHub instead.
• Your own intake page. A "contribute" link (or !contribute row) to any https page: Wyrd opens it with the keyword, link, description and category in the address.

Tokens for private lists

A token for a list stays on the computer where it was entered. It is never synced, never included in an export or a backup, never written to a log, and never shown again after it is entered; Wyrd only says whether one is saved. It is sent only to that list's host, with no cookies, and redirects are not followed, so it cannot be passed on to another site. It is bound to the exact list address it was entered for, and deleted when the subscription is removed.

It is stored unencrypted, protected the same way as the rest of the Chrome profile and no better: whoever controls that profile could use it. That is why a token should be fine-grained, limited to one repository and to Contents, and given an expiry date, and why it should be revoked on GitHub if a computer is lost.

What a list may contain

• Accepted: http and https links, and @ aliases. Everything else is refused entry by entry, with the reason shown in the preview; the rest of the list still loads.
• Also refused: links with a user name in the address (https://accounts.example@other.example/ reads like one site and opens another), and entries with invisible text-direction characters.
• Limits: 2,000 keywords and 512 KB per list; keywords up to 100 characters, links up to 2,000; descriptions are cut at 200 characters.
• A web page where a file was expected, such as a sign-in page, counts as no access, never as a list. Nothing in a list is ever run as code.

Security advice

A shared list is input you choose to trust, and Wyrd still checks every entry. It cannot know, though, whether payroll points at the real payroll site: anyone who can edit a list can repoint a keyword for everyone subscribed to it.

• Keep editors few; readers do not need edit rights. A Google Form open to many people makes them all editors in effect: restrict it to your organisation, or copy approved answers into the tab Wyrd reads.
• On GitHub, branch protection with required reviews turns every change into a pull request.
• Read the "what changed" notes; an unexpected change to a familiar keyword is the thing to look for.
• For anything sensitive (bank, payroll, admin consoles), a personal keyword cannot be overridden by any list.

Starter packs and pack links

A starter pack is a list of suggested keywords to add once, rather than to subscribe to: some with an address, some for the reader to fill in. It lives where a list does and uses the same formats: CSV with keyword, url, description and category (the url may be empty; a !title row names the pack), or JSON with a name, an intro and entries. The everyday search pack on the Guides and Stories page looks like this:

{
  "name": "Everyday search pack",
  "intro": "Five useful searches to make Wyrd helpful on day one.",
  "entries": [
    { "keyword": "g", "url": "https://www.google.com/search?q=%s", "description": "Search the web with Google", "category": "Search" },
    { "keyword": "yt", "url": "https://www.youtube.com/results?search_query=%s", "description": "Search videos on YouTube", "category": "Search" }
  ]
}

Load one with Start from a pack… in Keyword tools, or offer it on a web page with a link of this form, where the pack's address is URL-encoded:

http://wyrd.internal/?pack=https%3A%2F%2Fexample.com%2Fteam-pack.json

Wyrd opens Keyword tools with the pack filled in. Nothing is read until the person presses Load (Chrome asks for access to that one site), and nothing is added until they tick entries and press Add. wyrd.internal is a reserved name that can never be a real website; for someone without Wyrd the link leads nowhere.

Ready-made packs and list templates, for households, small teams, IT admins, HR, marketing and teams: keyword templates.

Invite links and share links

Invite links: one click to a list

Copy invite link, on a list's row on the Shared lists page, copies an address such as http://wyrd.internal/?list=https%3A%2F%2Fdocs.google.com%2Fspreadsheets%2Fd%2F…%2Fedit. Send it to the people who should use the list. When one of them opens it in a browser with Wyrd, their Shared lists page opens with the list's address filled in and Preview ready. Nothing is read and nothing is subscribed until they press Preview and then Subscribe. If their view cannot take the list (Personal, or a GitHub file or other address in Family & Friends), a banner says which view can and switches only when they press it; if they already have the list, Wyrd says so.

• The link holds the list's address and nothing else: never a token. Someone who needs a token to read the list still enters their own.
• The address is what it is: for a sheet published to the web, anyone who has the address can read the list. Send such a link only to people who may read it.
• It only does something in a browser that has Wyrd; elsewhere wyrd.internal leads nowhere. For people who do not have Wyrd yet, send the list's address too.

Share links: one keyword

Copy share link, next to a list's keyword, copies an address such as http://wyrd.internal/?q=team%2Fwiki. It contains the namespace and the keyword, never a token and never the destination, and it works only for people who have Wyrd and the same list: they see Wyrd's confirmation page and press Open. It keeps working when someone named the list differently. There is no share link for a keyword of your own, which exists only in your browser.

For IT admins: preset lists with Chrome policy

If your organisation manages Chrome (Google Admin console, Group Policy, a configuration profile), you can give everyone the same shared lists without anybody subscribing by hand. Wyrd reads a policy called SharedLists from Chrome's managed storage for extensions. This is a policy for Wyrd, not a permission: installing or updating Wyrd shows no extra warning.

• Set by your organisation. A preset list appears on everyone's Shared lists page, marked that way, before their own lists (their own keywords still win). They cannot remove, move or rename it.
• It is read like any list: every 6 hours, at start-up and on Refresh, and at once when the policy adds it. It goes away, with its downloaded keywords, when the policy no longer names it. It is not synced to people's other computers.
• Public addresses only. A preset list is always read without the browser's sign-in and without a token: a Google Sheet published to the web as CSV, a file in a public GitHub repository, or a JSON or CSV file on an intranet server that does not ask for a login. A list that needs a sign-in or a token cannot be preset; people subscribe to it themselves, and an invite link makes that one click.
• Each person allows the site once. Chrome still asks every person whether Wyrd may read the list's site: until they press Grant access on the list's row, the list is not read. Tell people to open Shared lists once after the rollout.

SharedLists is a list of up to 10 entries, each with:

An entry that breaks these rules is skipped; the others still apply. If a person already subscribed to the same address themselves, their own subscription stays and the preset list is not added twice.

Wyrd's extension ID is jpoppmijoimaipaibckkkibejgohjmdn. In the Google Admin console, add Wyrd by its ID under Devices → Chrome → Apps & extensions for the organisational unit, and in its settings, under Policy for extensions, paste the value. The example uses two made-up lists; replace the addresses and names with yours:

{
  "SharedLists": {
    "Value": [
      { "url": "https://docs.google.com/spreadsheets/d/e/2PACX-EXAMPLE/pub?output=csv", "namespace": "acme", "label": "Acme links" },
      { "url": "https://intranet.example.com/wyrd/engineering.json", "namespace": "eng", "label": "Engineering" }
    ]
  }
}

The Admin console wraps each policy value in "Value". On Windows the same list goes, as JSON on one line, in a string value SharedLists under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\3rdparty\extensions\jpoppmijoimaipaibckkkibejgohjmdn\policy; on macOS, in a configuration profile for the preference domain com.google.Chrome.extensions.jpoppmijoimaipaibckkkibejgohjmdn; on Linux, in a JSON file in /etc/opt/chrome/policies/managed/. Menus and field names differ between versions of these tools: check them in your own admin console.

Check that it arrived. On a managed computer, open chrome://policy and press Reload policies: Wyrd's extension ID should be listed with SharedLists and its value, without an error. Then open Wyrd's Shared lists page: the list shows Set by your organisation; press Grant access once and its keywords work. To take a list away, remove its entry from the policy. The policy gives the organisation no access to anything in Wyrd: it only names lists to read.

Security and compliance questions

• Certification. Wyrd is not SOC 2 certified and makes no such claim. It is a browser extension without a server: the developer receives no customer data, because there is nowhere for it to go.
• Where the data is. The list stays in your Google account, GitHub organisation or web server, under your access rules and audit trail. Each subscriber's browser keeps a copy of the keywords it downloaded.
• What Chrome asks. Access to the list's site only, one site at a time, when someone presses Preview; removing the list gives it back. Every permission is explained in permissions and data.