Federated Wiki's requirements for a **compatible API and protocol** for participating in a federation.
We consider what requests a server must handle in order to participate in wiki's federation. Such a server provides pages without taking responsibility for the client-side javascript conventionally used by federated wiki.
# Requirements
Wiki supports a small number of cross-origin endpoints which deliver pages and information about pages to client-side applications launched from other sites.
GET /welcome-visitors.json GET /other-page-slugs.json GET /system/sitemap.json GET /favicon.png
Wiki compatible servers are expected to deliver html hypertext content when a user's browser is directed to wiki related urls.
http://example.com http://example.com/any-page-slug.html http://example.com/view/...
In rare cases 'view' might be replaced with 'origin' or with the domain name, in our example, 'example.com'.
Federated wiki servers provide additional endpoints used by the client-side javascript code they serve. These do not apply to foreign servers which presumably support unrelated interactions with their users.
# Strategy
One could serve only cross-origin requests for well known pages and be a useful member of the federation.
GET /other-page-slugs.json
This could be joined into the federation by editing a lineup url to site the server/slug of the new resource and the resulting page dropped on a Factory to construct a lasting Reference that can move through the federation. The reference would expect a flag to be complete.
GET /favicon.png
Viewing such a Reference will induce a neighborhood inquiry. Failure here is inconsequential. But to be available to search add a sitemap.
GET /system/sitemap.json
Presence in the neighborhood does suggest the availability of a site with welcome-visitors as it's root. When this is absent a potentially confusing Future appears upon clicks.
GET /welcome-visitors.json
A good strategy is to use a private temporary instance of wiki to prepare these sorts of pages. If this static content is served from a 'pages' subdirectory then launch wiki on localhost:4000 to edit.
wiki -d . -p 4000 --security_legacy
So far all of these api endpoints are well defined and easy to support independently of any other services a foreign server might offer.
Wiki will generate hyperlinks available to the host browser where one could expect to find html content. These are targeted to new tabs.
http://example.com http://example.com/any-page-slug.html http://example.com/view/...
Here a foreign server is as free as any other traditional web site to take control of the browsing experience. Consider redirecting all of these into your own url scheme and leave federation browsing to the originating tab.