(defcomp ()
  (~docs/page :title "Future Possibilities"
    (~docs/note
      (p "This page is speculative. Nothing here is implemented. It documents ideas that may or may not happen."))
    (~docs/section :title "Custom protocol schemes" :id "schemes"
      (p (~tw :tokens "text-stone-600")
        "sx:// and sxs:// as custom URI schemes for content addressing or deep linking. An sx:// URI could resolve to an sx expression from a federated registry. This is technically feasible but practically unnecessary for a single-site deployment."))
    (~docs/section :title "Sx as AP serialization" :id "ap-sx"
      (p (~tw :tokens "text-stone-600")
        "ActivityPub objects could be serialized as s-expressions instead of JSON-LD. S-expressions are more compact and easier to parse. The practical barrier: the entire AP ecosystem expects JSON-LD."))
    (~docs/section :title "Sx-native federation" :id "federation"
      (p (~tw :tokens "text-stone-600")
        "Federated services could exchange sx fragments directly — render a remote user's profile card by fetching its sx source from their server. This requires trust and standardization that doesn't exist yet."))
    (~docs/section :title "Realistic assessment" :id "realistic"
      (p (~tw :tokens "text-stone-600")
        "The most likely near-term improvement is sx:// deep linking for client-side component resolution. Everything else requires ecosystem adoption that one project can't drive alone."))))
