Tags are how work is organised in Kythene, and they're also how access is controlled. One mechanism doing both jobs is deliberate: scoping a project scopes its memory and its published work together, in one place.
Projects are tags
A project is a tag of a distinguished project kind. Everything else is a plain label.
Projects are free and cheap, so make one per repo, per client, per initiative. One project per repo is the setting that keeps recall sharp - untargeted recall on a busy workspace returns a firehose.
kythe projects # list them
kythe projects "acme" # searchIn practice you name the project once - "on the acme project" - and your instance carries it through publish, remember and recall for the rest of the session.
What a tag controls
| Tag state | Who can see the work carrying it |
|---|---|
| Open (default) | Everyone in the workspace |
| Internal-only | Workspace members only - excluded from every anonymous view |
| Password-protected | Anonymous viewers who have the password |
| Private to members | Only the named members of that tag |
| Share code | A named outsider, with no account - view, comment and approve |
Password-protection and private-to-members are mutually exclusive: private content is never anonymously shareable.
On top of tag visibility, an author can keep an individual item private to themselves. Owners and admins retain an audit-logged oversight view of hidden content, so a workspace's stewards can always account for what's in it.
Where it lives in the app
Settings -> Projects & tags. It used to be labelled "Tags & sharing", which left projects - a first-class idea you see chips for on every screen - with no name anywhere in the product. One word per concept, and the same word here and there.
Setting it up
Tag access is managed in the workspace's tag settings. Mark a tag internal, give it a password, make it private and add the members who should see it, or mint a share code for an outsider.
Because memory carries tags too, a private project tag hides both the project's collections and its memories from everyone outside it - including from other people's recall. There's no second access model to keep in step.
Tidying up
Tags sprawl. Three operations keep them under control:
kythe tag rename <name-or-id> <new-name>
kythe tag merge <source>... --into <target>
kythe tag delete <name-or-id>Merge is the one you'll want most - api, apis and API becoming one tag without re-tagging anything by hand. Delete removes the tag; it doesn't delete the work that carried it.
Two kinds of tag are held back from all three, and from every tag list, filter and picker: the internal tags behind memory and behind each wiki. A wiki's access lives on a tag, but you manage it from the wiki's own settings, and rename, merge and delete refuse it - nobody should be able to dismantle a wiki from a screen that never says the word.
Your instance can do this too:
"We've got both
infraandinfrastructureas projects - merge them intoinfra."
Naming
A few habits that pay off:
- Lowercase, hyphenated, singular.
client-acme, notClient Acme Projects. - One tag per engagement where an outsider is involved - it makes scope obvious and revocation total.
- Write the taxonomy into your workspace guide. Instances read it and will then tag things the way you would have, which is far cheaper than fixing tags later.