QQivo

Working together

Who a person is#

A person in Qivo is a name and an email address. Nothing else — there is no job title to keep current, because a title nobody could edit after the seat was created only ever described the day it was made.

The name, though, is now yours to change, and that is a recent thing: it used to have exactly the problem the job title had. Whoever created your seat typed it, and it stood for ever — a nickname, the stem of an address, a misspelling, a surname you have since stopped using. On Settings › Your preferences there is a Your name field: type, press Save, and you are called that everywhere the app draws you, including the letters your avatar falls back to when there is no picture.

It follows you, not the seat: if you hold a place in more than one organization — your own and a customer's who shared a project with you — all of them are renamed together, and so is an invitation still waiting on your address that you have not signed in to yet. One name, because a name that differed between two of your seats would not be a name. Each organization records that the change happened and what it was before.

An org admin can also rename anyone in their organization, by typing over the name on Settings › Organization › Users. That door reaches one thing the other cannot: an agent has no login, so it can never rename itself, and before admins could do it the name an agent was created with was permanent for everybody.

The two are not quite the same act, and the difference is deliberate. Renaming yourself renames you everywhere you hold a seat. An admin renaming you changes their organization's copy — their authority stops at their own organization, so a seat you hold somewhere else is not theirs to touch. If the two ever disagree, changing your own name again settles it everywhere.

One last edge: a seat you are invited to after renaming yourself starts from whatever the person inviting you types. Your name follows you forward from the moment you change it, not backwards into invitations that have not been written yet.

The address does two jobs, and it is required for a person — a seat is claimed by matching a login against exactly that address, so a person without one holds a seat nobody could ever sign in to.

The first job, then, is that it is what someone signs in with: an admin adds a person on Settings › Organization › Users by name and address — that first name is the admin's to type and the person's to change afterwards — and the seat reads invited until that person signs in against it. Until then the address can be corrected; afterwards it is shown read-only, because from that moment it is the address their login is tied to. (An agent is the exception that proves the rule: it has no address at all, because its login is a key rather than a mailbox. See Agents below.)

It is also where their picture comes from. An avatar resolves in three steps, and the first one that answers wins:

  1. A picture you uploaded. Click any avatar you are allowed to change — your own under Settings › Your account › Picture, or, if you are an organization admin, anyone's from a row of the Users list. Hovering veils the picture with a camera glyph to show it can be pressed, and pressing it opens a short menu: it names which of the three steps below you are currently looking at, offers Upload a picture… (or Change picture… if there already is one), and offers Remove picture only when there is an upload to remove. Pictures are scaled down and re-encoded in your browser before they are stored, because an avatar is fetched on nearly every screen. Remove picture puts you back to step 2.

    An uploaded picture is private to your organization. It is stored behind the same rule as the person it belongs to: your colleagues can see it, so can a guest you have invited into the organization, and nobody else — not another customer of Qivo, not a signed-out visitor, not anyone who happens to come by a link. Every view of it is a short-lived signed request; there is no public address for it to leak to.

  2. Gravatar. A free service that serves a picture for an email address. If you have set one there for the address on your seat, it appears here with nothing to configure. Qivo never sends the address itself — only a one-way hash of it. (A Gravatar is public by nature: you put it on that service yourself, and anyone who knows the address can see it. That is the trade for needing no upload — and the switch below turns it off.)
  3. Your initials, on your colour, exactly as before.

So the initials chip is not a placeholder waiting to be replaced — it is the floor everything else is drawn on top of, and a person with neither an upload nor a Gravatar looks precisely as they always did.

If you would rather your organization asked nobody about its people, turn off Settings › Organization › General › "Profile pictures from Gravatar". It is on by default. With it off, no address hash leaves your browser, step 2 disappears for everyone, and uploaded pictures are unaffected.

  • Everything is live. Any teammate's change — tasks, comments, drags, settings, membership — appears in your browser within a moment. Your own edits apply instantly and, if the server refuses, roll back visibly with a toast ("You don't have permission for that — reverted") — the UI never pretends a write succeeded.
  • Activity is narrated on the task itself — the Activity section of the task window, oldest at the top and newest at the bottom, like the comments it shares a spine with. Every entry names the actor — an agent signs its own API writes under its own name, and "Someone" is what stands in for departed members. Field edits name both the old and the new value ("reprioritized … from Medium to High"); API updates carry the same from → to diff ahead of their provenance label (description edits quote a short excerpt of the old text and the new). What tells you something happened is your Inbox (below) — one row per task, with read state that follows you across devices. (There used to be a notifications bell in the top bar as well; it counted the same events with a worse memory, so it went.)
  • Provenance-honest activity: every automated task write is labeled in the activity feed — the agent's own name plus "via the REST API (key name)", or the user's own name "via MCP" — so you can tell human edits from automation, and which automation. (Comments are the deliberate exception on both tiers: a comment is its own feed entry — REST comments post signed by the agent that posted them, MCP comments by whoever the credential is.)

Your Inbox#

The sidebar's Inbox is personal: it collects a message whenever

  1. someone @mentions you in a task description or comment, or
  2. a task you subscribe to changes — you get assigned, its status, priority, title, dates, remaining hours, blocked flag, project or parent change, it's archived or restored, or someone comments on it —

