How Syndik8 thinks about fairness

The question this page answers

Shared-ownership calendars expose information. Who’s flying today. Who flew for three hours on Tuesday. Who landed so hard they uploaded a suspiciously-blurred Hobbs photo. Syndik8 gives admins three levers for choosing what other members see, and deliberately makes each one syndicate-wide rather than per-member. This page explains the three levers and the reasoning behind the syndicate-wide choice.

The three privacy primitives

All three live on the Privacy & Visibility screen at /syndicates/:syndicateId/settings/privacy. Admins set them; every member in the syndicate experiences the result.

Show member names on bookings

A calendar-level toggle. When on, every booking on the calendar carries the author’s name. When off, other members’ bookings read “Busy”; your own bookings still show your name. With this off, members who are not permitted cannot see who booked a given slot. See show member names on bookings.

Usage log visibility

A dropdown controlling who can see the financial detail (charge, shortfall, rate) on other members’ usage logs. The two values are All Members and Admins Only. The log itself is always listed, so a member can see that a flight happened, its duration, and its landings, because that data matters for scheduling and maintenance. Only the charge columns are hidden. A member always sees their own logs in full; admins always see everything.

A toggle controlling access to photos attached to usage logs (Hobbs readings, fuel receipts). The uploader always sees their own photos; admins always see everything. Other members only see a photo when this toggle is on. With the toggle off, a member who isn’t entitled to see a photo cannot view it. See usage photo privacy.

Why syndicate-wide, not per-member

The obvious question is why these can’t be personal preferences. Each member picks their own privacy level, sees the calendar how they want, and the rest of the syndicate is none the wiser. The design rejects that for one reason: the unit of social agreement in Syndik8 is the syndicate, not the individual.

If one member has names off and another has names on, the calendar becomes a different artefact to different people. A member who has set their own view to “Busy” thinks the group agreed to calendar anonymity; the member next to them, who kept names on, reads the same calendar as fully identified. When the first member makes a booking on a Saturday, they think their co-owners see “Busy”. The co-owners actually see “Sam’s Saturday booking”. The trust breakdown when that mismatch is noticed is significant; privacy that is silently different for different viewers is worse than no privacy at all.

Syndicate-wide settings avoid this by making privacy a group norm. The group has a conversation once (“do we want names on the calendar?”, “can everyone see each other’s charges?”) and the admin configures the syndicate to match the agreement. Every member sees the same calendar, reads the same logs, sees (or doesn’t see) the same photos. The syndicate’s privacy posture is a property of the syndicate itself, not of the member viewing it.

The prospect-versus-member trade-off

Defaults matter most for the two populations that experience them first: prospects who haven’t joined yet and members who just did.

A prospect is reasoning about whether a syndicate is right for them. The demo calendar (or a screenshot from a friend showing the group’s usage) is a key signal. They want names on the bookings because names are how you reason about demand: a calendar with six distinct flyers looks different from a calendar where one person fills every weekend. “Busy, Busy, Busy” tells a prospect nothing about the group’s flying pattern.

A brand-new member, fresh out of onboarding, might reasonably prefer names off for their first month, for privacy while they’re still finding their feet. The syndicate admin has five seconds to decide the default on syndicate creation, before any member experience exists.

Syndik8 defaults the calendar toggle to on (names visible) because the prospect-evaluating case is also the acquisition case; it is when the product is being judged, and it is when an uninformative calendar does the most damage. Members can flip the toggle the moment the syndicate is live. The default is deliberate, not casual.

Usage photo sharing defaults to off, because the photo case is different: a photo is a fiduciary document (proof of the Hobbs reading, proof of the fuel spend), and the uploader uploaded it for the admin, not for their peers. The default protects the member who just submitted a receipt; the admin can open the door if the syndicate wants peer-visible evidence.

Usage log visibility defaults to All Members, because operational data about a syndicate’s flying (who flew, how long, how many landings) is the substance of the shared-ownership conversation. Hiding it by default would undercut the whole point of sharing an asset. Syndicates that want financial privacy can lock it down to admins-only.

What these settings are not

The three primitives are not access controls for bookings themselves. Every member of the syndicate can see every booking on the calendar, regardless of the names toggle; the calendar is the scheduling mechanism, and hiding bookings would mean members couldn’t tell whether the asset is free. The names toggle controls only whether the booker’s name is shown, not whether the slot appears.

Similarly, usage logs are always listed; the usage log visibility setting only hides the financial columns. The booking, hours, and landings remain visible so members can make scheduling and maintenance decisions; you need to know whether yesterday’s flight put the aircraft over the oil-change threshold, regardless of whether you can see what it cost.