Skip to main content

​
Protocol roles

Roles give PressChain an explicit vocabulary for capabilities and accountability. The current V3 authority table defines five protocol roles. Applications should consume these IDs as canonical data rather than inventing their own numeric mapping. Enterprise and Administrator exist as platform roles, but they are not additional protocol role IDs in this table.

​
Why roles are protocol data

A role is not just a badge beside a display name. Protocol actions can require a role and an active bond. Verification and review flows can weight participation differently. Outlet or publishing interfaces can use roles to determine which actions are reasonable to present. If every application uses its own role names and IDs, a signed action becomes difficult to interpret outside that application. Canonical roles solve that interoperability problem.

​
Role checks belong close to the action

A client can preflight role state to improve UX, but it must not assume that a client-side check is enforcement. A safe interaction looks like this:
The contract or authoritative service must still validate the action when it executes. State can change between the UI check and transaction inclusion.

​
Role weight

Role weight provides protocol context for systems where participation quality or responsibility matters. It should not be converted into a universal claim that one person is more truthful than another. Applications should display the actual source of a weighted result. If a verification score uses role weight, show the participating roles or the rule that produced the result rather than presenting an unexplained number.

​
Reader is a real role

Reader has role ID 0 and no minimum bond. That does not mean Reader is equivalent to “anonymous.” Some actions can still require an authenticated PressKey identity, while other actions require a bonded publishing or verification role. This distinction is especially useful for community participation. A system can allow authenticated readers to contribute evidence without giving them the same canonical publication authority as an Editor.

​
Platform roles

Enterprise and Administrator are useful application and operational concepts but should not be serialized as fake protocol IDs 5 or 6. Keep platform authority in the layer where it is defined. This is also why archived role definitions must not be copied into new code. Historical source may include roles that are no longer active. Current V3 authority is the canonical table.

​
Product design guidance

Role-aware UI should answer three questions clearly:
  1. What role is active for this identity?
  2. What bond or permission requirement is missing for the requested action?
  3. Is the restriction coming from protocol state, outlet authority or application policy?
Avoid a single generic “not authorized” modal for all three. Developers and newsroom users need to know what state is actually preventing an action.

​
Use role labels from authority

Keep the role table in one versioned module or fetch it from an authoritative configuration source. That makes role copy consistent across navigation, transaction review and audit trails. If a future approved V3 rule changes a label or requirement, application behavior should converge through the same authority update rather than a collection of hard-coded UI patches.