Beyond HTTP

See also: Design Rationale — why these choices were made.

In 1995, attackers tapped traffic at Helsinki University of Technology and captured passwords from plaintext sessions. Tatu Ylönen responded with SSH: encrypt the channel, authenticate endpoints, make interception far harder. That decision was correct, and it worked. In parallel, TLS and HTTPS scaled the same channel-first model to the web. Together they shaped how we think about internet trust: secure the pipe, then trust what came through it.

That model solved confidentiality in transit. It did not solve portable proof for the data itself.

The gap after disconnect

HTTP was designed for documents on servers. It is excellent at request/response exchange. But once the connection is gone, the payload does not carry built-in answers to basic questions:

• Are these bytes exactly what was sent?
• Who authored them?
• Where do they belong in shared history?

While online, server identity and TLS state can answer some of this. Offline, a copied payload is just bytes unless you preserve external context.

Over time, platforms filled that gap with central logs, account systems, and policy layers. They became memory, identity, and trust infrastructure for everyone else.

The HTTPS model also shaped social & political assumptions. If trust lives in channels, then platforms look like unavoidable dependencies with concentrated, often unchecked power. Without a message-first paradigm, there is no durable public marketplace of ideas — only administrators granting your (community’s) identity and injecting popularity feeds hosted only on their private servers as a single source of truth.

The inversion

HPPR changes one boundary:

• Channel security still matters for transport.
• Data authenticity is anchored in the packet.

A packet can be verified anywhere it travels, independent of the original connection.

Three packet layers

HPPR builds from three composable packet types.

1) Blob — data with intrinsic identity

A Blob is raw bytes with a typed hash markline.

• Change one byte, hash changes.
• Same hash means same content.

The hash is both integrity proof and immutable address.

2) Plex — data with coordinate and time

A Plex wraps a Blob with:

• Group
• App
• Location
• TAI

Now the packet carries human location semantics such as //u/chess/README inside the signed/hashable structure.

3) Seal — data with authorship

A Seal wraps a Plex with:

• Seal-By (verification key)
• Seal-Sig (signature)

Now integrity and authorship travel with the content itself.

Two ways to address the same world

HPPR deliberately keeps two address forms:

• Hash address (////...): immutable, exact bytes.
• Coordinate address (//group/app/location): mutable tip at a path.

This resolves a long-running web tension:

• Use hash addresses for evidence, reproducibility, and citation.
• Use coordinate addresses for living documents and ongoing collaboration.

Version selectors (/|/...) let you pin exact historical states when needed.

Repositories become hosts, not truth authorities

A repository stores packets and resolves coordinate lookups. It is operational infrastructure, not the root of truth.

If a repository disappears:

• packet verification still works locally,
• mirrors can serve identical content,
• archives remain meaningful offline.

Failure shifts from “history disappears” to “routing needs repair.” That is a better failure mode for communities.

Identity and governance become inspectable

HPPR identity is key-based and packet-defined.

• Ring1 handles repository-level identity and permissions.
• Ring2 handles group membership across repositories.

Membership and ACL policy are represented as packets, not hidden tables. That makes governance auditable:

• what rule exists,
• which key authored it,
• which packet changed it.

This does not remove governance conflict. It makes governance state explicit.

Route trust and code trust are different decisions

Knowing where content is hosted is not the same as trusting it to execute code.

HAVI keeps these concerns separate:

• route configuration decides where to fetch,
• trust policy decides which signer keys may run active content.

This separation avoids a common failure in web systems where reachability silently becomes execution permission.

A practical design choice: start from group or app

A useful rule of thumb:

• If you are organizing a community, start with the group: //my-city/events/, //family/photos/.
• If you are building reusable software, start with the app: //family/chess/, //club/chess/, //school/chess/.

Both growth paths stay compatible because the coordinate model supports both.

What this enables

These are technical primitives with social consequences.

Durable civic memory

A local paper, school board, or neighborhood archive can publish signed records that remain verifiable after server migration, domain loss, or mirror changes.

Community-run software space

Different groups can run the same app model while keeping local membership and policy control.

Portable accountability

Authorship claims move with data. Verification does not require privileged access to a single company log store.

Lower-friction mirrors and backups

Anyone can mirror packets without breaking integrity guarantees, because proof is in the packet, not in transport metadata.

Scope and limits

HPPR does not solve every problem.

• It does not eliminate abuse.
• It does not make distributed systems simple.
• It does not replace the need for transport encryption.

What it changes is the substrate:

• less hidden authority in the channel,
• more explicit rules in data,
• stronger portability of proof,
• more recoverable shared history.

Conclusion

The core principle is small and practical:

Validate messages by their own cryptographic structure, not by the channel that delivered them.

From that one change, you get a different internet architecture:

• trust independent of current connection,
• authorship independent of hosting provider,
• governance state that communities can inspect,
• and records that remain meaningful when infrastructure changes.

HPPR is not alone in exploring hashed and signed message systems. Projects such as Git, IPFS, Secure Scuttlebutt, and Nostr also show the value of content-addressed or signature-first data models. HPPR’s contribution is relative simplicity: three packet layers, explicit coordinates, and minimal rules that stay inspectable.

For exact wire format and validation rules, start with hppr/spec/010-PACKETS.md.