Open Transclusion and Linking Standard (OTLS)

Before talking about delegation we must talk about peer discovery. Under OTLS, a wiki can configure any amount (including none at all) of "peers" who are expected to support the same protocols. To truly enable the decentralized nature of OTLS, this list of peers must be available for being used to discover more wikis by the client. Such list must be at the location defined by the following two rules:

• If the canonical url of the wiki is with a HTTP query path of empty or / (e.g. something like "https://wiki.sebastian.graphics" or "https://wiki.sebastian.graphics/"), the peer list must be available at the location formed by appending peers.txt at the end of that URL (e.g. something like "https://wiki.sebastian.graphics/peers.txt").
• If the HTTP query path of the canonical url of the wiki is anything other than empty or / (e.g. something like "https://wiki.sebastian.graphics/wiki/Special:Index"), the peer list must be available at the location formed by taking the "directory part" of that URL and appending peers.txt at the end of that (e.g. something like "https://wiki.sebastian.graphics/wiki/peers.txt").

The URL of the peer list should refer to a plain-text file containing a list of query endpoints that uses the OTLS standard. Each line should contain one description of endpoint. Each description of endpoint can contain a name (optional), but must contain an URL. If choose to contain a name, the textual format would be the name, followed by a comma ,, followed by the URL. If choose not to provide a name, the host part of the URL is considered to be the name of that endpoint. For example, assume the file referred by a form's otls:peer link contains the following text:

https://wiki.sebastian.graphics/otls-query
  Minecraft   ,  https://minecraft.wiki/q
 AestheticsFandom,https://aesthetics.fandom.com/wiki/Special:Search

It would be considered as containing 3 peers:

• The first one only contains an URL, which means that its host part, i.e. wiki.sebastian.graphics, would be considered as the name of this peer.
• The second one contains the name Minecraft and the URL https://minecraft.wiki/q.
• The third one contains the name AestheticsFandom and the URL https://aesthetics.fandom.com/wiki/Special:Search.

All query endpoint should be designed to take its query string w/ the GET method and from the parameter named query. For example, to query the 3 peers listed in the example above, you need to send GET requests to the following URLs:

https://wiki.sebastian.graphics/otls-query?query={{text}}
https://minecraft.wiki/q?query={{text}}
https://aesthetics.fandom.com/wiki/Special:Search?query={{text}}

Wiki pages can provide a form like this:

<form otls:method="delegation"
      method="GET" action="{{action link}}">
  <!-- ... -->
  <input otls:action="query" type="submit" />
</form>

• Non-JS static file only site normally don't have the power to handle a form like this. One is still strongly recommended to include such a form and use otls:method and otls:action for browser extensions to pick up and handle the query. The action in this case can be left blank.
• Static file only site w/ JS should be able to hook onto the submit button and call the searching HTTP API there. The action in this case can be left blank.
• Sites with a backend should obviously be able to handle search queries…

Any form can use an additional or a separate peer list by using the otls:peer attribute:

<form otls:method="delegation" otls:peer="{{peerlist-url}}"
      method="GET" action="{{action link}}">
  <!-- ... -->
  <input otls:action="query" type="submit" />
</form>

The value of otls:peer should be one of the following:

• replace;{{url}}: replace the "canonical" peer list with {{url}}.
• add;{{url}}: append the "canonical" peer list with the content of {{url}}.
• {{url}}: same as add;{{url}}.