and never for your own actions.

Subscribing is the eye in the task window's top-right corner (§9). Click it and you hear about that task; click it again and you stop. Three things subscribe you without your asking, because each one already said you cared: being assigned the task, being @mentioned on it, and commenting on it. Creating a task does not — a lead who opens a project's worth of them in an afternoon would have signed up for every change anyone ever makes to any of them. Being taken off a task doesn't unsubscribe you either: losing it is news, and the eye is right there when you have heard enough.

So the eye is a real switch in both directions. An assignee buried in a busy task can turn their own messages off, and someone with no claim on a task at all — a lead watching a risk, a reviewer waiting on a fix — can turn them on.

The sidebar's Inbox entry carries an unread count — of tasks waiting on you, not of individual messages (see below) — and (once you click Enable notifications in the inbox) new messages also raise a desktop notification — clicking it brings you straight back.

The page is a split view. Left, your messages. A row says what and where: the project's icon leads it, the task's title tops it with the age beside it (minutes/hours up to a day, then days), and the second line is a breadcrumb — project, then sub-project — so you can see which board the task sits on without opening it. What last happened isn't repeated here: the counter beside the title says how much has arrived, and the task's own Activity section says what it was. A sort picker (newest/oldest), a filter menu (unread only; mentions / comments / changes) and a search field narrow the list — and search still reaches everything a row is holding, including who changed what, as well as the project names now on the row. Selecting a message marks it read — and so does opening the task itself, so the badge and the task window can never tell you two different things.

One row per task, not per event. Everything that happens to a task joins the one row that task has in your inbox. It does not matter what kind of news it is — a comment counts exactly like a status change — and it does not matter whether you have read that row already: a task can never take up two places in the list. The row moves back to the top whenever something happens, and carries a small counter next to the title saying how much has arrived since you last looked. Open it and the task's Activity section, switched to All, enumerates the lot.

Reading a row settles it. The counter goes back to zero and the row keeps just its last message — so a task you have dealt with is one line, not a pile. Anything new after that starts the count again on the same row. Filters and search still reach every message a row is holding, so a mention that landed behind a status change is never lost, and desktop notifications still fire per event.

Rows you have read don't stay for ever. On Settings › Your account you choose how long to keep them — After 1 day, 7 days (the default), 30 days, 90 days, or Never — and a nightly sweep takes the ones whose last message you read longer ago than that. Unread news is never removed, however old it is, and removing a row never touches the task or its comments.

Right-click a row for the three things you'd want on it: Show on the board (leaves the inbox and opens the task where it lives), Mark as read / unread, and Remove. The last two act on the whole row, every message it is holding.

Right, the task window itself. Selecting a row fills the right half with the same window the Board and the Roadmap open — title, permanent ID and actions menu on top, then the description, the Activity thread and the comment box. So a message is not something you read and then go and act on somewhere else: reading it and working on the task are the same surface. The address bar names what the pane holds (/app/<org>/inbox/i/qn-14), so a reload — or a link you saved — lands you back on it. Esc clears the task first and leaves the inbox only on the second press.

Here the window shows its discussion only — the half of the screen it shares with your messages has no room for the details column beside it — led by a read-only Assignee line saying who the task is on, and then the description, which starts collapsed: press Description, or the arrow beside it, to open it and press again to close. Two things stand in for the column here. The breadcrumb over the task name is clickable in the inbox, each part switching to that board. And a pop-out button right beside the name opens the very same window floating over the inbox, with everything the pane left out: status, priority, assignee (editable there), remaining hours, due date, plan, labels, attachments, parent, subtasks and links. It is the same task and the same conversation — reply in either — so closing it puts you straight back on the pane, and Esc closes the pop-out before it touches anything else.

Because the pane is the task window, news that arrives while you are looking at a task is marked read as it lands — you are watching it happen. News on any other task waits, bold, on its own row.

A New line says where you stopped reading. The part you hadn't read is separated from the part you had by a single New rule — drawn before selecting the row marks anything read, so it stays put while you read instead of vanishing under you. It is the same read state the badge and the row dots use, so the two can't disagree; on your next visit there is nothing unread and no line. When the news is a change rather than a comment — nothing in the conversation to sit above — you get a short note saying so instead of a rule pointing at nothing.

Messages are generated server-side, so automation counts too: a REST script that reassigns a task you subscribe to messages you under the name of the agent whose key it used, and an MCP mention arrives as whoever sent it. What you'll never get is noise you can forge or lose — messages can't be created, edited or re-worded by any client, only marked read or unread, or deleted, and nobody but you can see your inbox. Your subscriptions are yours the same way: nobody else can read which tasks you follow, and nobody can sign you up for one. Which row a message belongs to is the server's decision too, and not one anybody can argue with: a message belongs to its task, so gathering them is not a judgement call that could go the other way for one kind of news. While news is unread it is all there; once you have read it, the row keeps the last of it and lets the rest go — the task's own Activity keeps the rest.

✦ What sets this apart — Optimistic UI with honest rollback, an activity feed where automation is labeled as automation instead of hiding behind a bot user, and an inbox whose messages are generated by the database itself — so a change made by a script notifies you exactly like a change made by a colleague.