Everything FrogNet and Ribbit claim to do.

This is the exhaustive capability ledger behind the rest of the site. The teaching pages introduce the ideas in a useful order; this page exists so a capability, consequence, experiment or architectural boundary cannot quietly disappear from the story.

Items here are not all the same kind of statement. Some are architectural contracts, some are demonstrated capabilities, some are reference-implementation details, some are measured evidence, and some are explicit non-claims. Follow the linked architecture and evidence pages for context and qualification.

Evidence record How claims are tested

Current implementation: the shared-RAM contract and engineering record

Programming surface.

Capability	Status	Detail
Three-coordinate state	Implemented	Owned cells, JSON bags and write-order ids.
Latest / distinct / collection state	Programming contract	Address choices determine observation semantics.
Held reads and views	Implemented in the modern RAM surface	Binding-specific support; do not infer support from every legacy wrapper.
Freshness	Read contract	Reader selection by memory-clock age; not mandatory timer deletion.
Claims and Wants	Programming patterns	Coordination through separate owned state and deterministic arithmetic.
Vendor API extensions	Supported architecture	Schema, operations and lifetime are chosen by the vendor.
C++ / Python	Implemented	Shared library and interoperability records.
JavaScript	Supplied binding guide	Programming guide and examples; not built or tested in this website revision.
Kotlin member	Implemented independent client	RAW protocol, membership, placement, reach and bridge logic.
Arbitrary durable exactly-once effects	Not a general guarantee	External systems need their own recovery contract.

Network construction.

Capability	Status	Evidence / condition
LAN-only autonomous operation	Existing FrogNet path	Local discovery, routing and service roles; no Internet required.
Region-driven discovery	Implemented r19-a15	Facts → world → graph → local plan; crawl bypassed in region mode.
Session-bound membership	Implemented	Announcements and held mappings leave with the session.
On-mesh / off-mesh placement	Qualified in namespaces; hardware observed	Existing LAN address or a region-assigned leaf via hub.
Several simultaneous ponds	Implemented; namespace qualification	One forward pond, other sessions and policy-permitted reach.
Overlapping private prefixes	Namespace-qualified	Per-scope devices and 1:1 aliases; checksums and ICMP quoted headers.
Identity-only resolution	Implemented; namespace-qualified	Exactly one answer; multiple ponds answering are refused.
Pond switching and notices	Implemented; namespace evidence	Open sessions change roles; notice is state.
Recursive scope composition	Architectural model	Arbitrary-depth operational qualification is not established.
Service re-election from facts	Implemented; simulation-qualified	No dependency on reading the failed application store.
Fresh installs without broker dependencies	Planned cleanup	October 12 plan; not an established release.
Maximum region size	Uncharacterized	Old broker allocator arithmetic is not a current region capacity measurement.

Applications and experiments.

System	Status	Evidence
Desktop / Android Communicator	Implemented; recorded hardware call	Desktop r3 and Android r5; earlier bandwidth work remains separate.
FrogTorch	Compared campaigns	Four DDP ratios; controls and semantic variants retained.
Redis-on-Ribbit	Behavior and performance campaigns	Passes, N/A and errors reported by checkpoint.
lispers.net conversion	Conformance records	Wire preservation, registrations, refresh and liveness.
RINA conversion	Flow records	Reliable delivery, credit-state and route-change tests.
Monitoring and sensors	Operational demonstration	PC membership, monitor and live map; Android monitor presentation has a recorded open issue.
Games and older household apps	Historical experiments / remnants	Do not infer supported current deployment from the old product list.
Containers / VMs / namespaces	Architecture plus namespace evidence	A workload can publish its own identity and scope; not a shipped Kubernetes CNI or general container deployment qualification.

Evidence ledger Mechanism reference

