The seminal literature on Linked Data sets the following founding principles [4]:

1. Use URIs as names for things.\

2. Use HTTP URIs so that people can look up those names.\

3. When someone looks up a URI, provide useful information.\

4. Include links to other URIs, so that they can discover more things.\

In the multi-protocol context at hand, where the second principle no longer holds, a re-formulation of it could be to "Use Web URIs [...]", intending "Web" in a broad sense. We then want to ascertain that, in such an environment, the other principles still hold true. A core use case that shall be adopted to that end is the one of serving Linked Data as sites on the Small Web–which are sometimes called capsules or stations–either natively hosted or retrieved by proxy from the HTTP-based Web. This will not be achieved by extending the Small Web protocols: their characteristics, used to extract an irreducible core contract from their lowest common denominator, are regarded not as constraints, but as capabilities superimposed on said contract. Consequently, whereas the HTTP-dependent Linked Data Platform [12] is acknowledged, it cannot be taken as reference, in contrast to other approaches in the Internet of Things.

The remainder of this paper is structured as follows: Section 2 provides an overview both on the landscape of current-generation Small Web protocols and on prior approaches to minimalist management of Linked Data. Section 3 summarises the specification, covering the salient characteristics of both the core contract and wire format. Sections 4 and 5 delve into the specifics of the format and transport protocols at hand, respectively. Section 6 illustrates the reference implementation, which is validated in Section 7 against the specification and available client tools. Section 8 revisits the stated objectives and discusses them in terms of their implementation, whilst setting out medium-term prospects.

Although none of these protocols have been submitted to the IETF for standardisation, they are each at various stages of maturity and enjoy diverse adoption. The present work aims at treating them equally, regardless of maturity.

2.1.1 Gemini. Gemini2 was introduced in 2019 as an evolution of traditional Gopher, with modernisations such as mandating TLS-encrypted connections and natively using a hypertextual content type, Gemtext (§2.2). Although Gemini is read-only and rigidly inextensible by design, sister protocol Titan3, which should listen to the same TCP port as Gemini (1965 by default), was designed for uploading data. In Gemini jargon, a site is called capsule, and the set of all known capsules is known as Geminispace. As of March 2026, Geminispace is known to comprise about 4850 capsules.4

2.1.2 Spartan. Admittedly a hobbyist-oriented protocol inspired by Gopher and Gemini, Spartan5 strives for extreme simplicity, opting for unencrypted TCP, reducing its status codes to 4, and dropping request parameters. It also accepts Gemtext as content type but, unlike Gemini, it supports data upload natively. Spartan uses TCP port 300.

2.1.3 Nex. Nightfall Express, or Nex,6 is likely the least developed of these protocols, yet it still enjoys third-party support. It is a minimalist, stateless protocol whose request payload (on port 1900) consists of an optional path, and that has no response headers. It supports a line-oriented plaintext content type with hyperlinks. Nex is read-only, but can be paired with sister protocol NPS7 for uploading data to port 1950. A Nex online resource is called a station.

The focus of this work is on the protocols that have seen the most extensive development and adoption with third-party client and/or server implementations (§7.2). A plethora of further internet protocols that can be likened to the Small Web are being proposed, including Mercury, Scorpion, Guppy, and Molerat.8 For any of these to be considered in the future, even in the event that they should challenge our current core contract and wire format, they will require substantial adoption beyond the reference implementation offered by the proponents of the protocols themselves.

Table 1 consolidates what distinguishes the five protocols from one another, and, not coincidentally, what distinguishes all of them from HTTP as it is exploited by the Linked Data Platform: no verb space, no general header mechanism, and no content negotiation, the three pillars LDP's semantics are built on (§2.3).

Table 1: Feature comparison of the five Small Web protocols, focused on properties that bear on the feasibility of an LDP-like binding. Titan and NPS are mostly wire-identical to their read counterpart, differing only in the operation admitted.

