Date: 2026-04-16 Status: Research / Architecture note Purpose: Reframe smolnet support around protocol capabilities rather than named protocols, define a transport-plus-format architecture for Middlenet adapters, tier follow-on protocol priorities, and highlight Scroll as a strategic protocol because its UDC-centric worldview aligns unusually well with Graphshell and Verse.

Related:

• 2026-03-28_smolnet_follow_on_audit.md
  • admission-bar audit for Titan, Spartan, Misfin, Nex, and Guppy
• ../../graphshell_docs/technical_architecture/2026-03-29_middlenet_engine_spec.md
  • Middlenet scope, portable engine framing, and protocol/content-space model
• ../../graphshell_docs/technical_architecture/2026-04-16_middlenet_lane_architecture_spec.md
  • lane split, async rendering lifecycle, and HTML-lane boundaries
• ../../graphshell_docs/implementation_strategy/viewer/2026-04-16_smolweb_compliance_and_middlenet_html_contract.md
  • HTML/CSS support contract for Middlenet's HTML lane
• ../technical_architecture/VERSO_AS_PEER.md
  • current Gemini/Gopher/Finger baseline and Verso placement
• ../../verse_docs/technical_architecture/VERSE_AS_NETWORK.md
  • Verse community/index posture and UDC-facing network context

External references:

• Scroll spec portal: https://portal.mozz.us/gemini/scrollprotocol.us.to/spec.scroll
• Scroll specification text provided in-session on 2026-04-16

---

The earlier smolnet follow-on audit was intentionally conservative. It asked which post-Gemini/Gopher/Finger protocols deserved native attention first and why. That was the right question for an initial admission bar.

What is now needed is a broader architectural lens:

• the smolnet world is larger than Gemini/Gopher/Finger plus a few nearby follow-ons
• many named protocols collapse into a small number of capability and format families
• Middlenet should scale by composing transport and format handlers rather than by adding bespoke protocol stacks one by one
• Scroll deserves special treatment because it is not just another retrieval protocol; it natively carries UDC semantics that align with Graphshell's and Verse's own classification ambitions

This note therefore complements the earlier audit rather than replacing it.

---

Viewed by protocol name, the ecosystem looks sprawling. Viewed by capability, it is much more compact.

These protocols primarily answer "request an address, receive a document or directory-like response":

• Gemini
• Gopher
• Gopher+
• Finger
• Spartan
• Nex
• Scroll
• Mercury
• Scorpion
• Text
• Guppy
• Molerat
• Terse
• FSP
• SuperText

These protocols extend the "retrieve a document" model with body-bearing requests or upload semantics:

• Titan
• Spartan

These protocols are primarily about sending messages rather than retrieving a document:

• Misfin
• NNCP is adjacent here conceptually, though it is better treated as later infrastructure for intermittent or offline-first messaging than as a core smolnet document lane

These are usually services hosted on existing protocols rather than distinct wire protocols:

• GUS
• CAPCOM
• Antenna
• Cosmos
• Spacewalk
• Wander

The important architectural consequence is that Graphshell should not ask "which named protocols do we support?" first. It should ask which capability families the product needs and then map protocols onto them.

---

Most smolnet document protocols vary along a handful of axes:

Axis	Common values
Transport	Plain TCP / TLS / Noise / UDP with acknowledgement
Status model	None / single digit / two digit / small enumerated family
Content declaration	Item-type implied / MIME-like header / implicit
Content format	Gemtext-like / Gopher menu / plain text / richer gemtext variant / raw
Identity model	None / client certificate / protocol-specific identity binding

This reframing matters because it collapses many "new protocol" requests into a much smaller implementation surface:

• Gemini and Spartan are near-neighbors once transport and body-bearing request differences are isolated
• Scroll is best understood as a Gemini-shaped protocol with additional semantic and formatting structure
• Mercury, Text, and Nex simplify parts of the same general retrieval shape
• Guppy changes transport behavior more than it changes document semantics

The capability model Graphshell should expose is therefore something like:

• retrieve document
• publish or upload
• send message
• discover identity or endpoint
• query with user input
• navigate an index or menu

App-level flows should target capabilities, not protocols. "Publish this" or "query this source" should route through the protocol registry to a capability provider, rather than baking Titan, Spartan, Gemini, or Gopher-specific logic into the product surface.

