Whimsical

Dropbox

Dropbox gives you the simplest user mental model—“this folder is shared”—but architecturally it assumes a central service. For Seed, you seem to need a mental model where nodes exist independently, and sharing determines which content replicates between which nodes.

The strongest inspirations are:

Tailscale — best inspiration for the network/permission model. A user has a set of machines inside a tailnet. Machines have identities, can be grouped/tagged, and access between them is controlled independently of physical location. You can also share a specific machine with someone outside your tailnet rather than merging the two networks. (Tailscale)
The interesting Seed analogy is: Peer/Server = machine; Network = tailnet; Capability = ACL/grant; Space/Document = resource exposed by that machine.

Syncthing — probably the closest inspiration for the actual sync UX. You connect devices, then explicitly choose which folders are shared with which devices. There is no requirement that every device have every folder. A folder can therefore exist on A+B but not C, while another exists on B+C. (Syncthing) This feels extremely close to your Seed problem. Syncthing even has an Introducer concept: one trusted device can introduce another device into a shared folder topology. (docs.syncthing.net)





Resilio Sync — useful for the “Dropbox UX without Dropbox architecture” idea. It presents folders and synchronization fairly conventionally, but replication happens peer-to-peer between endpoints rather than requiring a canonical cloud copy. (resilio.com)

I think the key design insight for Seed is to separate membership from replication.

Imagine:

And then:

So rather than:

Dropbox
Folder → members

I would model Seed more like:

Syncthing
Resource → replication set

combined with:

Tailscale
Identity → nodes → capabilities

That gives you an important property: a Server doesn't contain the Space conceptually. It merely holds a replica of it. Likewise, a Peer doesn't need to “belong to” one server.

This also fits distributed-systems thinking better. There isn't necessarily one instantaneously authoritative physical copy; you're dealing with cooperating processes/nodes and their local states. That's exactly the kind of system model Chandy and Lamport start from when defining distributed global state.

For your Sharing Permissions PRD, I’d therefore seriously consider this conceptual stack:

Account → Node → Space → Sync relationship

where a Node is anything capable of storing/syncing Seed data: laptop, phone, self-hosted server, university server, Seed-hosted server.

Then sharing becomes:

“Allow this account to sync this Space.”

and deployment becomes:

“Keep this Space available on these Nodes.”

Those are two different operations, which I think is exactly the distinction you've been circling around with Peer vs Server. A server may simply be a node with high availability, not a fundamentally different object.

If you're looking specifically for UI inspiration, I would study Syncthing first, Tailscale second, Dropbox third. The product Seed could feel as simple as Dropbox while exposing the topology progressively like Tailscale/Syncthing.