> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mauvely.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Sharing files

> Share a file or folder with a named Mauvely user, or by link with an optional password, expiry date and download limit — and what revoking really does.

Two ways to share, with different guarantees.

<CardGroup cols={2}>
  <Card title="With a named person" icon="user">
    They need a Mauvely account with a Cloud vault. The key is wrapped so only they can open it.
  </Card>

  <Card title="By link" icon="link">
    Anyone with the URL. Optionally protected by a password, an expiry date and a download cap.
  </Card>
</CardGroup>

Sharing a **folder** shares everything inside it, now and in future — that falls out of how the
keys are structured rather than being a policy.

<Note>
  Sharing the same folder with five people works, but if a team needs a shared place to *work*
  rather than a folder to read, a [workspace](/cloud/workspaces) is the better shape — it has its
  own storage allowance and its own chat, and members are managed in one list rather than per
  folder.
</Note>

***

## Sharing with a named person

Enter their email address and choose a role. Your browser wraps the item's key to their public
key, so only their private key can open it. The server sees only the wrapped result.

### Roles

| Role            | Can                            |
| --------------- | ------------------------------ |
| **Can view**    | Read and download              |
| **Can comment** | Read, download and leave notes |
| **Can edit**    | Change and replace the file    |

<Warning>
  **Roles are a server guarantee, not a cryptographic one.** Anyone who can view a file necessarily
  holds the key that decrypts it — that is what viewing is. Nothing stops a viewer keeping their own
  copy, and no key hierarchy could.

  What *is* enforced is that a viewer cannot write. Uploads, renames, moves and deletes are all
  checked server-side against the role.
</Warning>

### If they have no vault yet

You can still invite someone who has never opened Cloud. The invitation is recorded and they are
shown as *invited*, but nothing is readable to them until they set up a vault — there is no public
key to wrap the file's key to yet. Once they do, the share completes.

They receive an email invitation. Accepting adds the item to their **Shared with me**.

### Fingerprints

The share dialog shows the recipient's key fingerprint, and pins it at the moment you share.

If their key later changes, Cloud says so loudly — *their encryption key changed since you shared
this*. Investigate before dismissing it. This is the mechanism that makes a substituted key
detectable; see [Security](/cloud/security#sharing-with-a-named-person) for what it does and does
not prove.

***

## Sharing by link

A share link carries a secret in the part of the URL after the `#`. Browsers **never transmit that
part** — not in the request, not in a referrer header, not in any server log. The server can serve
the file without ever being able to read it.

### Options

| Option             | Effect                                           |
| ------------------ | ------------------------------------------------ |
| **Role**           | View, comment or edit, as above                  |
| **Password**       | The recipient must supply it                     |
| **Expiry**         | The link stops working after this date           |
| **Download limit** | The link stops working after this many downloads |

Cloud suggests a strong password for you. All the options are editable after the fact.

### About the password

It is enforced **twice, independently**:

* The password is folded into the key that unwraps the file, so the encrypted data is useless
  without it even to someone holding the entire URL.
* Separately, the server checks a verifier before it hands out anything at all, so an anonymous
  caller never receives material to attack offline.

Neither layer is load-bearing on its own. The server-side check is rate-limited to ten attempts an
hour per link — this is the one place in Cloud where a person-chosen secret faces guessing.

### Managing links

**Shared by me** lists every link you have created, with its view and download counts, and warns
about links expiring soon. From there you can edit or revoke any of them, or revoke every link at
once.

***

## Revoking

Revoking stops the server serving that person or that link, immediately and completely.

<Warning>
  **Revocation cannot un-know a key somebody already has.** Anything already downloaded stays
  readable. Anything they already decrypted stays decrypted.

  Revoke to stop future access. If the content itself has to become unreadable, replace the file
  and delete the original.
</Warning>

## Removing yourself from a share

Anything shared with you can be declined before you accept, or removed afterwards, from **Shared
with me**. Doing so removes your access, not the owner's file.