---

The current lane split in Middlenet is still correct: adapters produce content and renderers realize it. What needs tightening is the adapter architecture so it scales across smolnet protocols without becoming a protocol zoo.

A transport-focused crate SHOULD own wire-level mechanics:

• connection type: TCP, TLS, Noise, UDP-with-ack
• request shape: URL only, URL plus selector, URL plus input, URL plus body
• response framing: no header, single-digit status, two-digit status, item-type-prefixed menus, and similar families

In that model, many protocols become configuration plus a small amount of edge-case handling rather than wholly separate implementations.

A format-focused crate SHOULD own content decoding into SemanticDocument fragments or deltas:

• gemtext core
• gemtext extensions
• gopher menu
• plain text with links
• feed formats
• Markdown
• raw faithful-source rendering when needed

Gemtext-like variants should share one parser core plus extension hooks rather than forking early.

The adapter crate SHOULD be glue:

• choose transport configuration by scheme or endpoint capability
• choose format parser by content declaration and protocol rules
• produce streamed DocumentDelta output into the Middlenet lane system

This keeps protocol comprehensiveness mostly an adapter-level cost instead of a whole-engine redesign each time.

---

Not every protocol deserves equal effort. A tiered posture keeps Graphshell honest and maintainable.

• Gemini plus Titan
• Gopher
• RSS, Atom, and JSON Feed
• Finger
• Markdown and plain text
• Spartan
• Nex

These either have clear deployment reality, very low incremental cost, or both.

• Misfin
• Scroll
• Text

These are worth support once the adapter architecture is capability-driven. Misfin matters because it gives smolnet a real messaging lane. Scroll matters because of semantic alignment with Verse and Graphshell. Text matters because it expands the transport and trust surface in a way that is still conceptually compact.

• Mercury
• Scorpion
• Guppy
• Gopher+
• SuperText

These are best approached only after the capability model proves itself on the more important families above.

• Molerat
• Terse
• FSP

The product should not overfit the long tail before the core families are stable.

---

Scroll is not just another protocol on the list.

Its most interesting property for Graphshell is that it treats Universal Decimal Classification as a first-class content-shaping concern. That is architecturally unusual in the smolnet world and unusually aligned with Verse, which already treats UDC as a semantic typing and relevance signal for community search and indexing.

That makes Scroll interesting in at least three ways:

• semantic ingestion: Graphshell can ingest Scroll documents with more native structure than generic gemtext because the source is already trying to say what kind of thing it is
• Verse alignment: UDC-bearing documents map more naturally into Verse ranking, filtering, and subject-scoped community indices
• authoring fit: Scroll feels closer to Graphshell's worldview than a pure "small document over the wire" protocol because it bakes classification into the publication surface

For that reason, Scroll SHOULD be treated as a strategic Tier B target even if its deployment remains smaller than Gemini's or Gopher's.

This does not mean Middlenet should special-case Scroll everywhere. It means the capability and format architecture should leave room for Scroll's additional semantics to survive ingestion instead of being flattened away.

The provided specification makes clear that Scroll's document format is a distinct descriptive markup language, not just an ad hoc Gemini variant.

Important properties for Middlenet:

• MIME type is text/scroll
• headings run from # through #####, with level-5 headings explicitly treated as textual titles rather than outline-defining section boundaries
• documents are section-oriented: headings begin sections and imply nested outline structure rather than merely decorating nearby paragraphs
• thematic breaks use ---
• code blocks use triple backticks and optional format tags
• nested quotes and nested lists are first-class
• links use =>, while input links use =:
• inline emphasis, strong, and code toggles exist but are line-bounded
• line-level escaping is explicit and small enough to parse in a stream
• link relations such as [Citation], [Cross-reference], and polarity markers like [+] or [-Citation] are part of the document model, even if clients present them optionally

This is exactly the kind of source format Middlenet should preserve as its own semantic lane instead of flattening into generic HTML.

Scroll also matters at the transport-and-response layer.

The spec provided in-session defines:

• a request line of <URI> <LanguageList><CRLF>
• BCP47 language negotiation as a first-class request concern
• Gemini-style status handling for non-success cases
• success responses that include MIME type plus author, publish date, and modification date before the body
• metadata requests that return an abstract in scrolltext rather than the full resource body
• success codes in the 20-29 range whose second digit maps onto top-level UDC classes

