Security & Architecture
This page explains CollectiveTap's security model at a high level — without exposing operational details that would increase attack surface.
Server-first architecture
CollectiveTap is built around server-authoritative state. The server is the source of truth for each link's data, and clients render what the server returns.
Typical link shape: /a/:tool/:id
No accounts, no passwords
CollectiveTap does not require accounts, passwords, or a user identity database. This reduces the amount of sensitive identity data the system needs to hold and defend.
Your access is defined by the link you have — especially its capability token.
Capability-based access model
Access is controlled using signed capability tokens ("caps") embedded in URLs. Caps determine what actions are allowed (for example: read-only vs read-write).
- Caps are part of the URL. Sharing a URL can share its permissions.
- Caps are signed. Clients cannot forge new permissions.
- Caps can expire. Some access may stop working when caps expire.
You'll often see caps as a query parameter like ?cap=....
Signed tokens (integrity over secrecy)
The security model emphasizes integrity: the server validates that a cap is authentic and unmodified before allowing protected actions. This helps prevent permission escalation from the client side.
Practical implication: treat edit links as sensitive, because the permission is carried by the URL.
Expiring links
Links are designed to be lightweight and temporary by default. Most links automatically expire after approximately 90 days unless extended. This helps limit long-term accumulation of live data.
Expiration affects the link's availability — it is not a guarantee of immediate deletion of all cached artifacts.
Rate limiting and abuse prevention
CollectiveTap uses abuse-prevention controls such as rate limiting. These protections are designed to reduce spam, automated misuse, and destructive traffic patterns.
Full IP addresses (IPv4/IPv6) may be collected and retained indefinitely for security and abuse prevention.
Operational thresholds and enforcement rules are intentionally not published.
Deterministic state
Tools are designed so state updates are predictable and consistent. In practice, this means the server applies changes in a controlled way and returns the resulting state for clients to render.
This reduces "split brain" behavior where different devices disagree about what is true.
OG image rendering and caching
CollectiveTap supports OG-first sharing: links can generate preview images suitable for messaging apps and social platforms. These images are pre-rendered and cached to improve reliability and performance.
- OG PNG images are stored in Supabase as cached render artifacts.
- Cached images may persist independently of link expiration due to caching behavior.
- Preview versioning may be used so clients can request the most recent cached render.
Bucket names, internal paths, and storage keys are intentionally not disclosed here.
Hub aggregation security model
Hub is an aggregation layer that helps people navigate multiple tool links in one place. Hub-level access controls the Hub view, while child links retain their own capabilities and permissions.
- Hub link visibility: sharing a Hub can expose linked-card context to everyone with that Hub URL.
- Capability boundaries: child tools still enforce their own read/write caps.
- Admin links are sensitive: Hub admin URLs should be treated like passwords and not posted publicly.
Infrastructure-level security practices
CollectiveTap relies on established infrastructure providers for hosting, storage, and database services. Security controls include standard protections such as transport encryption, access controls, and provider-managed hardening.
Responsible disclosure
If you believe you've found a security issue, please report it via the contact channel and include clear reproduction steps. Avoid testing against other people's links or attempting to access data you do not control.
Contact: support@collectivetap.com
Note: This page describes the security model, but it is not a guarantee that vulnerabilities will never occur.