Local-first, then server-authoritative

[a-type]

This is an amazing project, and I'm loving the reasoning behind it. I'm really interested in building useful, sustainable software with a focus on utilizing client devices and staying lean.

A lot of my ideas start with something that's usable local-only in a webpage. I love the fact that a webpage is so cheap to host - so I can keep the local app available for anyone who wants to use it, and store all their data locally. But I'm interested in building small businesses out of apps by selling any features that require significant server work, like cross-device sync, multiplayer, or long-running tasks. This just makes sense to me; I host servers to provide persistent access and storage, and that's what you pay for. Cancel anytime to go back to local-only.

Aphrodite looks really promising for my needs, but I wanted to check in before putting too much effort behind prototyping with it. What I want to do isn't really P2P. Ultimately I'm hosting a server anyway to back up user data, and device sync is awkward to teach to users if it requires both their devices to be online at the same time to work - for better or worse, the status quo has conditioned users to expect seamless sync after they close the tab.

With your current understanding of Aphrodite's roadmap, will an 'upgrade path' for users from local-only to server-stored-and-synced still be in line with project goals? I know in theory the server is just another peer, but what I'm really hoping to do is restrict networking altogether unless the user has created a paid account, basically - so my server-side system is both the authority on that and the gateway to networking with other devices. This is more restrictive (or, pessimistically, greedier) than the P2P ideal, but in my opinion it's a more user-friendly spot on the 'spectrum' you reference in the project writeup than fully P2P that preserves a lot of the niceties web users are already comfortable with.

I feel it's a subtly different paradigm than a more open P2P mesh system, and has its own constraints. Having a central server means you could actually enforce authorization in a 'trusted' space, for example. Both P2P discovery and authorization are kind of side-stepped in this scenario - for most of my ideas I wouldn't need 'row-level' auth at all; if the server accepts your connection to a client, they can be trusted as a collaborator. But auth could be implemented on the server, rejecting changes from clients it centrally knows are not allowed as writers.

For prior art on this kind of paradigm, https://liveblocks.io is a good example. There are many things I like about Aphrodite in comparison, though - like the data schema, and being open source of course.

Anyways, that's enough rambling - I'll be watching the project and I'm excited for a future of simpler, better software. Cheers.

[tantaman]

A lot of my ideas start with something that's usable local-only in a webpage. I love the fact that a webpage is so cheap to host - so I can keep the local app available for anyone who wants to use it, and store all their data locally.

This is exactly how I've felt. I've done a few "local only" apps but never got around to enabling paid hosted features for them because those always seemed more painful to add on than it should be.

What I want to do isn't really P2P. Ultimately I'm hosting a server anyway to back up user data...

I'm focusing on P2P because, currently, I see that paradigm as being flexible enough to support traditional client-server interaction (server is a more privileged peer -- as you mention later in your comment) without too much complication.

I'm in the process of testing this hypothesis by helping build out a local app whose only "peer" is a central server used to sync local state back to and receive extra information from. Unfortunately I'm NDA'ed on the app but it's centered around https://www.mealme.ai/

will an 'upgrade path' for users from local-only to server-stored-and-synced still be in line with project goals?

I think that would be compatible. Aphrodite won't just automatically start connecting to peers. How peers are discovered, which peers are authorized to connect, and how peers verify their identity, would be configured by the application developer.

Take this with a grain of salt though as I've just started implementing the peer to peer layer so there are still a bunch of unknowns.

for most of my ideas I wouldn't need 'row-level' auth at all; if the server accepts your connection to a client, they can be trusted as a collaborator.

This is a good point. I've been thinking of it from the perspective of each "record type" (or schema) being able to express its authorization concerns in terms of who/what can read/write it. This is probably overkill for many use cases.

---

Thanks for your interest. If you know anyone that'd be interested in collaborating, point them my way.

I'll let keep you up to date with how the exploration goes with using Aphrodite for a more traditional client/server setup.

[a-type]

I'd mention @siliconjungle, but it seems you're already in touch! I'm just learning about this space after toying with my own systems for years, it's been exciting to see projects like yours that are already gaining ground. At the end of the day I probably won't be a big contributor in the core tools area, but I'm really excited about building out apps!

[a-type]

Also I'll note that as long as the server-side story is flexible enough, row-level auth is still a great thing to express in the data schema! Ideally I could authorize interactions in such a way, but then the logic for enforcement would be in the domain of my code - which will already know trusted client identities via traditional central user accounts and OAuth.

[dumblob]

Ad P2P - I think the main difference between what P2P means for many is "eventual sync" whereas with client-server architecture one expects a "user-controlled sync" (i.e. not eventual but fully visible to the end user who can then e.g. achieve behaviors like "do not do anything new until a full sync is done"). Traditionally with P2P such user control was not possible of if it was, then at least not enough fine-grained or just not "first-class" 😉.

So I wonder how these experiments with "P2P as the backbone for client-server" will play out. I will keep my ears open!

[tantaman]

And P2P - I think the main difference between what P2P means for many is "eventual sync"

Yeah, at the moment its playing out that "the app assumes all data is available locally and immediately starts executing, with updates flowing in later from the server"

A concrete example being --

1. User navigates to their dashboard
2. There's no data locally on device for their dashboard. That is seen as the authoritative state so an empty dashboard is displayed.
3. Server has some dashboard state for the user
4. Dashboard starts filling in as the server brings the client up to date

This is more or less the experience with apple notes where you open a note and then (sometimes even as you're typing) new updates flow in.

I can see this experience being pretty problematic if the server takes a long time to bring the client up to date. Maybe an API to see syncing status can be exposed but too early to say.