Making the personal web social again

Here’s a version in the spirit of the Agile Manifesto: short enough to remember, strong enough to constrain design.

Manifesto for the Durable Personal Web

We are building a web for people, not platforms.

Through building and using it, we have come to value:

People over platforms Ownership over access Files over proprietary data models Open standards over closed ecosystems Free and open-source software over vendor dependency Domains and keys over platform identities Explicit relationships over algorithmic reach Small trusted networks over global engagement Publishing over posting Interoperability over integration Local control over centralized convenience Simple protocols over elaborate infrastructure Durability over novelty Repairability over replacement Human intention over machine optimization

That is, while there may be value in the things on the right, we value the things on the left more.

Principles

1. The individual is the primary node. A person should be able to own their identity, domain, files, and publishing environment.

2. The web is the interface. A normal URL should remain useful without requiring a proprietary application, account, or platform.

3. Files are a first-class medium. Content should remain understandable, movable, copyable, inspectable, and recoverable outside the software that published it.

4. Public is simple; private is possible. Publishing openly should be easy. Restricting a resource to specific people should not require surrendering control to a third party.

5. Identity should be portable and cryptographic where useful. Domains, public keys, signatures, and capabilities should allow identity and trust to exist independently of a platform operator.

6. Following is an explicit human act. People decide whose work enters their attention. No algorithm has an inherent right to intermediate that relationship.

7. There is no requirement for a global feed. A social web can consist of many small overlapping circles rather than one universal attention market.

8. FOSS is infrastructure for continuity. The essential software should be free and open source so that no company, founder, acquisition, bankruptcy, policy change, or business model can extinguish the system.

9. Standards outlive products. Prefer HTTP, HTML, URLs, DNS, SSH, Git, text files, established cryptography, and other broadly understood protocols wherever they are sufficient.

10. The system must survive its creators. We design for decades, not funding rounds. A future maintainer should be able to understand the system, recover the data, replace components, and keep it running without us.

11. Complexity must justify its existence. Every daemon, database, protocol, abstraction, dependency, and service creates another failure mode and another obligation for the future.

12. No central service should be sacred. Discovery, authentication, hosting, trust, indexing, replication, and communication should be replaceable or distributed wherever practical.

13. Surveillance is not a business model requirement. Participation should not require behavioral tracking, profiling, advertising identifiers, or the extraction of a person's social graph.

14. Attention is not inventory. The system should serve communication, expression, friendship, learning, and creation—not maximize engagement.

15. Trust grows from relationships. Reputation and access should be capable of emerging from human-scale networks, including invitations, introductions, and vouching, rather than being imposed by a universal authority.

16. Anyone may build a strange website. There is no canonical post format, profile layout, media type, or mode of expression. A personal site may be a journal, archive, gallery, filesystem, game, radio station, laboratory, or something nobody has named yet.

17. Forking is a feature. If the project stops serving its users, they should possess the code, data, documentation, and rights necessary to take it somewhere else.

18. Boring technology is often beautiful technology. A directory of files served by a small HTTP server may be preferable to a distributed architecture nobody can understand twenty years from now.

19. The network should degrade gracefully. A personal archive should remain valuable if federation disappears, discovery breaks, another node goes offline, or the broader project ends.

20. We are building for people we will never meet. Our measure of success is not whether this becomes the next social platform. It is whether someone decades from now can inherit a node, understand it, run it, modify it, and still reach another human through the open web.

The test

If the company disappears, does it still work?

If the original developer disappears, can someone else maintain it?

If the network disappears, do I still have my work?

If fashions change, are the files still readable?

If one component dies, can I replace it?

If I leave, can I take everything with me?

If the answer is yes, we are building the right kind of web.

I’d probably keep the 20 principles as the full version and eventually distill the opening value statements down to 7–9 canonical pairs for the memorable manifesto.

Not building a better social network.

The primitive is the individual node: a domain, a directory of files, and a server. Everything else becomes an optional layer rather than a platform you must join.

A useful way to frame what you’re orbiting:

