Collaboration
Datasets and specification drafts can be shared with other people and discussed through comments.
Sharing and roles
Datasets, specification drafts and published specifications are shared the same way: open the item, click the Sharing tab in the sidebar, add a person by the email on their profile, and choose a role.
| Role | Can do |
|---|---|
| Owner | Everything: content, sharing, role changes, deletion |
| Editor | Change the content, not who has access |
| Viewer | Read |
Who owns what you create
The person who creates a dataset, a draft, or a published specification is its first owner, recorded as a membership the moment it is created, on every path: the web interface, the REST API, the MCP tools, a hub push from metaseed, and an import. Ownership is a membership like any other, so it can be handed over. One rule decides who may do what: an explicit membership decides; failing that, the creator owns the item; failing that, the person whose account the item lives in owns it; failing that, a collaboration grant on the item gives everyone in that collaboration its role. An account belongs to one person, so the account rule is the item's home; the collaboration grant is the only group rule.
Datasets created before memberships were recorded at creation were given their account's user as owner when the rule arrived; where that user already held a lesser role on the dataset, the role was raised to owner rather than duplicated.
Every page of the web interface reads that rule, and so does the REST API when it is given a dataset's id. Two paths do not, and are scoped to your own account instead: the REST list of datasets together with every REST specification route, and the MCP tools. An item shared with you, or granted to your collaboration, is therefore reachable in the browser but not yet through a token or an agent.
The number on the Sharing tab is how many other people and collaborations have access: it leaves you out, so an item nobody else can reach shows no number. Only an owner can add someone, change a role, or remove access. Anyone can remove themselves, which is how you leave something shared with you.
Handing something over
Make the other person an Owner, then remove yourself. Both of you can be owners in the meantime, and the item keeps working throughout.
An item always keeps at least one owner: the last one cannot be demoted, removed, or leave. Without that rule an item can end up with nobody able to share or delete it, recoverable only by an administrator.
Access is per item. Sharing one dataset grants nothing else, and sharing a published specification lets a colleague edit and re-publish it without giving them your datasets.
How an email is resolved
Each person has their own account, and sharing reaches across accounts: the person you name does not have to be a colleague in any other sense.
- The address is matched without regard to capitalisation.
Ada@Example.organdada@example.orgname the same account. Addresses are stored lowercased; the profile page still shows the address exactly as your identity provider reports it. - One account exists per address, so a share never has to choose between candidates.
- The person must have signed in to the hub at least once. An account is created on first sign-in, and there is nothing to share with before that. If the hub says no account uses an address, ask them to sign in once and try again.
Collaborations
The hosted hub authenticates through SURF Research Access Management (SRAM), where people are organised into collaborations, each with one or more groups. SRAM reports a person's membership at sign-in as eduperson_entitlement URNs: urn:mace:surf.nl:sram:group:<organisation>:<collaboration> for the collaboration itself, and urn:mace:surf.nl:sram:group:<organisation>:<collaboration>:<group> for each of its groups the person is in. A member of a collaboration who is in none of its groups is reported by the first form alone, and is a member like any other: listed under Collaborations, shown on their own profile, and reached by a grant to the collaboration. The hub uses them for two things: finding the people you work with, and sharing an item with a whole collaboration at once. A local instance authenticates through Keycloak, whose development realm emits the same URNs, so everything here works locally.
Bringing your own collaboration
Collaborations, their members and their groups are managed by SURF in SRAM (sram.surf.nl), not in the hub; joining, leaving and inviting happen there. Any SRAM collaboration can use the hosted hub: an admin of the collaboration connects it to the Metaseed Hub application in SRAM. Its members can then sign in, are listed to each other under Collaborations, can share items with the whole collaboration and publish a specification to it alone. A group named after a repository integration (ena, pride, brapi, metabolights, seek or dcat) enables that integration for its members, also when SRAM reports it with a prefix such as metaseed-seek (Features and SRAM groups). The Collaborations page summarises this in an info box.
Your collaborations
The hub does not keep its own list of who is in which collaboration. It takes a reading: the group URNs your identity provider reported, and when it read them. A sign-in takes one and replaces whatever was there, so leaving every collaboration takes effect at your next sign-in. Opening any page also takes one when there is none or it has gone stale, which is what saves a session older than this feature from never having one. Your profile lists the result under Your collaborations with the time it was read.
The snapshot exists because two things cannot be answered from the sign-in token alone. Listing the people in a collaboration needs everyone's membership, not just yours. And a request made with a hub personal access token, which is one way metaseed and MCP clients call the hub, carries no entitlements at all, so without the snapshot a dataset shared with your collaboration would be invisible to those clients.
A reading older than the configured limit (MEMBERSHIP_MAX_AGE_DAYS, 30 by default) is not trusted: it no longer grants access and no longer lists you among a collaboration's people. This bounds how long someone who has left a collaboration keeps reaching its items through an access token.
Seeing no collaboration means one of three things, and the page says which:
| What you see | What it means |
|---|---|
| The hub has not read your collaborations | No reading has been taken. Sign out and in again. |
| The reading is too old to trust | It grants nothing until it is taken again. |
| Your identity provider reported none | A reading was taken and named no group. |
A hub personal access token carries no group membership at all, which is why the reading exists; a request made with one therefore never takes a reading, and never clears the one you have. A SRAM application token is different: SRAM answers every check with your current groups, so a request made with one takes a reading like a sign-in does.
Collaborations
Collaborations in the header lists every collaboration you are in and, for each, the members who have signed in to the hub at least once and chosen to be shown there, with the name and address on their profile and when they last signed in. You see only the collaborations you belong to. Someone who has never signed in is not listed, because the hub has no record of them; SRAM itself remains the authoritative list.
The email field on the Sharing tab suggests these people as you type, so sharing with a colleague no longer means asking them for the address on their profile.
Your name and address are shown to a collaboration only after you say so. For each collaboration you have not answered for, the hub asks Do you want to share your profile data (name and email) with this collaboration?, on the page you land on after signing in and on the collaboration's card under Collaborations, with Yes, share and No. Either answer is recorded and the question stops; a Share my name and email with this collaboration tick box on the card lets you change it later. Until you answer yes, your entry is in that collaboration's list for you alone, marked not shared with the others, and the Sharing tab does not suggest you to its members. The answer is per collaboration and holds across sign-ins. It changes nothing else: you see the list either way, anyone who knows the address on your profile can still share with you, and grants to the collaboration reach you as before, because membership itself is SRAM's.
Publishing to a collaboration
A specification can be published so that only a collaboration's members see it, which is the middle ground between a private draft and a release to the whole hub. See Who can see it.
Sharing with a collaboration
On the Sharing tab, under Collaborations, an owner can grant a whole collaboration a role. The choice lists the collaborations the owner is in. A grant gives every member of the collaboration the role Editor or Viewer; Owner cannot be granted to a collaboration, because ownership is what lets a person share, hand over and delete, and an item whose owners are "whoever is in a group this month" cannot keep the last-owner rule. An owner can change a grant's role or remove it.
A grant is a fallback. A person's explicit membership on the item always wins, so someone in the collaboration can still be given a different role individually. The item's creator and the account it lives in stay owners regardless of any grant.
Items reachable through a grant appear in your dataset and specification lists like items shared with you individually, with the collaboration named. They appear for a person only while their membership snapshot is fresh, as described above.
Comments
The Comments tab provides threaded discussion on a dataset.
- Write a comment and click Post.
- Reply to a comment to start a thread. Replies nest up to two levels deep.
- React to a comment with Like or Dislike.
- Delete a comment you authored.
Specification drafts have their own Comments tab that works the same way, and so does a published specification: a release can be discussed by everyone who can see it, which is the collaboration it was published to, or every user of the hub. Comments on a release belong to that version: a new version starts with none, and forking a specification into a draft does not carry them over. Someone who cannot see a specification can neither open it nor read or write its comments.
Notifications
The hub tells you about things that happened to your items while you were not looking. The bell in the header shows how many notifications are unread and opens the list. Each entry names what happened, who did it and when, and links to the item where you can still open it. Opening the list marks every entry as read. Entries are kept for 90 days.
You are notified when
- someone shares a dataset, a specification draft or a published specification with you, changes your role on it, or removes your access;
- someone comments on a dataset or a draft you own, or on a specification you published, or replies to a comment of yours;
- someone shares an item with a collaboration or group you are in, or publishes a specification to one.
Administrators are also notified of server errors.
You are not notified of your own actions, and one action produces at most one entry per person: the owner of a dataset who is also the author of the comment replied to gets the reply, not a second entry for the comment. Who is in a collaboration is read from the membership recorded at each person's last sign-in, so someone who has not signed in since joining is not notified. Changing the role of a collaboration grant, or removing one, produces no notification, and neither does publishing a specification to every user of the hub.
The count on the bell is refreshed once a minute while a page is open. The list is part of the web interface; a client using an access token (metaseed, MCP clients) cannot read it.
Presence
Who is in a dataset room is kept in Redis, not per process: each instance writes its own connections into a per-room sorted set scored by a heartbeat timestamp, and reads the whole set back when presence is rendered. An instance that dies stops refreshing its entries, and they age out after three missed heartbeats — so a crashed process's users disappear from presence without any cleanup handshake. Without Redis (single-process development), presence falls back to the process's own connection list, which is then also the whole truth.