Summary

The root of our social network graph is spread across a dozen SaaS apps that pollute the data. Contact data is the way out; local-first apps make private relationship data first class where entering that data into SaaS was never even an option.

Personal Network Toolkit contains an architectural specification, reference designs, and MCP servers for local-first contact and relationship applications that have the goals of:

Private data sovereignty
Mirroring of saas contact data
Secure communications channels
Portable, durable, and recoverable user data
Locally diagnosable

From those goals, architectural constraints fall out. Those architectural constraints were made into a blueprint spec designed to be human readable but ideal for agentic AI to build an app from, or verify that an app meets those constraints: https://github.com/richbodo/personal_network_toolkit/

The specification assumes that AI agents are the composers and humans are the orchestrating builders.

MCP servers have been added to the reference designs and the spec, so that Personal Network Applications are easily automatable - PNAs are designed for AI-mediated use without collapsing privacy boundaries. A lot of interesting architectural constraints are required to make this viable, and still meet the goals.

Using AI agents as composers with typed verifiable contracts specifically for building applications in the domain of contact and relationship data is also novel for the space, so there are some lessons learned there as well.

The architectural constraints are what I would like to describe and workshop.

There is also a social network health (community mental health) angle - two reasons personal network applications have potential to improve social network health: The first is the obvious noise, distraction, and bad data that users are confronted with in SaaS systems - people leave the system without contacting the right person - they run out of energy or time. The second is that important relationship data is extremely useful - it's just not reasonable to enter that kind of sensitive data into most SaaS systems. But without that private information, we have to rely on memory alone - and again, it’s easy to forget or run out of time and energy with that method. Exit from SaaS is not an option, but interop and data mirroring turn SaaS into a glorified db, solving for it’s problems in several use cases.

History

After my last talk at DWebCamp, I was approached by someone who suggested I should build an app to improve mental health in the developer community. Having followed probably the best social network health trainer alive for about five years, I did not think that would work at all. Later I had my own mental health challenge and tried to use SaaS systems to find people to talk to urgently. I was met with noise, distraction, and a long traversal through people I did not really know, until I ran out of energy. I later realized I had to get control of my contact data - I could not survive that kind of thing - I need to know who is important and who I can talk to when I have no energy at all and need a friendly human.

After implementing a paper solution, then building a couple command line contact managers and a directory archive for myself, and after studying social network health specifically for remote workers, I started to see the local-first light. I was using my own apps more than SaaS apps to discover and reach out to friends - only my phone competed with them. I cannot realistically exit SaaS, but I can interoperate with it now, without distraction, and I control all of my private relationship data.

Although I am somewhat naive, I’ve never been so stoked about a software project.

Prior Art:

There are some adjacent and very informative efforts: Solid Application Interoperability specifies how applications interoperate over personal data in server-hosted pods, with access controls and data registrations — but it's silent on the inside of a local-first application and on what architectural commitments an app of a particular category must hold. ATProto Lexicons define typed schemas that conforming apps must implement — but they're protocol-level RPC and record schemas for federated social, not architectural commitments for a local-first contact application.

The Personal Network Application specification, proposes to occupy the gap none of these addressed: a category-level architectural specification for local-first contact and relationship applications, with the Shared/Private data split as a hard commitment and typed contracts an AI agent can build against.

Solid asks where personal data can live. AT Protocol asks how social records can interoperate. JSContact asks how contact cards should be represented. PNAs ask what guarantees an application must make when it turns contact data into private relationship memory.

A lot of local-first research is likely to lend itself to future directions for PNAs. grjte’s writing on groundmist is informative.

Who this workshop is for:

Spec-curious builders, local-first folks, anyone who's tried and failed to exit their contacts from SaaS, ATProto people thinking about the private-data gap. Anyone in a bigger project that is wondering what projects that are constrained to one person building for themselves are coming up with. People who wonder what this has to do with community mental health.
Agenda:

Background + SNH framing + Prior Art (5 minutes):
Demo (5 minutes):
Spec Walk-Through (10 minutes of highlights):
Critique and rework (35 minutes):
Wrap - what survived (5 minutes):
What I’ll bring:

Laptop, Post-its and pens.
Note:

If you want to give the workshop more time (90 min) we will expand the critique and discussion part. That might work well with a larger crowd (8 or more) where we break out into two or more groups, to give each group time to discuss a more specific topic. We can use up a lot of time integrating and reporting out with that method, but it’s parallelized, so we get more critiques in.

For a small group (7 or less), we’ll probably all sit around the table and allow each person to raise their passion critique for two minutes, then allow anyone to rebut for 3 minutes - that should yield about 7 critiques in 35 minutes.