Local-first Design Guide for Decision makers

[aschrijver]

Weird's success depends in part on the adoption of the local-first computing paradigm. Depends on paradigm shift, people making the jump. Encouraging them to do so.

There is something still missing in the current local-first landscape. There isn't a lot of guidance that allows an architect or dev to make informed design decisions as yet. What are the architecture patterns in local-first? What are their use cases, pros and cons, etc? Current vendors are focused on technical internals and product, research focuses on low-level algorithms and such.

It is clear that if your use case is collaborative document editing, then you are good to go and can make a shortlist of projects to choose from. CRDT's + Sync and a good API. However, what if the goal is to deliver an app or even an app framework which furthermore must (inter)operate on an open social network with many 3rd-parties ...

In cases where the full app state is p2p synchronized between peers, what does that mean for authorization? And encryption? How do 3rd-parties deliver services to the app, extend it with plugins? How do apps interact with other apps. Much of this is unexplored. The wait here is for the generic sync protocol that, as Martin Kleppmann says, makes the back-end disappear. And then focus on productive (low-code) app frameworks.

Before I became aware of local-first I was intrigued by the extreme loose-coupling of having an event driven and service-oriented architecture as the basis for social networking. Where emitted events are the triggers in a service choreography and apps are compositions of services.

Does local-first p2p obviates the need for such design? Or do they go hand in hand, complementing each other? When to choose which communication method? Etcetera.

Guidance for Decision makers to help onboard newcomers who are exploring the local-first landscape is needed, and it can be part of the portal discussed in commercialization / licensing discussion.

[zicklag]

100% this would be a good thing to pull into some good, organized documentation. Things are really hard to keep up with in the space. Even I have hard time keeping tabs on things, and while I'm still digesting more protocols over time, at some point when working on Weird I had to say, "OK that's all I can take, I've got to just go forward with what I've got for now and hope I'm not missing the 'answer' in something I haven't done a deep dive into yet."

One thing I really want to try once I can budget time for it is to make learning resources that make everything seem totally obvious how things work and are put together in a very easy-to-remember way.

I think I might have the aptitude to make videos or blog posts in that direction.

I think it'd be good to do objective reviews on how certain protocols work, as well as subjective interpretations of their strengths, weaknesses, and how they fit or compare to other protocols and the work that we are investing in specifically.

Obviously this is something that we can chip away at over time.

[aschrijver]

Yes! Probably most valuable short-term is a) docs, docs, docs and b) blogs (for an ecosystem audience). Especially the docs are tricky to evolve alongside rapidly changing codebase. A boring chore to keep them in sync, but key to attract more builders to the space. You might consider having a "Definition of Done" whereby code/spec changes are to be followed with an up-to-date check of the docs.

I think it'd be good to do objective reviews on how certain protocols work, as well as subjective interpretations of their strengths, weaknesses, and how they fit or compare to other protocols and the work that we are investing in specifically.

Great. After a good landing page the docs are the 'checklists' for 1st decision makers who draft the short-list of candidate technologies for their tech stack. At that early stage the docs are usually among few things to stand out from the crowd. Actually test-driving the tech comes afterwards.