• Ownership: my domain, my files, my machine/account, my URLs.
• Publishing: anything the web can express—HTML, Markdown, photos, audio, weird immersive things, directories of files. No canonical “post” object.
• Public by default: ordinary HTTP URLs remain the universal read interface.
• Selective access: some paths/resources are private or semi-private. Basic Auth is the crude prototype; keys/capabilities could become the serious version.
• Following, not feeds: I explicitly choose the people/nodes I care about. There need not be a global algorithmic timeline at all.
• Files as truth: the social system should not require surrendering content into somebody else’s database.
• Git/SSH as an alternate transport: the web is one interface; ssh, git clone, rsync, maybe even content-addressed replication are others.
• Identity through keys: a person/node could have a public key, making signing, authentication, invitations, private resources, and eventually vouching natural extensions.
• Trust is downstream: don't solve spam, bots, Sybil attacks, moderation, discovery, reputation, and global identity in version 0. Those can become layers.
• Caddy is already a prototype: filesystem → access rules → HTTP. You’re experimenting with the fundamental object model, not merely configuring a web server.

The SSH idea is especially interesting conceptually, even if it never becomes the end-user UX. Imagine:

ojas.net
├── public/
│   ├── index.html
│   ├── notes/
│   ├── photos/
│   └── feed.xml
│
├── friends/
│   ├── journal/
│   └── photos/
│
└── private/

Caddy exposes public/ normally. Membership in friends/ might eventually derive from possession of a key/capability rather than a username/password. Git could replicate portions of the tree. Your “social graph” could literally be a small local file saying which identities you follow/trust.

And this produces a very different architecture from ActivityPub-era thinking. Instead of starting with:

How do servers federate social-network objects?

you start with:

How does one human publish and selectively share files from a sovereign node?

Then ask how two such nodes become aware of each other.

I’d resist IPFS, ActivityPub, databases, global directories, comments, likes, and even the vouch system initially. Your existing Caddy setup may be valuable precisely because it lets you test the more fundamental proposition with almost embarrassingly primitive technology:

files + URLs + domains + HTTP + SSH + keys.

If that primitive feels good between five actual humans, then the missing social protocol will become much clearer.

Yes. This experiment exposes a much sharper requirement than “persistent annotations.”

What Safari/Notes gives you is application behavior, not a durable web primitive. The annotation exists, but its manifestation depends on hidden conditions: which Notes folder it lives in, whether Notes is running, which browser opens the URL, and apparently which device you are on. The underlying reference is not even carried in the URL.

For what you’re imagining, “trustworthy” should mean something much stricter:

• Deterministic — same page + same annotation data ⇒ same result.
• Inspectable — I can see exactly what was stored: page URL, quoted text/context, destination URL, author, timestamps, etc.
• Portable — annotations are ordinary data I can copy, back up, version, sync, and move to another implementation.
• Application-independent — closing some companion app must not alter the meaning of my annotation.
• Browser-independent — another conforming client should be able to render the same annotation.
• Local-first — my own annotations continue to work if a vendor, cloud account, or network disappears.
• No hidden coupling — moving a note between folders should not mysteriously change whether the web page is annotated.
• Recoverable — if the plugin dies in 15 years, I still possess understandable annotation files.
• Openly specified — the format and matching behavior are documented, not private implementation details.

So your Honda example ideally boils down to a boring file somewhere:

version: 1
page: https://ojas.net/nsx/juggernauts
selector:
  exact: "impossible dream"
  prefix: "looked like an "
  suffix: ". The only car"
action:
  type: link
  href: https://youtu.be/6FmXjxdDBRI

The browser plugin becomes almost disposable. Its job is simply:

read page
+
read annotation files
+
match target
+
render overlay

If VivaldiPlugin disappears, FirefoxPlugin 2047 could consume the same file.

That also suggests a manifesto principle worth adding:

Data is the durable artifact; software is a replaceable interpreter.

Or even more severe:

If behavior depends on an application we cannot replace, we do not own it.

Your Safari test is useful because it distinguishes persistence as a feature from persistence as architecture. Apple gave you the former. You’re after the latter.