Gemtext (unofficial MIME type text/gemini; filename extension .gmi) is the default information interchange format for Gemini, also supported by Spartan. It is a lightweight markup format with support for hyperlinks, headings, preformatted text, bulleted lists, and blockquotes.9

A key characteristic of Gemtext is that lines are strictly delimited, therefore a single line can have one purpose and one only; this implies, for example, that a list item cannot contain a link. Unlike HTML or most of Markdown, multiple lines are not meant to be joined together by a rendering engine.

Standards-wise, the reference W3C recommendation for a Web protocol binding of Linked Data is the Linked Data Platform (LDP) [12, 18]. It delineates regulations for using HTTP to read and write RDF resources organized into typed containers, giving clients a uniform protocol for create-read-update-delete (CRUD) operations and membership management over Linked Data on the web. By contrast, the SPARQL query language specification has HTTP bindings wired into it [8]. As LDP is strongly aimed at leveraging the full potential of HTTP semantics, this work does not seek to implement or replicate LDP in the Small Web, but rather to encode the strict interactions assumed by the latter in terms of data consumption.

The academic literature on the aforementioned Small Web protocols of the current generation is virtually non-existent. However, that of bridging Linked Data over to non-HTTP protocols is not an entirely novel idea, as it has been explored in the Internet of Things, under constraints that are largely orthogonal to the ones addressed here. Hasemann et al. devised a method for constrained sensor nodes to publish RDF descriptions of themselves over 6LoWPAN/CoAP [9]; their concern, however, is the compactness of the RDF encoding for devices with kilobytes of RAM and no filesystem, while the transport exposed to clients remains a document-level, CoAP-based interface with explicit GET/POST/DELETE/SUBSCRIBE operations, i.e. a request/response model with a method set and a subscription mechanism that plays the role headers and content negotiation play in HTTP. The closest work to our intent is that of Loseto et al., who map the Linked Data Platform's container and membership model onto CoAP [14]; their own reference implementation describes its proxy component as translating “LDP-HTTP request methods and headers into the corresponding LDP-CoAP ones,” aimed squarely at machine-to-machine Web of Things scenarios. Both lines of work therefore translate yet retain, at the transport level, a verb-and-header apparatus and target machine clients that never need a document to double as human-navigable hypertext, unlike the wire format of most of the Small Web (§3.2). They therefore cannot be transposed wholesale onto a core contract that defines only a request URL and a binary OK/Error outcome (§3.1); they nonetheless corroborate the premise that a leaner transfer protocol need not preclude Linked Data compliance.

Data decentralisation as proposed by the Solid framework is also worthy of observation, not least because it shares this work's ambition of returning agency over Linked Data to its producers. Solid Pods are LDP containers exposing the standard HTTP method set, with access control implemented as a separate ACL resource whose association is advertised through a Link header, with resource/storage discovery similarly conducted through Link headers rather than through the request path or body [16]. None of these mechanisms has a counterpart in the present core contract, which defines no headers and no verb beyond an implicit request (and, via sister protocols, an equally implicit upload). Solid adoption has seen prudent yet steady progression. Notably, deployments such as SOLIOT do not merely graft Solid's access-control philosophy onto an unchanged HTTP substrate: Bader and Maleshkova explore adapting it to CoAP as well as another lightweight IoT protocol, MQTT [3], showing that Solid's data-control model can migrate away from HTTP. Yet CoAP retains a REST-like method set and an options mechanism, while MQTT retains topics, quality-of-service levels, and a broker-mediated publish/subscribe contract—neither dispenses with the request/response or headers-equivalent apparatus altogether. The applicability of the Solid data model, and in particular its container-based resource organisation and access-control paradigm, to header-less, single-verb Small Web transports such as Gemini and Spartan therefore remains an open question, one only partially anticipated by SOLIOT's move away from HTTP.

The atom of information is the RDF triple: (subject, predicate, object). This specification retains the assumptions of the RDF 1.1 Concepts and Abstract Syntax specification, whereby subject is a non-literal node, predicate is an IRI, and object is any RDF node [7]. A resource description may be the set of all triples sharing a node as subject or object.

