Visible without system access
Public fields may be shown on a direct system, member, or group view without requiring the viewer to be linked to that system.
Privacy
Privacy is part of the data model.
Origami stores visibility per field instead of treating an entire system, member, or group as simply public or private. The same rules apply when data is viewed through Discord or on the web.
Visibility levels
Public and private.
Visible only to linked system accounts
Private fields require an authenticated Discord account that is linked to that Origami system.
Field-level privacy
Visibility is set per field.
A profile can mix visibility levels. For example, a member can expose their display name publicly while keeping other profile information restricted. System, member, and group entities each have their own supported privacy fields.
Default behaviour
When a field has no explicit privacy override, Origami uses its default visibility. System settings can also make newly created members or groups private by default without changing existing ones.
Web views
A direct link does not grant extra access.
A system link identifies what should be viewed. It does not prove that the viewer belongs to that system. Origami checks the viewer's authorization separately and only returns fields they are allowed to see.
Unauthenticated viewer
Public fields only
Linked + authenticated account
Public + private fields for that system
Editing session
Management controls after authorization
Private fields are filtered by the server before the page is rendered. They are not sent to unrelated or unauthenticated viewers and merely hidden with CSS or JavaScript.
Linked accounts
Shared system data, separate Discord identities.
Multiple Discord accounts can be linked to the same Origami system. Those accounts share the system's identity data, but the accounts themselves remain distinct.
Account linking uses one-time codes. A second Discord account redeems the code itself, and Origami prevents the only account attached to a system from unlinking itself.
Proxy attribution
Proxying does not hide the real sender from Origami.
A proxied message can use a member's name and avatar, while Origami keeps attribution tied to the actual Discord account that sent it. Linking another account does not merge those moderation identities together.
Server moderation controls are local to that server. A member profile is not a replacement identity that can be used to bypass restrictions applied to the real Discord account.
Imports & assets
Migration data is treated as system data.
PluralKit and Tupperbox imports can contain sensitive profile and system information. Origami keeps imported systems separate from unrelated Origami systems instead of silently merging everything into the currently active one.
Imported profile images are copied into Origami's own asset storage so the resulting profile does not depend permanently on another service's image URL. Image uploads use the same asset validation rules as Discord-side uploads.
PluralKit tokens
Import tokens are intended for temporary use during the migration flow and should not become stored Origami credentials.
Deletion
Destructive actions are explicit.
Deleting a system removes its associated Origami data, including members, groups, switches, stored assets, proxy tags, and related records. Deleting a group does not delete the members that were inside it.
Unlinking a Discord account is different from deleting the system. It removes that account's connection to the system while leaving the system itself intact.
Access & editing
Authentication proves the account. Authorization unlocks the system.
Signing in with Discord does not automatically reveal every Origami system. The authenticated Discord account still needs to be linked or otherwise authorized for the system being managed.
The web client and Discord bot are intended to use the same underlying Origami services and validation rules, so changing data through one interface changes the same underlying data seen by the other.