Architectural philosophy
- Automate everything that can reasonably be automated.
- Discover anything that can be discovered instead of requiring it to be configured.
- Derive anything that can be derived from authoritative state instead of maintaining duplicate bookkeeping.
- Make every mechanism generic that can legitimately be made generic.
- Solve generic infrastructure problems once below the application instead of repeatedly in every application.
- Keep application-specific semantics in the application or vendor rather than pretending they can be generalized.
- Hide network topology from applications whenever topology is irrelevant to their domain.
- Hide transport selection from applications whenever transport is irrelevant to their domain.
- Hide physical service placement from applications whenever placement can be determined automatically.
- Move coordination into shared state wherever the required semantics can be expressed as state.
- Move redundant wire representation into reusable semantic machinery instead of application-specific compression.
- Push complexity downward until each problem is solved at the lowest layer with enough information to solve it generically.
- Preserve existing application contracts where possible rather than requiring applications to become FrogNet applications.
- Treat RAM as RAM and leave persistence, reconciliation, authority, continuity, and recovery policy to the owner of the state.
- Prefer independently published truths over conversations among distributed participants.
- Use the operating rule: determine your truth, write your truth, read the other truths, go.
- Treat RAM as the programming model and everything beneath it as implementation policy.
- Separate authoritative truth from derived views so generic machinery does not create redundant state.
- Separate real dependencies from incidental communication so only participants that actually depend on a changed truth need to wake.
- Treat failure, partition, movement, stale observations, and changing bearer characteristics as normal operating conditions rather than exceptional modes.
- Preserve continuing network context when the relationship itself is stateful instead of recreating request/response choreography on every interaction.
FrogNet Living Network — §1 Scope and terminology · §2 Architectural invariants
- FrogNet is a distributed network operating environment rather than a transport, VPN, database, broker, or cloud service.
- A FrogNet node can operate autonomously without Internet connectivity.
- Nodes automatically organize themselves into a connected pond.
- Nodes continue operating when external connectivity disappears.
- Connected networks can split into independently operating ponds when links disappear.
- Independently operating ponds can heal when connectivity returns.
- Healing restores network connectivity without requiring applications to rebuild their networking model.
- FrogNet provides discovery, routing, transport, semantic compression, security, split/heal behavior, and service elections.
- Applications operate against the FrogNet programming surface rather than physical network topology.
- FrogNet can span local networks, radios, Internet paths, and tunnels within the same logical network.
- FrogNet is transport-agnostic rather than being architecturally tied to one link technology.
- The same application architecture can operate from a single machine through an Internet-spanning FrogNet.
FrogNet node — §3 Node, identity and installation
- A FrogNet node is a sovereign participant with persistent identity.
- A node participates in discovery, routing, service election, shared state, and network operation.
- A node can be a complete useful network by itself rather than requiring a server or cloud controller.
- The reference implementation runs on ordinary Linux hardware.
- FrogNet deliberately uses visible Linux mechanisms rather than hiding the operating system behind an appliance abstraction.
- Routing tables remain real Linux routing tables.
- Network interfaces remain real Linux interfaces.
- Sockets and processes remain ordinary operating-system resources.
- systemd services participate in FrogNet service lifecycle.
- dnsmasq participates in the reference networking environment.
- WireGuard participates in inter-site transport.
- Filesystem and kernel networking state remain inspectable by the operator.
- FrogNet infrastructure is owned and operated by its user rather than supplied as a mandatory cloud service.
Network discovery — §4 Discovery and membership · §4a Triggering and the merge controller
- Discovery automatically finds FrogNet hosts without application involvement.
- The local discovery path recursively learns hosts reachable through already discovered FrogNet hosts.
- Discovery allows a node to learn hosts to which it is not directly attached.
- Discovery builds network knowledge rather than merely locating a single endpoint.
- Discovery measures round-trip time to reachable hosts and paths.
- Discovery evaluates alternative routes to each reachable host.
- Discovery produces an optimal route for each host based on measured RTT.
- Different destinations can therefore have different optimal routes from the same source.
- A lower-latency indirect path can be preferred over a physically simpler path.
- Discovery responds to nodes and links appearing, disappearing, degrading, and recovering.
- Newly discovered connectivity can produce new optimal routes automatically.
- Lost connectivity removes routes that are no longer usable.
- Reconnected ponds rediscover the hosts and paths made reachable by the restored connection.
- Discovery results supply topology and locality knowledge to other FrogNet infrastructure.
- Discovery itself uses ordinary FrogNet infrastructure rather than requiring a separate networking architecture.
- Discovery has been expressed using the same shared-state model used by applications.
- A network address is not accepted as proof that a FrogNet participant exists.
- On the local discovery path, a candidate must answer the FrogNet discovery mechanism before it becomes known as a FrogNet participant.
- Discovery therefore establishes positive evidence of reachability rather than merely enumerating configured addresses.
- Negative observations are treated differently from positive observations because absence is harder to establish than presence.
- Discovery includes negative-cache behavior so failed probes do not become permanent assumptions.
- Discovery includes retry behavior for candidates that were previously unreachable.
- Discovery includes cache-flush behavior so stale negative observations can be discarded.
- Discovery test isolation prevents stale observations from contaminating later discovery results.
Routing — §5 Addressing and routing
- Routing is produced automatically from discovery rather than configured by applications.
- Routes are selected per destination rather than imposing one universal path through the network.
- Route selection is based on observed RTT rather than simple hop count alone.
- FrogNet can route through intermediate nodes when a destination is not directly reachable.
- End-to-end routes can cross heterogeneous transports.
- Applications identify what they want to reach rather than specifying how packets get there.
- Route changes remain below the application programming surface.
- Routing automatically adapts to topology changes discovered by FrogNet.
- Routing allows network partitions to occur without requiring applications to reconfigure themselves.
- Routing automatically becomes available again as healed connectivity is rediscovered.
- Routing information provides locality knowledge used by service-placement algorithms.
Failure, convergence, and self-healing — §6 Pond formation, split and heal · §13 Failure and recovery
- FrogNet assumes links can disappear while applications are running.
- FrogNet assumes nodes can disappear while applications are running.
- FrogNet assumes routes can change while applications are running.
- FrogNet assumes tunnels can fail while applications are running.
- FrogNet assumes networks can partition while applications are running.
- FrogNet assumes services can move while applications are running.
- FrogNet assumes processes can restart while applications are running.
- FrogNet assumes observations can become stale.
- FrogNet assumes the characteristics of a physical bearer can change during execution.
- Failure semantics are part of the architecture rather than an undefined excursion from normal operation.
- Recovery and convergence are intended to occur automatically from newly observed state.
- A mechanism that requires an operator to notice a failure before the network heals is not considered self-healing.
Transport independence — §18 Implementation considerations
- FrogNet treats transport as a replaceable mechanism beneath the application.
- Ethernet can carry FrogNet traffic.
- Wi-Fi can carry FrogNet traffic.
- Radio links can carry FrogNet traffic.
- WireGuard tunnels can carry FrogNet traffic.
- Internet paths can carry FrogNet traffic.
- Multiple transport types can participate in a single FrogNet path.
- Changing transport does not require changing the application’s programming model.
- FrogNet semantic processing can reduce traffic before it reaches a constrained transport.
- Non-FrogNet traffic can pass through the proxy without being converted into FrogNet semantic traffic.
Service discovery and virtualization — §8 Service discovery and election
- Applications can address logical services rather than physical machines.
- Logical service identity can remain stable while the machine hosting the service changes.
- Service discovery separates finding a capability from knowing its current physical host.
- Well-known logical names can provide stable entry points to services.
- Vendor services can expose their programming surface at well-known logical locations.
- Service placement can change as the network changes without changing callers.
Service elections — §8 Service discovery and election
- FrogNet can elect service hosts automatically.
- Host selection is deterministic so participating nodes can independently reach the same result.
- Host-selection policy belongs to the service rather than to one universal election algorithm.
- Different services can select different hosts from the same pond.
- A database service can select according to database-specific capability requirements.
- A media service can select according to locality and media-specific requirements.
- A service can restrict election to directly attached neighbors when relay placement would be inappropriate.
- A pond-wide service can elect from the full connected pond when locality is not required.
- Election scope is therefore itself service-specific.
- Stability rules can prevent marginal candidates from repeatedly displacing healthy incumbents.
- Adding a new service type can mean supplying a new selector rather than modifying a central election mechanism.
Floating services — §8 Service discovery and election
- A service can move between physical hosts while retaining the same logical identity.
- Service consumers do not need to know which machine currently hosts a floating service.
- Host loss can cause service placement to be recalculated from the surviving network.
- Service placement can exploit changes in available capability and topology.
Transient database — §9 Memory
- FrogNet can provide a floating transient database to a connected pond.
- The transient database has a logical identity independent of its current physical host.
- The database host can be selected automatically from eligible machines.
- Applications can use the database without embedding its physical address.
- Database placement can change as network membership changes.
- Transient state is intentionally distinct from application promises of persistence or reconciliation.
- FrogNet does not silently manufacture cross-partition database reconciliation semantics the application did not request.
Broker and WAN connectivity — §7 Internet extension and broker
- A broker can provide rendezvous and forwarding between Internet-separated FrogNet sites.
- The broker is not the FrogNet database.
- The broker is not the FrogNet Memory authority.
- The broker is not the service-election authority.
- The broker is not the semantic engine.
- The broker is not a member of the pond.
- Each connected side establishes its own WireGuard relationship with the broker.
- The broker therefore terminates separate WireGuard tunnels.
- Traffic can be decrypted at one tunnel interface, forwarded by the kernel, and encrypted into another tunnel.
- The broker is consequently inside the transport-encryption boundary.
- An operator controlling the broker can observe plaintext IP traffic crossing that forwarding seam.
- Confidentiality that must survive broker compromise must be supplied above the broker’s transport boundary.
- A broker can run on any suitable Internet-reachable machine.
- A broker placed on a LAN can directly join otherwise independent FrogNet connectivity and can short-circuit a longer path.
- Broker functionality includes tunnel creation.
- Broker functionality includes tunnel refresh.
- Broker functionality includes tunnel teardown.
- Broker functionality can include pond and chorus administration.
- Loss of the WAN path leaves each surviving pond capable of local operation.
- Restoration of the WAN path allows separated network portions to heal.
Security architecture — §12 Security and trust boundaries
- FrogNet’s security properties come from identifiable mechanisms rather than a claim of inherent security.
- FrogNet implements no novel cryptography of its own.
- Cryptographic identity can establish node or principal identity.
- Authentication determines which principals are admitted to protected relationships.
- WireGuard provides transport confidentiality where it is used.
- TLS can provide confidentiality and authentication where applicable.
- Key ownership is part of the trust model.
- Explicit trust relationships determine what compromise of each component permits.
- Network placement and membership can remove the need to expose conventional application endpoints publicly.
- Removing unnecessary public application endpoints reduces attack surface but does not imply that FrogNet has no attack surface.
- The security model distinguishes where plaintext exists from where cryptographic protection exists.
- The security model distinguishes transport confidentiality from end-to-end application confidentiality.
- Broker compromise has explicitly different consequences from endpoint compromise.
- Region owners remain responsible for application-specific authentication and authorization semantics.
- Region owners can impose validation, verification, auditing, signing, provenance, rate control, and participant restrictions.
- Security policy can differ among independently governed Regions.
- Signed script distribution can distribute software across the mesh.
- Script-distribution trust can be pinned on first contact.
- Semantic/template compression is deliberately constrained where a bearer or regulatory regime forbids obscured communications.
- The documented amateur-radio constraint treats semantic/template compression as unsuitable where Part 97 prohibits obscured communications.
FrogNet naming — §3 Node, identity and installation
- FrogNet can give services stable names independent of their current machine.
- FrogNet-controlled names can resolve inside the network without exposing physical placement to applications.
- Naming works with discovery and elections to separate identity from location.
FrogNet Memory — §9 Memory
- FrogNet Memory extends a RAM-like programming abstraction across the network.
- Programs share what they know rather than sending explicit application messages to one another.
- State is addressed rather than routed by application code.
- A connected pond presents an addressable shared state space.
- Writes publish values into that shared state space.
- Reads retrieve the current published truth at an address.
- Publications carry ordering information so newer state can be distinguished from older state.
- Application participants can operate independently against shared truths.
- The programming model removes network topology from ordinary state access.
- The programming model removes explicit sender/receiver relationships where the domain does not require them.
- Shared state can coordinate software, infrastructure, and physical devices.
- RAM itself makes no promise of persistence across re-homing.
- Consistency requirements created by re-homing belong to application or region policy.
- Copying, migration, reconciliation, and continuity are not silently imposed by the RAM abstraction.
Public Memory contract — §9 Memory
- The lowest application-visible Memory contract is intentionally small and stable.
- Memory can write state at an address.
- Memory can read state by a complete address.
- Memory can read state through partial-index addressing.
- Memory can optionally wait for state newer than what the reader already has.
- Memory can remove state when the application semantics require removal.
- Partial-index reads allow a consumer to retrieve matching state without reducing the model to one exact-key lookup.
- Blocking reads are dependency operations rather than application polling loops.
- Persistent sessions can associate multiple Memory operations with one live connection.
- Sequence numbers can associate replies with corresponding requests on persistent sessions.
- The common public contract allows generic tools, language libraries, qualification suites, discovery, and administration to operate across applications.
- The three-coordinate tuple space provides a common addressing contract while leaving coordinate meaning to the application.
Ribbit programming model — §10 UnREST
- Ribbit expresses distributed applications as participants operating on shared truth.
- A cell is an independently addressable truth.
- Containers organize related addresses without turning them into serialized application messages.
- References express relationships among independently addressable truths.
- Participants derive new truths from existing truths.
- Presence can itself be represented as state.
- Write ordering lets participants reason about publication order without inventing application message sequences.
- Held reads express real dependencies on truths that do not yet exist.
- Publication can wake a participant waiting on a held read.
- Publication therefore provides synchronization without becoming a central scheduler.
- Claims express competition as published state rather than lock ownership.
- Claim ordering can select which participant acts.
- Claims can disappear after their coordination purpose has ended.
- Batches can represent application state that must become visible as one truth.
- A publication point can declare a reconstructed or assembled body of state usable.
- Behavior can be implemented by ordinary participants rather than continually adding verbs to the memory server.
- Ribbit’s vocabulary is intended to remain small while applications build richer semantics above it.
- Wants are published truths expressing demand for state or a Region that is not currently resident.
- A participant can publish a Want and then park on the truth whose appearance satisfies that dependency.
- Partial indexes are part of the programming surface rather than requiring every relationship to be an exact key.
- Mounting a Region grants only the capabilities its owner chooses to expose.
- Shared state is not synonymous with public state.
- A Region is shared only among participants authorized by its owner.
- Continuing mounted context is part of the model when the represented relationship itself continues over time.
- Replacing continuing context with stateless RPC would recreate the request/response machinery Ribbit is intended to remove.
Lock-free application construction
- Single-writer ownership can eliminate write contention where the domain permits it.
- Participants can publish independent contributions without acquiring a shared application lock.
- Readers can derive decisions from published state instead of asking a coordinator.
- Claims can replace lock acquisition for competing operations.
- Derived state can replace synchronized bookkeeping.
- Held reads can replace polling loops for real dependencies.
- Application algorithms can avoid queues, reapers, coordinators, and explicit messages when their semantics permit it.
Dependency-addressed waiting
- Held reads can wait on the specific truth on which a participant actually depends.
- Dependency-addressed waiting avoids waking unrelated participants when an unrelated truth changes.
- In the documented waitbench with 64 readers, 2 writers, and 1,024 variables, one shared broadcast-like wait word sustained about 11,000 writes per second.
- In the same waitbench, 4,096 dependency-addressed wait words sustained about 445,000 writes per second.
- When all 64 readers genuinely waited on one variable, either design sustained about 28,000 writes per second.
- The result demonstrates elimination of unnecessary wakeups rather than a claim that genuine fan-out is free.
Derived state
- Counts can be calculated from authoritative state rather than maintained as separately synchronized counters.
- Liveness can be derived from published state.
- Expiry can be derived from state and time policy rather than requiring a universal reaper.
- Blocked participants can be identified from the state describing what they await.
- Derived information cannot become inconsistent with a duplicate bookkeeping representation that does not exist.
Regions
- A Region is an independently governed shared-memory segment.
- Regions can have independent operators.
- Regions can have independent namespaces.
- Regions can have independent authorization.
- Regions can have independent semantics.
- Regions can have independent schemas.
- Regions can have independent lifetimes.
- Regions can have independent residency policies.
- Regions can have independent backing policies.
- Regions can be global, customer-specific, group-specific, session-specific, transaction-specific, or task-specific.
- Region scope and Region lifetime are independent choices.
- A narrow Region can persist and a broad Region can be ephemeral.
- Regions do not have to share a global coherence domain.
- Regions do not have to share a global transaction system.
- Regions do not have to reconcile automatically with one another.
- Regions do not require globally stable pointers between independently governed state spaces.
Internet RAM
- A Region can function as an Internet-mountable shared-memory segment.
- An application can mount independently governed remote state as working memory.
- Multiple vendors’ Regions can be mounted into one application’s working state.
- Mounted Regions remain independently governed rather than merging into one global database.
- Vendors whose Regions are composed by an application do not need to know about one another.
- Vendors do not need to share schemas.
- Vendors do not need to share credentials with one another.
- Vendors do not need to participate in a common consensus system.
- The consuming application defines relationships among truths obtained from independent Regions.
- A mounted Region can already contain useful state when the application first sees it.
- Pre-provisioned Regions can eliminate application-level bootstrap conversations.
Vendor-defined Internet RAM and SaaS
- A vendor can expose a Region at a well-known location while retaining ownership of the state.
- A vendor can define the Region’s schema, authorization, backing, lifecycle, residency, initial contents, and connectivity policy.
- A Region can represent long-lived business state.
- A Region can represent transient coordination.
- A Region can represent telemetry, catalog information, device state, game state, or other domain state.
- Regions can be pre-provisioned before an application mounts them.
- Configuration can therefore exist as an initial condition rather than requiring a startup GET.
- Permissions can exist as an initial condition rather than requiring a startup GET.
- Catalog and account information can exist as initial conditions rather than requiring repeated bootstrap requests.
- The SaaS model can expose authorized live memory containing what the service knows instead of requiring the application to repeatedly ask the service what it knows.
Extensible Region schema
- FrogNet does not impose one application schema on all Regions.
- Vendors define the tuple organization appropriate to their domain.
- Schemas can represent objects.
- Schemas can represent classes.
- Schemas can represent containers.
- Schemas can represent collections and membership.
- Schemas can represent indexes.
- Schemas can represent relationships and references.
- Schemas can represent hierarchies and arbitrary levels of indirection.
- Higher-level structures can resolve ultimately to the underlying tuple-space contract.
- Applications can operate on domain abstractions without knowing the physical tuple representation.
- Vendors can change internal representation while preserving their external application contract.
Extensible api.php programming surface
- api.php is a vendor-controlled programming surface rather than one fixed FrogNet application API.
- A vendor defines the operations appropriate to its own Region.
- A vendor API can expose raw state operations.
- A vendor API can expose queries.
- A vendor API can expose objects and collections.
- A vendor API can expose domain-specific operations.
- A vendor API can calculate results from underlying state instead of exposing storage layout.
- A vendor API can enforce domain-specific rules.
- A vendor API can hide tuple organization completely from consumers.
- A vendor API can front ephemeral state.
- A vendor API can front long-lived persistent state.
- A vendor API can front an existing domain-specific database.
- A vendor controls persistence and lifetime policy.
- A vendor controls behavior during network loss.
- A vendor controls split and merge semantics for its state.
- A vendor controls re-homing policy.
- A vendor controls reconciliation policy.
- A vendor controls authority and acceptance policy.
- A vendor can change its internal implementation without forcing consumers to change their domain API.
Residency
- Residency means a logical Region is currently materialized in live RAM.
- Region lifetime is not required to equal one residency interval.
- An inactive Region can leave live RAM without destroying its logical identity.
- Residency management can itself be implemented as an ordinary Ribbit participant.
- Residency therefore does not require adding a virtual-memory subsystem to the core memory server.
Backing
- Backing is whatever can reconstruct a logical Region after it leaves live RAM.
- Backing is a role rather than a specific storage technology.
- A Region can have no backing when its semantics are purely ephemeral.
- Backing can be implemented with a database.
- Backing can be implemented with another memory implementation.
- Changing backing technology does not require changing the Region’s programming abstraction.
- Backing policy belongs to the Region rather than to FrogNet RAM universally.
- Backing can be absent.
- Backing can be files.
- Backing can be MariaDB.
- Backing can be another C++ Memory implementation.
- Backing can be object storage.
- Backing can be a distributed store.
- The backing mechanism is deliberately not part of the application-visible RAM contract.
Materialization
- Materialization reconstructs a Region from backing into live RAM.
- Materialization order can matter because participants react to truths as they become visible.
- Reconstruction ordering is therefore vendor policy rather than a generic FrogNet assumption.
- A publication point can be written last to declare a reconstructed Region ready for use.
- Participants waiting on a Region can be released when its required visibility truth appears.
- Materialization demonstrates that storage lifecycle can itself be expressed using Ribbit’s ordinary programming model.
UnREST — §10 UnREST
- UnREST is the programming surface through which applications can use FrogNet’s state-oriented model.
- UnREST replaces unnecessary request/response choreography with operations on shared meaning.
- UnREST handlers can reinterpret an ordinary application interaction without requiring the application to know the network machinery underneath.
- UnREST can preserve an application’s existing outward-facing contract while changing how the work is represented internally.
- UnREST can support ordinary request/response applications.
- UnREST Unleashed can support interactions such as streams and games whose behavior does not fit ordinary request/response handling.
Semantic transport — §11 FNWP-1 and BLDC-1
- FrogNet performs semantic reduction before ordinary byte compression.
- Repeated structures can be represented by their learned meaning rather than retransmitted in full.
- Semantic comparison distinguishes SAME, DIFF, and FULL cases.
- FULL carries a complete representation when no reusable semantic context exists.
- SAME identifies content that does not need to be retransmitted.
- DIFF carries the semantic change relative to already shared context.
- Semantic state is reused across exchanges rather than treating every exchange as unrelated bytes.
- The receiving side reconstructs the application representation from the semantic wire representation.
- SAME is not a cache hit and does not mean the far side skipped execution.
- The far side executes the operation and obtains the actual current result before deciding that the result is SAME.
- The actual result is compared with the semantic reference before SAME can be returned.
- An unchanged demonstrated exchange can collapse to a 21-byte request and a 21-byte response after execution establishes semantic sameness.
BLDC — §11 FNWP-1 and BLDC-1
- BLDC provides semantic representation and comparison beneath applications.
- BLDC learns reusable structure from application representations.
- BLDC separates stable structure from changing values.
- BLDC can tokenize recurring semantic structures.
- BLDC can represent subsequent instances primarily by what changed.
- BLDC can collapse unchanged repeated information to a minimal representation.
- BLDC operates before conventional compression so redundant meaning can be removed before redundant bytes are compressed.
- BLDC can reduce bandwidth on constrained links without requiring application-specific bandwidth code.
- BLDC can reduce unnecessary transmission on fast links as well as slow ones.
Extensible BLDC language handlers
- BLDC handlers provide a programmable semantic boundary between application representation and network representation.
- New handlers can teach BLDC the structure of additional languages and protocols.
- A handler can parse language syntax into semantic elements.
- A handler can identify stable structural elements.
- A handler can identify changing values.
- A handler can tokenize recurring constructs.
- A handler can define what constitutes semantic sameness.
- A handler can define how semantic differences are represented.
- A handler can preserve the information necessary to reconstruct the original application representation.
- A handler can specialize semantic reduction to the characteristics of its language.
- Adding a language handler does not require changing applications that already speak that language.
- Adding a language handler does not require redesigning FrogNet’s transport.
- BLDC handlers therefore function as extensible wire-language compilers rather than simple compression codecs.
FNWP wire protocol — §11 FNWP-1 and BLDC-1
- FrogNet-bound HTTP can be transformed into FNWP rather than sent as HTTP between nodes.
- FNWP uses framed operations over established peer connections.
- FNWP carries semantic operations including SAME, DIFF, and full representations.
- Application protocol and FrogNet wire protocol are deliberately separated.
- Applications can continue speaking their ordinary protocol locally while FrogNet uses a different representation on the wire.
- Long-lived peer connections avoid requiring a fresh network connection for every application operation.
Transparent proxying — §11a Proxy and daemon
- FrogNet can transparently intercept application HTTP at the node boundary.
- FrogNet-bound traffic can enter semantic processing automatically.
- Non-FrogNet traffic can be forwarded normally without semantic transformation.
- Existing applications therefore do not need to become aware of FrogNet merely to obtain FrogNet transport behavior.
- Discovery traffic receives the same semantic and transport machinery because it uses the same generic path.
Proxy / daemon execution path — §11a Proxy and daemon
- The proxy can take ownership of an existing application interface.
- The proxy can intercept conventional application traffic.
- The execution path determines whether and how an interaction should use FrogNet’s semantic path.
- The operation is carried to the far side using FrogNet’s wire representation.
- The far side executes the underlying application operation against the origin.
- The current result is compared against semantic context after execution.
- The return representation can be reduced to SAME, DIFF, or FULL as appropriate.
- The receiving side reconstructs the behavior expected by the original application.
- This interposition allows an existing application contract to survive while the communication machinery beneath it changes.
FrogNet Plane
- Plane is a separate FrogNet contract for state that is too large, too frequent, or too perishable for ordinary Memory.
- Plane is optimized for current useful data rather than historical delivery.
- A publisher can publish a named current-value stream.
- A server-side reflector can fan one publication to multiple kept subscriber connections.
- Plane publication can use send-or-drop behavior instead of queue-and-replay.
- A value that cannot be sent while it is current can be discarded rather than allowed to become stale backlog.
- A newer generation supersedes an older unsent generation.
- The reflector does not need to retain stream history.
- Send-or-drop semantics bound staleness under overload.
- Plane can support identity reads.
- Plane can return SAME when a reader’s digest already identifies the current value.
- Plane can return DATA when current bytes are required.
- Plane can return GONE with a reason when the requested generation is no longer available.
- Plane supports blocking wait and wakeup for a requested newer generation.
- Plane supports expiration.
- Plane can optionally verify payload identity.
- Tensor Plane extends the same contract to large tensor payloads.
- Python-to-C++ tensor-plane interoperability has been demonstrated.
- C++-to-Python tensor-plane interoperability has been demonstrated.
- Python-to-Python and C++-to-C++ tensor-plane pairings have also passed the documented interoperation checks.
- Plane and Memory serve different state semantics while sharing FrogNet’s broader programming model.
Plane media scheduling and high-speed transport behavior
- FrogNet provides a high-speed data path distinct from ordinary Internet-RAM cells for bulk real-time payloads.
- The high-speed path can multiplex multiple logical channels over a permanent TCP connection.
- Channel priority can determine which traffic receives transport opportunity first.
- Large logical frames can be segmented so higher-priority traffic can run between segments.
- Non-blocking admission can reject already-obsolete media before it becomes queued stale data.
- TCP supplies reliable ordered delivery for segments that are admitted to the transport.
- Receivers can reassemble complete logical frames before delivering them upward.
Adaptive systems — §14 Performance and adaptation
- FrogNet separates network-route adaptation from application-representation adaptation.
- Route adaptation asks which reachable path should carry traffic.
- Communicator media adaptation asks what representation the current path can sustain.
- Communicator’s SotF model publishes observations as shared state.
- A pure derivation computes the target media rate from those observations.
- The target derivation has no clock, I/O, or memory of its previous decision.
- Local adoption policy can apply timing and hold-down behavior when moving toward the derived target.
- The target is a consequence of shared facts while adoption timing remains local policy.
Language independence
- FrogNet’s contract is independent of one implementation language.
- Python implementations have exercised the FrogNet/Ribbit programming model.
- C++ implementations have exercised the FrogNet/Ribbit programming model.
- PHP implementations have exercised the FrogNet programming surface.
- Independent Python and C++ implementations have demonstrated bidirectional interoperability.
- Cross-language implementations communicate through shared contracts rather than a shared runtime.
- FrogNet does not require one common application framework.
- Application-language independence is separate from BLDC wire-language extensibility.
Machine independence
- The programming model is not tied to one CPU architecture.
- FrogNet has operated on x86 systems.
- FrogNet has operated on ARM systems.
- The same application model can span heterogeneous machines.
- Machine capability can influence service placement without becoming application configuration.
Application-contract preservation
- Existing applications can retain their native external interfaces while FrogNet replaces machinery underneath them.
- PyTorch can retain its distributed-backend contract.
- Redis clients can retain the Redis protocol contract.
- HTTP applications can retain HTTP locally.
- Compatibility layers can translate mature external APIs into Ribbit operations without changing their clients.
Redis-on-Ribbit
- Redis-on-Ribbit implements Redis compatibility without using Redis server code.
- Stock Redis 7.2.11 serves as an independent behavioral oracle.
- RESP2/RESP3-facing clients can interact with the Ribbit implementation.
- Redis strings have been implemented over Ribbit.
- Redis hashes have been implemented over Ribbit.
- Redis sets have been implemented over Ribbit.
- Redis lists have been implemented over Ribbit.
- Redis sorted sets have been implemented over Ribbit.
- Redis geospatial behavior has been implemented over Ribbit.
- Redis HyperLogLog behavior has been implemented over Ribbit.
- Redis streams have been implemented over Ribbit.
- Redis consumer groups have been implemented over Ribbit.
- Redis MULTI/WATCH semantics have been implemented over Ribbit.
- Redis blocking operations have been implemented over Ribbit.
- Redis expiry semantics have been implemented over Ribbit.
- Redis testing forced fairness semantics into claims without turning the memory substrate into Redis.
- Redis testing forced multi-value visibility semantics to be expressed without turning Ribbit into a Redis transaction engine.
- Redis demonstrates that a mature independently designed API can be expressed over the same small Ribbit vocabulary.
Psychedelic FrogTorch
- FrogTorch implements PyTorch distributed operations over FrogNet Memory.
- PyTorch itself remains unchanged.
- all_reduce has been demonstrated.
- barrier has been demonstrated.
- broadcast has been demonstrated.
- all_gather has been demonstrated.
- reduce has been demonstrated.
- Contributions can materialize independently as shared state.
- Remote reads do not have to reproduce conventional collective-message choreography.
- Ordinary DDP semantics can be retained while the backend changes the communication model.
- Heterogeneous machines have participated in the same distributed training workload.
- Seattle and New York machines have participated in the same distributed operation.
- A New York contribution has been observed materializing before a Seattle contribution.
- FrogTorch demonstrates distributed numerical computation as an algorithm over shared truth rather than necessarily as an algorithm over messages.
- Same-campaign FrogNet/Gloo comparisons have produced 1.95x, 1.64x, 1.03x, and 1.75x results.
- Separate heterogeneous-mesh measurements produced approximately 1.47–1.77x Gloo per-element rate for Psychedelic all_reduce.
- FrogTorch demonstrates the possibility of treating geographically distributed compute as resources behind one shared-state programming surface.
Communicator — §15 Reference applications
- Communicator demonstrates FrogNet in a latency-sensitive continuously changing application rather than a datastore workload.
- Communicator implements presence.
- Communicator implements chat.
- Communicator implements bidirectional audio.
- Communicator implements bidirectional video.
- Audio receives priority over video.
- Video can be segmented to prevent large frames from monopolizing the transport.
- Keyframes can be segmented rather than treated as indivisible transport units.
- Obsolete video can be discarded before it enters a stale transmission queue.
- Media quality can degrade as available capacity falls.
- Media quality can recover as available capacity returns.
- Adaptation can remember previously unsuccessful transmission sizes.
- Communicator has demonstrated bidirectional 160×120 video at 24 fps with uninterrupted prioritized audio.
- The demonstrated constrained operating point was approximately 121 Kbps.
- The demonstrated path included Seattle, Internet/WireGuard transport, New York, and a 900 MHz radio segment.
- Communicator demonstrates that FrogNet’s model extends beyond CRUD, databases, and bulk computation.
Monitor — §15 Reference applications
- Monitor expresses observability as published system truth.
- Observers derive the views they need from changing shared state.
- Monitoring does not require every observed component to conduct a separate request/response conversation with every observer.
- Monitor demonstrates a Prometheus-like application class using the same state-oriented model.
- A producer can add another published fact without registering a new communication relationship with each observer.
- A sufficiently generic Monitor can display a newly published fact on its next read.
- Adding a new monitored fact need not require changing the monitoring system.
- Adding a new machine need not require reconfiguring a central monitoring server.
Sourri
- Sourri demonstrates ordinary application programming over Ribbit.
- Users can be represented as independently addressable state.
- Conversations can be represented as containers and relationships among truths.
- Conversation turns can remain independently addressable rather than being repeatedly serialized as one growing object.
- Readers can calculate the turn addresses they require and read them independently.
- Unchanged turns remain unchanged truths.
- References express relationships among application objects.
- Held reads express actual application dependencies.
- Participant behavior supplies application logic above the memory substrate.
- Sourri demonstrates that the model can support ordinary SaaS-style application structure rather than only infrastructure experiments.
Residency / Swapper experiment
- The swapper is an ordinary participant rather than a special memory-server subsystem.
- An inactive Region can be copied to backing and verified before removal from live RAM.
- A returning consumer can publish demand for a nonresident Region.
- A consumer can park on the truth it requires while materialization occurs.
- The swapper can reconstruct the requested Region from backing.
- The visibility marker can be published last so consumers never observe a partially usable Region as complete.
- Backing has been changed from MariaDB to another C++ memory implementation without changing the abstraction.
- The experiment demonstrates infrastructure implemented with Ribbit rather than added beneath Ribbit.
- The residency oracle verified backing cell-for-cell before removal from live RAM.
- The residency oracle demonstrated Want publication on return.
- The residency oracle demonstrated parking while the required Region was absent.
- The residency oracle demonstrated rematerialization and publication-point wakeup.
- Conversation continued after rematerialization.
- Earlier reconstructed history was byte-identical in the documented test.
- Recovery from a kill during copy/remove was exercised.
- Replacing MariaDB backing with a second C++ Memory preserved the behavior.
Physical control
- FrogNet shared state can cause physical action at a remote location.
- A lamp in New York has been actuated from Seattle.
- The demonstrated physical-control distance was approximately 2,400 miles.
- Physical devices can therefore participate in the same truth-oriented programming model as software.
Sensors, actuators, AI, robotics, and automation
- A sensor can publish what it knows as shared state.
- An actuator can read the state on which its action depends.
- An AI system can read the same operational state as other participants.
- An AI system can publish derived state or decisions back into the shared state space.
- Multiple AI systems can operate simultaneously over the same world state.
- Multiple dashboards can observe the same real-time state simultaneously.
- Sensor-to-actuator loops can operate entirely without Internet connectivity.
- Sensor and actuator concentrators can publish into shared Memory over Bluetooth, Wi-Fi, or Ethernet.
- External radio systems can appear as data endpoints that write observations into shared Memory.
- FrogNet can also ride radio infrastructure as a transport bearer.
- Robotics can use the same publish/read model for perception, decisions, and actuation.
Cross-language interoperability
- Python and C++ implementations have interoperated against the same tensor-plane contract.
- Python-to-C++ operation has been demonstrated.
- C++-to-Python operation has been demonstrated.
- Cross-language interoperability demonstrates that the contract rather than one implementation defines the system.
- C++ chat clients have operated against the same shared-state model as Python implementations.
Governed state and games — §15 Reference applications
- A participant can publish intent without directly modifying authoritative resolved state.
- A governing engine can validate published intent.
- The governing engine can be the single writer of resolved authoritative game state.
- Players can read authoritative board or world state rather than sending moves directly to one another.
- Single-writer governance preserves authoritative truth without requiring peer-to-peer application messaging.
- Game state can therefore use the same shared-state model while retaining application-defined authority.
SuperTuxKart experiment — in progress
- The SuperTuxKart experiment asks how much conventional game-networking code can disappear when the application is re-expressed as shared state.
- Instrumentation exists to compare stock and modified runs by tick and kart.
- The validator records position, rotation, linear and angular velocity, speed, steering, energy, and finish state.
- The intended architecture places object and control state in Memory.
- The intended architecture places fast kinematics in Plane.
- The validator framework exists, but the cited technical reference does not claim completed physical-machine qualification.
Concurrency and ordering evidence
- Multi-client cross-posting tests have preserved value order.
- Multi-client cross-posting tests have avoided duplicate delivery.
- All readers observed the writer’s final published value.
- Contention tests have exercised competing operations on shared state.
- Acknowledged C++ contention testing has demonstrated zero dropped values in the measured run.
- Unacknowledged high-rate testing has demonstrated the distinction between freshness and observing every generation.
- FrogNet therefore distinguishes semantic requirements such as latest-value freshness from requirements to observe every intermediate generation.
Qualification and characterization — §16 Simulator and conformance
- FrogNet distinguishes proving that a contract works from measuring how a particular implementation performs.
- Loopback tests can qualify semantics independently of WAN behavior.
- Internet tests can qualify the same contracts across real networks.
- Performance measurements are treated as reference measurements rather than portable architectural limits.
- External behavioral suites can be used as independent oracles for compatibility work.
- Failures can be classified as implementation defects, misunderstood external contracts, or semantics the FrogNet model intentionally does not reproduce.
- Benchmark tooling can characterize throughput, latency, skipped generations, receive queues, and saturation boundaries separately.
FrogSim — §16 Simulator and conformance
- FrogSim provides a simulation environment for FrogNet behavior.
- Simulation allows network behavior to be exercised without requiring every target physical topology.
- Simulation participates in qualification of FrogNet mechanisms and applications.
Application composition
- An application can compose truths from multiple independently governed Regions.
- Relationships among independently governed Regions belong to the consuming application.
- One vendor does not have to federate with another vendor merely because one application uses both.
- Applications can read truths from several Regions and publish derived truths into another Region.
- Cross-vendor composition therefore does not require a universal schema, database, consensus system, or authority.
Vendor extensibility
- Vendors control the schema through which their domain is represented.
- Vendors control the API through which their domain is exposed.
- Vendors control Region scope.
- Vendors control Region lifetime.
- Vendors control backing.
- Vendors control residency.
- Vendors control reconstruction ordering.
- Vendors control split/merge policy.
- Vendors control reconciliation policy.
- Vendors control authority.
- Vendors control security policy.
- Vendors can replace internal implementation technologies without changing the application’s relationship to the Region.
- FrogNet supplies generic machinery while deliberately leaving domain truth to the domain owner.
Extensibility axes
- BLDC handlers make the wire-language semantic layer extensible.
- api.php makes the vendor programming interface extensible.
- Region schemas make the data model extensible.
- Participants make behavior extensible without continually enlarging the core memory server.
- Service selectors make infrastructure placement extensible without enlarging one central election algorithm.
- Backing implementations make persistence technology extensible without changing the RAM abstraction.
- Transport independence makes physical connectivity extensible without changing applications.
- These extension points allow FrogNet to generalize mechanisms without forcing one universal application model.
Explicit architectural boundaries and non-claims — §17 Known limits
- FrogNet/Ribbit does not claim one globally coherent heap.
- FrogNet/Ribbit does not claim global transactional memory.
- FrogNet/Ribbit does not claim global transactions across independently governed Regions.
- FrogNet/Ribbit does not provide automatic cross-Region consistency.
- FrogNet/Ribbit does not provide automatic cross-Region reconciliation.
- FrogNet/Ribbit does not provide automatic cross-Region transactions.
- FrogNet/Ribbit does not claim zero synchronization where a real dependency exists.
- FrogNet/Ribbit does not claim zero contention where participants genuinely contend for the same authority.
- FrogNet/Ribbit does not claim genuine fan-out is free.
- FrogNet RAM does not claim permanent or infinite physical RAM.
- Ribbit does not require every opaque algorithmic value to be decomposed into independently addressable cells.
- Regions do not acquire globally stable pointers merely because an application composes them.
- Current benchmark results characterize stated implementations and environments rather than establishing universal architectural limits.
Core architectural consequence
- FrogNet moves distributed-program complexity away from explicit communications machinery and toward the application’s actual state and rules.
- Things traditionally treated as intrinsic constraints of distributed applications can therefore be tested as possible artifacts of a message-oriented programming surface.
- The application defines what its truths mean while FrogNet handles the generic machinery required to make those truths usable across machines and networks.