3.1.1 Identity of RDF Resources. Every resource that can be requested by a client is identified by an IRI. IRIs may use the <http[s]://>

scheme, or a Small Web scheme (e.g., gemini://, spartan://) if natively served in that protocol.

3.1.2 Read Request. The Linked Data resource being requested is defined by the request URL alone, as it is the only omnipresent and consistent element across protocols. The IRI of said resource is provided in one or two ways:

as the full request URL, e.g. gemini://example.smol/0123456789abcdef; or\

encoded in the URL path, in the form <protocol>//<host>[:<port>]/<rsrcIri>, where <rsrcIri> is URL-encoded. Example: nex://example.smol/http%3A%2F%2Fwww.wikidata.org%2Fentity%2FQ257469.\

A client sends exactly one IRI per request using either method. Whether the resource data are to be locally retrieved by the server, or proxied from a third-party host, is determined solely by the first or second request form being used, respectively, i.e. the part of the request path that follows the system one is an URL-encoded IRI. HTTP(S) resources will typically be proxied. Method 2 should not be used to proxy to the same host that received the request.

Lastly, there is no assumption on returning a “not found” response when there are no data describing a possible entity URI: this is in line with the underlying assumption of the Semantic Web or the LDP specification, where a HTTP 404 or an empty body are both possible, but neither is mandated. Hence, only “OK” and “Error” outcomes are defined.

3.1.3 Hosting vs. Retrieval. A provider that hosts Linked Data natively on a Small Web site, i.e. a capsule or station, may commit to giving each data entity a cross-protocol identity, by minting URIs for each supported protocol. One key consequence is that, due to its repercussions on the logical interpretation of entity statements, the authority host and domain of resource IRIs never change across protocols. This no-rewrite policy implies, for instance, that there shall be no gemini://www.wikidata.org/... resource to match the original HTTP one—barring the unlikely event that Wikidata starts serving to the Small Web. For that reason, it is also safe to assume ontological equivalence, such as with implied owl:sameAs or owl:equivalentClass statements, across entity IRIs that differ by protocol. Because domain names are not rewritten, the server supporting multiple protocols, be they HTTP or Small Web, shall be one and the same, therefore it should retrieve the same statements regardless of the protocol: it may therefore add equivalence statements such as (nex://example.smol/entity1 owl:sameAs gemini://example.smol/entity1).

Figure 2 operationalises the Core Contract as described: whether an IRI is resolved locally or proxied from HTTP(S) is decided once, by scheme alone, and both paths converge on one binary outcome.

A flowchart beginning at a client request carrying one IRI. A decision on the IRI scheme branches left to a proxy fetch for http or https resources, using Turtle with an RDF/XML fallback and a scheme-swap retry, or right to a local lookup for a native Small Web scheme. Both branches converge on a decision of whether a resource description was found. If not, the flow ends in an Error outcome. If found, the resource is serialised as Gemtext-LD, in expanded or condensed mode, ending in an OK outcome.

Figure 2: Resolution flow for a Core Contract request.

For the so-called wire format, i.e. the markup format assumed for data transfer by default, we postulate the following:

that it must be a prefix-dispatched, line-oriented markup format;\

that it supports hyperlinking by means of URL parsing.\

The acronym PDL-HL will be use to refer to the above. In (1), we call a markup format line-oriented when whitespace is not collapsed across newlines, unlike in HTML; and prefix-dispatched when the syntactic construct into which a line is parsed is determined solely by its leading k characters, i.e. a fixed-length prefix discriminator, or sigil. It follows that each line constitutes an independent syntactic unit. No assumption is made, however, as to how many consecutive lines constitute an atomic semantic unit: that determination is delegated to the hypertext layer, which is why (2) is required.

The assumed semantics of hyperlinks warrant a commitment at the core contract level regarding whether or not wire formats must reflect the identity of Linked Data resources in their rendering. Because there is no guarantee that a line representing a link has an anchor text, the identity of the referenced RDF resource must be reconstructable from the rendered hyperlink alone. Concretely, while a hyperlink should resolve to a representation of the resource under any supported protocol, it must be rendered so as to display the protocol of its identity (typically HTTP for non-Small-Web resources). This separation of concerns permits URL (but not entity IRI) rewriting in formats that support anchor texts, preserves isomorphism between wire-format Linked Data and RDF, and ensures that Linked Data principles 3 and 4 continue to hold: it remains possible to discover entities and resolve their identities, even when this should need requests to branch off from the Small Web to HTTP—a circumstance that several protocol designs contemplate.

A response body is a sequence of resource descriptions. A resource description takes the following form:

Level-1 headings therefore delimit groups of statements. For property blocks, two serialisation modes are defined:

Expanded (default): one Gemtext line per triple.\

Condensed (optional): triples grouped under level-2 headings of the form "## <predicate>".\

In this encoding, described in Table 2, the creation of hyperlinks for objects–their URIs if resources, or datatype IRIs if literals–is prioritised. Each triple (subject, P, object) produces exactly one Gemtext line.

Table 2: Expanded mode object encoding.

The example below renders the Wikidata statements that entity Q257469 is a video game with two English titles. It assumes a Gemini proxy is running on localhost (port 1965 implicit). Line 2 is wrapped for display purposes.

Condensed mode supports QNames, whose prefixes are declared in a preamble with level-1 heading # Prefixes. Prefix URIs are not hyperlinks. Triples are grouped by predicate: groupings may be sorted. Each predicate group produces:

A level-2 heading: ## <shortP> \

If P is an HTTP or Small Web URI, a property navigation link: => <P> ↗ <shortP> 11 \

One line per object value, as defined in Table 3.\

A trailing blank line.\

Table 3: Condensed mode object encoding (within a predicate group).

The listing below, sans the trailing blank line, shows the same statements in condensed mode. Note that, due to the increased context length and the more verbose syntax for the preamble and predicate headers, this mode is only recommended for RDF descriptions with non-human-readable IRIs and many statements sharing the same predicate.

Because of the significant differences between expanded and condensed encoding, it should be the client application's responsibility to request the latter if needed. To that end, HTTP-like query parameters may be supported.

Gemini supports read requests with no parameters. Of the status codes it returns, 10-19 is for requesting user input.

Transport: TLS 1.2+, port 1965\

Request line: gemini://<host>[:<port>]/<path>rn \

Response: <status> <meta>rn<body> \

<meta> may include any of lang and charset, i.e. the only response parameters that a Gemini client should process: these are assumed to be the union of languages and charsets of all the RDF literals present in the Gemtext-LD.

IRI derivation: the full request URL is the lookup IRI iff the path is not an absolute URL; otherwise, the path.

Interactive entry point: a request to / with no query string returns a Gemini input prompt (status 10). The user's input is the IRI to resolve.

Responses: status 40 (temporary failure) for validation errors; status 20 for success, MIME text/gemini.

Titan defaults to the same port as Gemini. A Titan request is distinguished by the titan:// scheme in the request line.

Request line: titan://<host>/<path>;size=<n>;rn \

Payload: exactly <n> bytes; the first line of the payload is the IRI to resolve.\

Response: same as Gemini (20 text/gemini or 40 on error).\

Being the only protocol to natively support submit, it needs dedicated path semantics to denote either operation.

Transport: plaintext TCP, port 300\

Request line: <host> <path> <length>rn \

Payload (if length > 0): exactly length bytes\

Path semantics: /submit reads payload, first line as IRI; otherwise /<anything> is treated as the IRI to resolve.

Response line: <status> <meta>rn<body>. A successful response status is “2 text/gemini”, whereas temporary and permanent failures are “4 <message>” and “5 <message>”, respectively

Transport: plaintext TCP, port 1900\

Request: a single line /<percent-encoded-IRI>n \

Response: raw plaintext body, no status line\

The IRI is URL-decoded before lookup. Since Nex has no status header, outcomes (success, error) are communicated entirely within the body. A Gemtext body is assumed to be returned, of which Nex clients treat only => lines specially.

NPS is the write companion to Nex, as Titan is to Gemini. Unlike Titan, it defaults to a separate port.

Transport: plaintext TCP, port 1915\

Request: multiple text lines terminated by a line containing only the "." character\

Response: raw plaintext body, no status line\

The first non-empty line of the payload is the IRI to resolve. Multi-line payloads allow editor-friendly submission: the user composes text, appends a terminator line, and pipes to the server.

To ensure a lossless conversion of RDF data into Gemtext-LD and back to RDF, the gemtext-ld crate carries 42 unit tests, covering five node types (IRIs, blank nodes, and three forms of literals) in both expanded and condensed serialisation modes. A substantial subset targets edge cases: misclassifying newlines in literals, non-registered namespace prefixes, subjects and predicates within registered namespaces, non-HTTP datatype URIs, complex BCP 47 language tags, embedded double-quotes, non-HTTP IRI objects in condensed mode, declaration and round-tripping of document-local prefixes for namespaces outside the registered set (§4), and disambiguation of nested, overlapping namespaces (e.g. Wikidata's prop/ versus prop/direct/). The implementation was refined until the suite passed and all edge cases round-tripped correctly without modification. As this suite grows with the format, the count above is a snapshot as of this writing; the authoritative, current figure is reproducible by running the test suite in the repository (§6).

The Chaykin server returns data per the client requests in all the five supported protocols. This has been verified through dedicated Small Web clients and general-purpose command line tools.

For the former, the browsers Lagrange13 and Alhena14 were used. Both are actively developed, cross-platform, and aiming to support all the protocols contemplated here, though neither supports NPS at the moment. For Spartan upload and Titan, these browsers open dialogues for inputting the entity URI in plaintext, which they URLencode in the request. Following the standard practice of IETF/W3C working groups, it was verified that: IRIs are resolved, links are navigable, condensed/expanded modes display correctly, and the HTTP proxy path fetches third-party RDF/XML or Turtle data.

Both clients successfully retrieved Gemtext-LD data requested through all supported protocols, though Alhena's behaviour with data retrieved via Nex was to save the payload to disk, due to strictly depending on the file extension. A revision of the protocol bindings to support lightweight, protocol-specific content negotiations and redirecting to URLs ending in .gmi could be considered. Both browsers seamlessly follow protocol switches in hyperlinks, e.g. spartan:// links in a document retrieved via Gemini, though this is an edge case assumed across different capsules/stations.

The same characteristics, sans navigability and rendering, were verified using command line internet clients netcat and openssl. The following is a minimal test suite in Bash scripting on a local server accessed in loopback.

Two store backends are available: a naive store performing a linear scan per request—O(n) for expanded Gemtext-LD and O(nlog n) for condensed, with n = number of triples—and an indexed store trading a costlier, tree-structured load for an O(k) resource lookup, with k = number of statements about the requested resource, obviating the re-grouping and re-sorting condensed mode otherwise requires. Preliminary benchmarks confirm the expected trade-off–faster lookup, slower load–but also that its magnitude is sensitive to the shape of the data, not merely its size; a systematic characterisation across representative Linked Data distributions is left to the extended validation report mentioned below.

The above establishes conformance and cross-client interoperability for a single reference implementation; it is not a broader empirical assessment of adoption, usability, or comparative advantage over incumbent approaches such as the Linked Data Platform. The capsules exercised throughout this section–a synthetic dataset for round-trip testing and a proxied Wikidata entity for client retrieval–are rather short of a representative sample of Linked Open Data in the wild. Establishing that the contract is not merely satisfiable but useful requires deploying it over real capsules and stations at scale, gathering reports from a wider set of clients, and the SPARQL-over-Small-Web and LDP-comparison studies already outlined as future work (§8). An extended validation report–the full conformance checklist, client logs, and performance benchmarks across representative Linked Data distributions–is maintained alongside the codebase (§6) and updated independently of this paper.