Fileshare Token
Overview
The FSHR (Fileshare) token represents sharing a file with another user. It grants the recipient access to view or edit the specified file.
Token Structure
| Field | Type | Required | Description |
|---|---|---|---|
iss |
identity | Yes | The identity sharing the file |
aud |
identity | Yes | The recipient of the share |
iat |
timestamp | Yes | Issue time |
k |
string | Yes | Signing key ID |
t |
string | Yes | Type with optional subtype: FSHR, FSHR:COMMENT, FSHR:WRITE, FSHR:DEL |
sub |
string | Yes | File ID being shared (e.g., f1~abc123) |
c |
object | Yes | Share content (see below) |
Subtypes
| Type String | Granted access | Description |
|---|---|---|
FSHR |
read (R) |
View-only access (default) |
FSHR:COMMENT |
comment (C) |
View and comment |
FSHR:WRITE |
write (W) |
Edit access (also used for admin shares) |
FSHR:DEL |
— | Revokes a previous share |
Content Schema
| Field | Type | Required | Description |
|---|---|---|---|
contentType |
string | Yes | MIME type (e.g., application/pdf) |
fileName |
string | Yes | Original filename |
fileTp |
string | Yes | File type: BLOB, CRDT, or RTDB |
File Types
| Type | Description |
|---|---|
BLOB |
Static binary file (images, PDFs, etc.) |
CRDT |
Collaborative document (real-time editing) |
RTDB |
Real-time database document |
Content-Addressing
This token is content-addressed using SHA-256:
- The entire JWT token (header + payload + signature) is hashed
- Action ID format:
a1~{base64_hash} - See Content-Addressing & Merkle Trees for details
Database Key
The database key for a fileshare token is [t, sub, aud]
Purpose: This key ensures that only one active fileshare exists per (file, recipient) pair. The key components are:
t: Token type (FSHR)sub: Subject (the file being shared)aud: Audience (the recipient)
Example:
- Alice shares file with Bob → Stored with key
["FSHR", f1~file123, bob.example.com] - Alice updates the share → New token with same key, previous one is marked deleted
- Only ONE active fileshare of the same file to the same recipient
Examples
Read-Only Share
User @alice.cloudillo.net shares a PDF with @bob.cloudillo.net (read-only):
| Field | Value |
|---|---|
| iss | alice.cloudillo.net |
| aud | bob.cloudillo.net |
| iat | 2024-04-13T00:01:10.000Z |
| k | 20240101 |
| t | FSHR |
| sub | f1~7NtuTab_K4FwYmARMNuk4 |
| c.contentType | application/pdf |
| c.fileName | report.pdf |
| c.fileTp | BLOB |
Write Access Share
User @alice.cloudillo.net grants edit access to a collaborative document:
| Field | Value |
|---|---|
| iss | alice.cloudillo.net |
| aud | bob.cloudillo.net |
| iat | 2024-04-13T00:01:10.000Z |
| k | 20240101 |
| t | FSHR:WRITE |
| sub | f1~collaborative_doc_id |
| c.contentType | application/vnd.cloudillo.doc |
| c.fileName | Team Notes.quillo |
| c.fileTp | CRDT |
Revoke Share
User @alice.cloudillo.net revokes Bob’s access:
| Field | Value |
|---|---|
| iss | alice.cloudillo.net |
| aud | bob.cloudillo.net |
| iat | 2024-04-13T00:05:00.000Z |
| k | 20240101 |
| t | FSHR:DEL |
| sub | f1~7NtuTab_K4FwYmARMNuk4 |
Integration with References
File shares can be combined with references for public sharing:
- Create FSHR action to share with specific user
- Or create a reference with
type: share.filefor public/guest access - Reference tokens support
accessLevel: readoraccessLevel: write
Access Control Flow
A non-DEL share requires the recipient to accept it. On receipt the action rests at status C (confirmation required); only on acceptance does the recipient’s server create the shared file entry and cache the access level. FSHR:DEL is processed without confirmation.
See Also
- Files API - File management endpoints
- References API - Public share links
- CRDT - Collaborative document editing
- RTDB - Real-time database access