That last point is unusually important. Scroll does not merely carry UDC as an optional document annotation; it reflects UDC at the protocol response level. That makes Scroll unusually compatible with Verse's own subject-typing and community-indexing ambitions.

The provided spec reinforces several Graphshell preferences already present in the docs:

• streamability: scrolltext is explicitly designed to be streamed and rendered progressively
• metadata-first access: abstract/metadata requests line up well with previews, hover cards, and low-cost fetch policies
• language-aware retrieval: BCP47 request language lists fit Graphshell's desire to respect reader preference rather than relying on site-side state
• small-protocol honesty: Scroll keeps the protocol simple while still allowing richer semantics than Gemini
• Titan adjacency: the spec explicitly recommends Titan support, which means Scroll sits comfortably beside the existing Gemini/Titan publication worldview rather than replacing it
• certificate continuity: TOFU, SNI, and optional client certs all fit the trust UX Graphshell is already building around Gemini-shaped lanes

If Graphshell adds Scroll support, the adapter and document model SHOULD preserve at least the following instead of collapsing them into plain text:

• heading-derived section hierarchy, including the special "title-like but not outline-defining" role of level-5 headings
• section hashes and heading-number-derived local navigation targets
• author, publish date, and modification date metadata lines
• BCP47 language negotiation intent and the language attached to returned resources
• UDC class information from success response codes
• link relations and relation polarity where present
• input-link semantics for query-style prompts
• metadata-request abstracts as first-class preview material

These are not just rendering details. They are navigation, indexing, preview, and trust signals.

---

Smolnet's native messaging coverage is thin.

Misfin is the clearest purpose-built lane here and is worth keeping on the roadmap because it is close enough to Gemini-shaped transport and content handling to be tractable once the capability model exists.

NNCP is conceptually interesting for Graphshell's long-horizon offline-capable/permacomputing posture, but it belongs in a later infrastructure phase rather than the core Middlenet rollout.

The smolnet ecosystem does not provide a compelling large-artifact transfer story. Titan handles uploads in a Gemini-adjacent way; document protocols handle document retrieval; none of that substitutes for a proper artifact layer.

Graphshell's answer here remains Verse plus iroh-blobs.

The capability model should therefore route by address and intent:

• small document retrieval goes to smolnet or Middlenet protocol handlers
• artifact retrieval goes to Verse-addressed or iroh-addressed flows
• the user should not have to care which substrate satisfies the request

This is an architectural complement, not a conflict.

---

The smolnet capability model and the smolweb HTML contract are adjacent, not identical.

• smolnet is about protocol and transport families for lightweight networked content
• smolweb is about the constrained HTML/CSS contract for Middlenet's HTML lane

That distinction matters because Graphshell should not silently convert every small protocol into generic HTML and call the problem solved. Protocol-faithful documents remain first-class. The HTML lane exists for actual HTML content and HTML-shaped archives or assistive views, not as a way to erase source protocol semantics.

The product posture should therefore be:

• faithful source semantics first
• optional assistive enrichment second
• HTML lane when the source is actually HTML or when an archive/export surface explicitly calls for it

Scroll is a particularly strong example of this rule. A Scroll document should normally enter Middlenet as Scroll, not as "HTML-shaped content with a nicer theme." Export to HTML may still be useful for publication or archive views, but Graphshell should preserve Scroll-native semantics at the canonical document-model layer.

---

This note implies a few documentation and architecture updates:

1. Replace long protocol lists with capability tables where possible.
2. Describe protocol support as the composition of transport and format handlers.
3. Keep Tier A/B/C/D priority language explicit rather than implying equal priority for every named protocol.
4. Call out Scroll explicitly as a UDC-aligned protocol worth strategic attention.
5. Treat Misfin as the main native messaging lane if smolnet messaging grows.
6. Keep Verse and iroh-blobs as the artifact-transfer answer rather than searching for a smolnet-native large-file story that does not really exist.

---

This note is intentionally architectural rather than ecosystem-statistical.

• protocol-health and deployment-size claims here are directional, not a rigorous census
• specific protocol support decisions should still pass through the dependency health rubric and the earlier admission-bar audit
• Scroll is highlighted here because of architectural fit, not because of a claim that it is widely deployed

That is enough for design direction even where exact community-size figures are uncertain.