Regions

Internet RAM

The RAM contract does not require one universal database or one universal owner. A vendor can expose a Region with its own schema, API, lifetime, security and backing.

Current implementation: the shared-RAM contract and engineering record

Placement does not change the programming rule.

A vendor can place its RAM host on a local machine, an off-grid network or an Internet-reachable server. Applications write and read addressed state in each case. The vendor chooses how a name locates that host and what happens when the path or host fails.

The API belongs to the vendor.

A domain API can expose objects, containers and references that resolve to cells. The tuple-space contract is the underlying recommendation, not a restriction to a generic key/value interface. The vendor may add host operations for queries or aggregates rather than making every client retrieve all state.

An application may mount several vendor regions. A pointer into another region is meaningful only with the appropriate region contract and access. Shared structure should reference the truth rather than duplicate it.

Ponds give networks scope.

FD&F treats a pond as a membership scope, corresponding to the DIF idea. A lillypad is a local network that can participate in more than one pond. Those relationships can be nested in the architectural model; they need not form one flat partition of every machine.

The current implementation has one session per configured pond, one forward pond, and reach into other permitted ponds. It has namespace evidence for overlapping private prefixes. Arbitrary-depth recursive deployment and automatic propagation of authorization through such a hierarchy are not established by that evidence.

Policy travels with the region.

The vendor or administrator chooses enrollment, read/write permissions, reach policy and security requirements. Region membership alone does not authorize every application operation. A network that uses the same numerical private addresses as another is not automatically the same scope.

The current bridge refuses ambiguous identity resolution when more than one pond answers. It quarantines released aliases to reduce premature reuse. Programs with addresses embedded inside application payloads require their own handling; translating IP packet headers cannot discover those addresses.

Vendor-owned semantics

The vendor decides what the tuples mean and what higher-level API is useful: objects, collections, queries, indexes or domain operations.

Independent policy

Region scope, lifetime, residency, backing, reconstruction, split/merge behavior, reconciliation and security belong to the Region owner.

Specification: §9 Memory

Composition

An application can use several Regions without forcing their vendors to share a schema, credentials or consensus system. The application defines the relationship.

Applicationcorrelates truths from mounted Regions CRM RegionCRM owner · schema · policyits infrastructure Billing RegionBilling owner · schema · policyits infrastructure Carrier RegionCarrier owner · schema · policyits infrastructure authorized mounts; no shared database or global authority
Mounting several Regions does not merge them. Each vendor keeps its own namespace, security, semantics, lifetime, residency and backing. The application supplies the relationship.
Composition, not federation

The Regions do not have to become one system.

A process can map several independently created shared-memory segments and use them together without merging the segments. Internet RAM applies the same idea across independently governed Regions. A weather vendor, a manufacturer and your own private Region can remain unrelated systems with different owners, schemas, credentials and policies. Your application is the thing that knows how their truths relate.

The backing store is an implementation choice.

A Region can be transient memory, persistent storage, a domain database or something in between. The application relationship is to the Region contract, not to MariaDB, C++ memory or another backing technology.

application → vendor API → Region → backing ↑ FrogNet transport + semantic wire

Application RAM is deliberately decoupled from the whole FrogNet node.

The application-side RAM work depends on the FrogNet core for transport and semantic compression. It does not require every application datastore to participate in FrogNet discovery, elections or broker operation. How a client finds the vendor's store is the application's business.

Evidence

big5

Qualified

Five heterogeneous machines in two cities mounted one Region served from a third city. The same program ran without placement logic.

FrogChat

Qualified

Internet chat used the shared-RAM contract with a small client and no conventional application backend.

Sourri handoff

Qualified

The application developer rebuilt and validated the handoff independently, an important test that the model could be picked up by somebody other than its author.